Current Limitations
When migrating from local to off-host execution, most content deployed to the Posit Connect server needs to be rebuilt. This process involves recreating the runtime environment needed to execute the content successfully. In a small number of cases, recreating the same exact execution environment within the new containers as had been built up over time on your on-prem server may not be possible. For this reason, validation of your important content after migration is recommended as well as the ongoing use of best practices in regards to package management and reproducibility.
Posit Connect must run either in local mode or Kubernetes mode; it is not possible to run with both at once. It is safe to switch between the two modes of operation by changing the Posit Connect configuration and restarting. Existing content needs to have its environment reconstructed the first time it executes after this change.
The launch of content processes takes longer when using Kubernetes than with local processes. This is especially obvious with interactive applications: there is no UI indicating that we are waiting for launch. Image size and Kubernetes scheduler overhead can contribute to slower process startup.
Processes do not appear in the Posit Connect dashboard Admin>Metrics view until they have successfully launched.
The Posit Connect dashboard Admin>Metrics view shows CPU/RAM for the Connect container and does not graph CPU/RAM for the content jobs. Current CPU/RAM for each job is listed in the Processes table.
RunAs users are not created within the runtime container; this can cause warnings like:
whoami: cannot find name for user ID 999Traffic between Connect and content pods is not encrypted.