[Bug]: Dokploy Cloud v0.29.12 remote deploy silently removes all runtime environment variables

[khanhduyvt0101]

To Reproduce

1. Use Dokploy Cloud v0.29.12 with an Application deployed to a remote, single-node Docker Swarm server.
2. Configure multiple runtime variables in the application's Environment tab. Include a harmless marker such as:

   DOKPLOY_ENV_TEST=true

3. Save the Environment configuration.
4. Deploy or redeploy the application from Dokploy.
5. Confirm that the deployment finishes successfully with status done.
6. Inspect the deployed service on the remote server without printing secret values:

   docker service inspect <service>      --format '{{ len .Spec.TaskTemplate.ContainerSpec.Env }}'

7. Inspect only the harmless marker inside the running task:

   docker exec <container> sh -lc      'if [ "$DOKPLOY_ENV_TEST" = "true" ]; then echo present; else echo missing; fi'

8. Observe that the service environment count is 0 and the marker is missing.
9. Add or change a variable in the Environment tab and redeploy again. The new task still receives no runtime variables.

This reproduced consistently across two Docker-image Applications on the same remote server. One application had a small environment block and the other had more than 30 configured entries; both new service specs ended with an empty environment array.

Current vs. Expected behavior

Current behavior

• Dokploy Cloud displays the saved variables correctly in the Environment tab.
• Deploy/redeploy completes successfully.
• The resulting remote Swarm service has:

  TaskTemplate.ContainerSpec.Env: []
  

• Consequently, applications fail at startup when required configuration is absent.
• If an application also has a bind-mounted .env file, it may appear to work while silently using stale file content instead of the Environment tab. Changes made in the Environment tab are still not received.

Expected behavior

• Every variable saved in the application's Environment tab should be applied to the remote Swarm service during deploy/redeploy.
• A deployment must not report success if the configured environment cannot be decrypted or parsed.
• If environment decryption fails, deployment should stop with an actionable error and preserve the last working service rather than replacing it with Env: [].
• A file volume should not be required for runtime variables; the Environment tab should be usable as the sole configuration source.

Provide environment information

Operating System:
  OS: Linux (remote VPS)
  Arch: x86_64
Dokploy version: Dokploy Cloud v0.29.12
VPS Provider: Remote VPS provider (redacted)
Deployment target: Remote single-node Docker Swarm
Applications/services: Docker-image and Dockerfile Applications

Which area(s) are affected? (Select all that apply)

Application, Docker, Remote server, Cloud Version

Are you deploying the applications where Dokploy is installed or on a remote server?

Remote server

Additional context

Investigation

The saved Environment value is present when reading the Application configuration through Dokploy, and the same plaintext block parses correctly as dotenv syntax. However, immediately after a successful Dokploy deploy/redeploy, the remote service contains zero runtime environment entries.

This appears related to environment-at-rest encryption introduced in #4789. The exact failure path is described in closed PR #4816:

1. Environment decryption fails and the ORM returns the raw versioned ciphertext beginning with enc:v1:.
2. The deployment path passes that value to dotenv parsing.
3. The ciphertext is not a dotenv assignment, so parsing produces an empty object.
4. The Swarm builder writes TaskTemplate.ContainerSpec.Env: [].
5. Deployment still reports success.

Because this occurs on Dokploy Cloud while dispatching to a remote deployment worker, a Cloud web/worker version mismatch or inconsistent ENCRYPTION_KEY / BETTER_AUTH_SECRET is a possible infrastructure trigger. That part is an inference and needs confirmation by the Dokploy team.

Workarounds currently verified

1. Directly restore the complete environment on the Swarm service

Applying the complete environment directly with docker service update restores the application:

docker service update \
  --env-add KEY=value \
  <service>

In practice, all required variables must be applied together; adding only one marker is unsafe for an application that requires many variables. Secret values should be supplied through a secure mechanism and must not be placed in shell history or logs.

This workaround is temporary: the next Dokploy deploy/redeploy removes the variables again.

2. Temporary bind-mounted .env file

A file volume mounted at the application's working-directory .env path allows runtimes that load dotenv files at startup to continue operating. After editing the file, the application must be reloaded so the process reads it again.

This is not the desired permanent solution because it duplicates the Environment tab, can become stale, and can hide the fact that the Swarm service environment is empty. The intended steady state is:

• Environment tab is the only runtime configuration source.
• “Create .env file” is disabled.
• No application .env file volume is mounted.
• Deploy/redeploy reliably applies the saved variables.

The file-volume workaround cannot be safely removed until Environment propagation works again.

Suggested behavior/fix

