Routine Maintenance and Migration

Upgrading Posit Connect, Posit Workbench, or Posit Package Manager isn’t the only maintenance work on your calendar. This page covers the routine tasks you do between product upgrades, and what to do when the operating system itself needs a major-version upgrade.

Routine maintenance

OS security patches

Apply operating system security patches on a regular cadence rather than waiting for a scheduled upgrade window. Patches managed by your distribution’s package manager (apt, yum/dnf, etc.) should be safe to apply without special precautions. You do not need to clear any Posit runtime caches after a routine distro-managed patch.

TLS certificate rotation

Rotating a TLS certificate means replacing the certificate and key files on disk and restarting the service. Where you configure this depends on the product:

  • Posit Connect and Package Manager: the [HTTPS] section of the gcfg configuration file.
  • Posit Workbench: the ssl-* keys in /etc/rstudio/rserver.conf.

A few rules apply across all three products:

  • The certificate file must contain the full chain, in PEM format, with permissions set to 644.
  • The key file must have permissions set to 600.
  • The key must not have a passphrase.
  • You must restart the service for the new certificate to take effect.
  • Use TLS 1.2 or higher.

Posit license renewal

The recommended way to renew your license is to place an updated .lic file in the product’s data directory and restart the service. This method works in air-gapped environments, since it does not require the server to contact a license server. After restarting, confirm the new license is active with license-manager status.

Each product also warns you before a license expires:

  • Posit Connect emails administrators 60 days before expiration, and shows a warning in the UI starting 15 days out.
  • Posit Workbench warns users in-session starting 15 days out, controlled by the license-warning-days setting.
  • Posit Package Manager exposes ppm_license_days_left and ppm_support_days_left as Prometheus gauges, so you can alert on them directly.

Upgrading the operating system

Warning

We do not recommend upgrading the operating system in place. Stand up a new environment, verify authentication, network, drivers, and package compatibility, migrate, then cut over. This keeps the original environment as a fallback until cutover.

This approach only works if package libraries are reproducible. Developers should use renv (R), venv, or uv (Python) so their package libraries can be rebuilt on the new host from a lockfile rather than reconstructed by hand. Reproducible libraries are what make the migration safe: without them, you’re relying on developers remembering exactly what was installed on the old server.

Content migration options

Once the new environment is verified, you have two ways to move content over:

  1. Spring cleaning: ask developers to redeploy only the content they still need. This clears out dead content along the way, but it isn’t automatic. Anything a developer doesn’t redeploy is left behind, so you need a way to confirm nothing important was missed.
  2. Move everything as-is, then rebuild package libraries on the new host.

For step-by-step instructions, see the [TODO: pin “Upgrade OS and product” / migration guide URL].