Env var changes without a redeploy: Docker, Kubernetes, Vercel, Railway, Fly and Heroku compared
Short answer: on most platforms an environment variable is fixed when a container or deployment starts, so changing one means a restart or redeploy. The exceptions are values delivered as files (Kubernetes volumes) or fetched by your app while it runs. The table below says what each platform does, with the source; the options after it are the ways to avoid the redeploy.
“Why do I have to redeploy to change one variable?” is asked on every platform. The reason is simple: a process receives its environment when it starts and nothing outside can change it (why). What differs is how much the platform makes you do. Facts below come from each platform’s documentation (linked, read 2026-11-01) or our own test where marked.
What each platform does
| Platform | What changing a variable means | Source |
|---|---|---|
| Docker | A running container’s environment cannot be edited. Our test: with Compose and env_file, editing .env changed nothing in the running container (it still printed A=one); docker compose up -d recreated the container and it printed A=two. docker update has no environment option |
Tested on Docker Compose v5.1.3 |
| Kubernetes | Env vars are set when the container starts. The ConfigMap docs say: “ConfigMaps consumed as environment variables are not updated automatically and require a pod restart.” Values mounted as volumes are different: “projected keys are eventually updated,” with a delay up to the kubelet sync period plus cache propagation, and a container using a subPath mount “does not receive automated Secret updates” |
Secrets, ConfigMaps |
| Vercel | “Any change you make to environment variables are not applied to previous deployments, they only apply to new deployments.” So: redeploy | Vercel docs |
| Railway | “Adding, updating, or removing variables, results in a set of staged changes that you must review and deploy, in order to apply them.” | Railway docs |
| Fly.io | fly secrets set “sets one or more app secrets, then updates each Machine belonging to that Fly App. This involves a restart of the Machine and a consequent reset of its ephemeral file system.” --stage defers it: staged secrets are only available on Machines started or updated afterwards |
Fly docs |
| Heroku | “Whenever you set or remove a config var using any method, your app is restarted and a new release is created.” | Heroku Dev Center |
So the platforms agree on the mechanism and differ in ceremony: Heroku and Fly restart for you, Railway stages the change for you to deploy, Vercel needs a new deployment, Docker needs a recreated container, and Kubernetes needs a pod restart unless you consume the value as a mounted file.
Ways to avoid a full redeploy
| Approach | What changes | Good for | Costs |
|---|---|---|---|
| Accept the restart, make it cheap | Rolling restarts, health checks | Anything | Brief disruption; every change is a deploy event |
| Kubernetes: mount as a volume | The kubelet updates the file eventually | Config files, certificates | Your app must re-read the file; subPath mounts don’t update; the delay is not instant |
| A controller that restarts workloads | Detects the change and rolls the deployment | Kubernetes teams | Still a restart; one more component |
| Agent or sidecar that re-renders a file and runs a command | A daemon polls a store and re-renders a file, then runs a reload command | Apps that can reload from a file | Poll interval. Infisical’s agent, for example, documents a default polling interval of 5 minutes and an optional command to run when a change is detected (docs) |
| Fetch at runtime in the app | Your code reads a secrets API while running | Any platform you can run code on | Your app holds API credentials; polling delay; a client per language |
| A supervising agent plus an SDK (what Dynv does) | dynv run starts your process and applies changes, either restarting only that process or updating hot variables in place |
Services where a restart is visible: pools, long connections | An extra binary or SDK; hot variables must be rebuilt by your code |
Not every platform allows the last row. On Dynv’s side, the facts:
dynv runsupervises your process. A variable in restart mode (the default) is applied by restarting that process (SIGTERM, then SIGKILL after 10 seconds) with the new environment: no image rebuild and no container redeploy, about a second after the change. A variable marked hot is updated in the running process and read through the SDK, with no restart at all. We showed a pool swap in a tested demo.- SDKs are on package registries:
npm install @dynv/sdk,pip install dynv,go get github.com/hoot-codes/dynv-go,composer require dynv/dynv. - Where you can’t wrap the start command (serverless functions, some PaaS), the SDK has a direct mode that fetches and decrypts in your process using a service token. The process then holds the token, which the SDK docs spell out as a trade-off.
- Build-time variables stay build-time. Values bundled into browser assets (
NEXT_PUBLIC_*, Viteimport.meta.env) are fixed when the build runs on any platform, including with Dynv.
Picking one
- If a restart is fine and you deploy often, the platform’s own workflow is the simplest thing.
- If you run on Kubernetes and your app can re-read a file, volume mounts avoid the restart for config you control.
- If you want to rotate credentials or change a pool’s connection string without a visible restart, you need something that delivers values while the process runs: your own fetch-at-runtime code, or an agent and SDK.
- Whatever you choose, the harder problem is usually which copies exist; see rotate a secret everywhere.
Limits of this comparison
- Platform behaviour changes. We quote documentation on the date above, and tested only Docker and Docker Compose. We did not run Kubernetes, Vercel, Railway, Fly or Heroku ourselves.
- We did not compare other secrets tools’ live-update features beyond the one documented example above.
Facts last verified . Spotted an error? Tell us.