At minimum, reject raw enc:v1: ciphertext before dotenv parsing and fail the deployment with an encryption-key consistency error, as proposed in #4816. The underlying Cloud worker key/version inconsistency should also be corrected so the worker can decrypt the environment block.

No logs, screenshots, names, IDs, domains, IP addresses, environment-variable values, or credentials are included in this report.

Will you send a PR to fix it?

No

[dosubot]

Thanks for the detailed bug report. I looked into the relevant code and can confirm the mechanism you've described.

The environment encryption introduced in PR #4789 uses a custom Drizzle ORM column type (encryptedText) that transparently decrypts values when reading from the database. Critically, the fromDriver method has a fail-open catch block that returns the raw ciphertext if decryption fails [1]:

try {
  return decryptValue(value);
} catch {
  // Return raw ciphertext instead of breaking queries
  console.error(...);
  return value;
}

This means if the Cloud worker's ENCRYPTION_KEY / BETTER_AUTH_SECRET doesn't match the key used to encrypt the environment data, the ORM silently returns the raw enc:v1:... string. Since that's not valid dotenv syntax, the downstream parsing produces an empty object, and the Swarm service gets Env: [] — exactly as you observed.

The decryption system does support multi-key fallback (primary key → fallback auth-secret-derived key → restored keys from backup files) [2], but if none of the available keys match what encrypted the data, it still fails silently at the ORM level.

Your diagnosis aligns with the code: the root issue is likely a key inconsistency between the Cloud web process (which encrypts on save) and the remote deployment worker (which reads/decrypts during deploy). Your suggested fix — rejecting raw enc:v1: ciphertext before dotenv parsing and failing the deployment with an actionable error — would prevent the silent data loss even if the key inconsistency isn't immediately resolved.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[khanhduyvt0101]

Thanks for confirming the code path.

@Siumauricio, this is still affecting our Dokploy Cloud v0.29.12 Applications deployed to a remote single-node Swarm server. Could you please confirm whether the Cloud web process and deployment worker are using consistent encryption keys, and let us know when it is safe to redeploy?

Until then, we are retaining the temporary bind-mounted .env file because a Dokploy deploy/redeploy produces TaskTemplate.ContainerSpec.Env: []. We can provide additional sanitized diagnostics if needed.

[smcalilly]

Confirming this on a Docker Compose stack (Dokploy Cloud → remote single-node Swarm). Same root cause, slightly different symptom.

Two deploys of the same env ~16 min apart, no Environment-tab change between them:

• Earlier: all vars present, stack came up fine.
• Later: Compose reports the previously-present required vars as unset:

level=warning msg="The \"DATABASE_URL\" variable is not set. Defaulting to a blank string."
level=warning msg="The \"DJANGO_SECRET_KEY\" variable is not set. Defaulting to a blank string."

The whole env came back empty — consistent with enc:v1: ciphertext parsing to {}. The Environment tab still shows the values correctly; only the deployed runtime env is empty.

For Compose the tell is these interpolation warnings (not Env: []). And if a one-shot migration service gates the others via condition: service_completed_successfully, the empty env makes it exit 1 and aborts the whole deploy — so this variant fails loudly instead of silently serving a misconfigured app.

Rejecting raw enc:v1: before dotenv parsing and failing with an actionable key-inconsistency error (instead of fail-open → empty env) would cover this too.

[othpwn]

I have the same problem, the environment variables I added through the UI are not accounted for during build. I checked /etc/dokploy folder for my deployment and indeed .env is empty

[Siumauricio]

Hey, we are investigating this issue!

[RonaldY98]

Seeing the same issue on my end as well, runtime environment variables seem to be dropped during the deployment step, preventing me from successfully deploying certain services that are deployed under docker swarm stack in a single node configuration. The actual environment variables that are dropped seems to be inconsistent on a per deployment basis.

[Siumauricio]

This is now fixed ✅

The root cause was on our Dokploy Cloud infrastructure side: the deployments service (the worker that executes deployments to remote servers) was missing the encryption-related environment variables, so it couldn't decrypt the environment blocks introduced by the encryption-at-rest feature (#4789) and services ended up deployed with an empty environment. This was an infrastructure configuration issue on our end — not a bug in Dokploy itself, and self-hosted installs were not affected.

No data was lost — your variables were always intact in the database (that's why the Environment tab kept showing them correctly). To recover, simply redeploy your applications and the environment variables will be applied to your services again. If you added a temporary bind-mounted .env file as a workaround, you can remove it after redeploying.

We'll also ship a safeguard so that if an environment block ever fails to decrypt again, the deployment fails with a clear error instead of silently deploying with an empty environment.

Thanks for the detailed report and investigation — it helped us narrow this down quickly.

[Siumauricio]

I will close this issue for now, thanks for reporting