Skip to content

v0.30.0: generated .env wraps values in double quotes — stack (swarm) composes get literal quotes in container env and silently fail to deploy #5110

Closed as duplicate

Description

@2316348163

Summary

Since v0.30.0, the .env file Dokploy generates for compose deployments wraps every value in double quotes. The Environment tab stores values unquoted (KEY=value), but the generated file on disk contains KEY="value".

docker compose strips surrounding quotes when parsing env_file, so compose-type services are unaffected. docker stack deploy does not — the docker CLI passes env_file lines through verbatim (classic --env-file semantics). Every service in a composeType: stack deployment therefore receives the quotes literally in its environment.

Impact

Containers boot with e.g. SERVICE_TYPE set to the six characters "api" instead of api, connection strings with embedded quotes, etc., and crash on start. Because typical stack update_config uses failure_action: rollback with order: start-first, the rollback is silent: the deployment log ends with Docker Compose Deployed: ✅, the deployment is recorded as done, and the old containers keep running. Stack deploys effectively become no-ops — we served a stale build in production for ~36 hours before tracing it, because every layer (CI, webhook, Dokploy deployment status) reported success.

Reproduction

  1. Create a compose service with composeType: stack, an env var SERVICE_TYPE=api in the Environment tab, and env_file: [.env] in the compose file.
  2. Deploy on v0.30.0.
  3. docker inspect the new container: Config.Env contains SERVICE_TYPE="api" (quotes literal). On v0.29.x the same setup produced SERVICE_TYPE=api.

Verified by diffing docker inspect .Config.Env of a container created under v0.29.x (257 vars, 0 quote-wrapped) against one created under v0.30.0 from the same unquoted Environment tab content (253 of 257 quote-wrapped; the remaining 4 were image-level ENVs).

Expected

Generated .env values should be written unquoted (or quoting should be limited to the docker-compose code path / values that need it), since docker stack deploy consumes env_file lines verbatim.

Environment

  • Dokploy v0.30.0, self-hosted, linux/amd64, single node
  • Compose type: stack (swarm), sourceType raw

Workaround

We inserted an entrypoint shim in each affected stack compose that strips symmetric double quotes from every env value and execs the original entrypoint:

entrypoint:
  - python3
  - -c
  - "import os;env={k:(v[1:-1] if len(v)>1 and v[0]==chr(34) and v[-1]==chr(34) else v) for k,v in os.environ.items()};os.execve('/entrypoint.sh',['/entrypoint.sh'],env)"

Activity

  1. linear-code commented on Aug 18, 2026

    @linear-code
  2. dosubot commented on Aug 18, 2026

    @dosubot

    Hi @2316348163! I'm Dosu and I'm helping the Dokploy team.

    This is a duplicate of #5096, which has already been traced to the same root cause and has an open fix PR.

    Root cause: PR #4962 (merged into v0.30.0) introduced prepareEnvironmentVariablesForFile to fix special-character corruption reported in #4694. That function wraps every value in double quotes — KEY="value" [1]. This is valid dotenv and docker compose strips the quotes correctly, but docker stack deploy passes env_file lines verbatim, so the quotes become literal characters in the container environment [2].

    Fix in progress: PR #5105 is open on canary and addresses exactly this. It adds a requiresDotenvQuotes(value) check so prepareEnvironmentVariablesForFile only quotes values that actually contain $, #, whitespace, ", or \. Values that are already dotenv-safe (URLs, alphanumeric strings, etc.) are emitted unquoted, keeping docker stack deploy working correctly while preserving the #4694 fix [3].

    Until that PR lands in a release, your entrypoint shim workaround is the right approach.

    To reply, just mention @dosu.


    Share context across your team and agents. Try Dosu.

    Leave Feedback Learn about dokploy with Dosu Add Dosu to your team

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions