Deployment Resource Scaling: Transitioning from Legacy Always On to Reserved VM Tiers

Question

Replit has transitioned from the legacy 'Always On' toggle to a structured Deployment system. This shift decouples the development Workspace from the production instance, meaning that Workspace sleep cycles no longer dictate the availability of a live application.

Under the current architecture, resource allocation is managed through specific machine types (such as Autoscale or Reserved) within the Deployments tab rather than a global account setting. This introduces a boundary where environment variables and resource limits in the Workspace may not align with the production deployment configuration.

When moving a project to a Reserved VM tier to ensure consistent uptime, it is unclear how the platform handles the synchronization of secrets and environment variables between the development environment and the deployed container.

Do environment variables defined in the Workspace automatically propagate to a Reserved Deployment?
  What is the documented behavior for updating these variables without triggering a full redeployment of the production instance?

Wasi · Answer

Short answer
Environment variables defined in the Workspace do not automatically propagate to a Reserved Deployment. You must enter them explicitly in the Deployment’s environment‑variables section, and any change there triggers a full redeployment (the container is recreated). There is no hot‑reload or in‑place update mechanism for Reserved VMs.
Confirmed facts

The Deployments tab stores its own key‑value pairs that are injected into the container at start‑up, completely separate from Workspace secrets or .env files.
  Changing any of those Deployment environment variables causes the deployment status to switch to "Updating" and a new container is started to apply the update.
  Workspace secrets can be referenced in the Deployment configuration, but modifications to those secrets only affect the Deployment after a subsequent redeploy.

Steps to configure and update variables for a Reserved VM

Open your project and go to the Deployments tab.
  Select the Reserved VM deployment you want to configure (or create a new one).
  In the deployment settings, find the Environment Variables section.
  Add, edit, or remove the key‑value pairs you need. These values are what will be injected into the container.
  Save the changes. The platform will automatically start a new deployment; you will see the status change to "Updating" and then to "Live" when the new container is ready.
  To verify, you can run a simple script in the deployed container (e.g., printenv or a language‑specific dump) and confirm the variables appear as expected.

What you cannot do

Edit a Workspace secret or .env file and expect the running Reserved Deployment to pick up the change without a redeploy.
  Trigger a hot‑reload of environment variables on a Reserved VM; Replit does not provide a signal‑based reload for this tier.

When to ask for more detail
If you are using Workspace secrets that are referenced in the Deployment configuration and you need to know whether updating the secret alone will propagate, let me know so I can clarify the exact redeploy requirement.

Deployment Resource Scaling: Transitioning from Legacy Always On to Reserved VM Tiers

1 answer

Short answer

Confirmed facts

Steps to configure and update variables for a Reserved VM

What you cannot do

When to ask for more detail

Your perspective belongs here.

0 question comments