bug: Project env query string stripped when using ${{project.DATABASE_URL}}

[dmrdvn]

To Reproduce

1. Create a project with Project > Environment variable:
   DATABASE_URL=postgresql+asyncpg://user:pass@some-host:/postgres?ssl=false
   (any valid URL; the important part is the query string after ?, e.g. ssl=false.)

2. In an application service (e.g. Docker Swarm app), set Service > Environment:
   DATABASE_URL=${{project.DATABASE_URL}}

3. Save and redeploy the service (full deploy so a new task is created).

4. On the server, verify the runtime environment inside the container:
   docker exec "$(docker ps -qf name=)" printenv DATABASE_URL

5. Observe that the printed DATABASE_URL does NOT contain ?ssl=false (query string is missing), while the Project env UI still shows the full URL including ?ssl=false.

6. Workaround: paste the exact same DATABASE_URL string (including ?ssl=false) directly into each service’s Environment and redeploy printenv DATABASE_URL then shows the query string correctly.

Current vs. Expected behavior

Current: Interpolated ${{project.DATABASE_URL}} at runtime drops the URL query string (?ssl=false). Project UI still shows the full string.

Expected: The resolved value in the container must match the project value byte-for-byte, including any ?key=value query parameters.

Provide environment information

OS: Ubuntu 24.04 LTS
Docker: Swarm (Dokploy on same host)
Dokploy version: 0.29.2
App: Custom service using DATABASE_URL to Supabase pooler

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

Application, Docker Compose

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

Same server where Dokploy is installed

Additional context

Related prior report (similar env/URL mangling): #2132, may be a different code path (project interpolation vs railpack).

Impact: Internal Postgres poolers (e.g. Supavisor) often need ssl=false on Docker networks; stripping ?ssl=false causes pooler errors like "User requested SSL connection but no downstream cert/key found" unless DATABASE_URL is duplicated per service.

Will you send a PR to fix it?

Maybe, need help

[dosubot]

Hi @dmrdvn! I'm Dosu and I’m helping the dokploy team.

This is a previously reported pattern — several issues have surfaced around environment variable values with multiple = signs getting truncated (e.g., MongoDB connection strings, argon2 tokens, and database URLs with query parameters like ?sslmode=require) [1] [2] [3].

The interpolation regex itself (/\$\{\{project\.(.*?)\}\}/g) is safe and does not strip query strings [4]. The current codebase uses dotenv's parse() function on line 404 to parse project env vars before interpolation [5], which should handle multiple = signs correctly. However, the question is whether your Dokploy version (0.29.2) includes this fix — an earlier version used a naive .split("=") that would truncate everything after the second = in values like ?ssl=false.

Workarounds to try now:

1. Wrap the value in double quotes in the Project env UI:

   DATABASE_URL="postgresql+asyncpg://user:pass@some-host:PORT/postgres?ssl=false"
   

   The dotenv parser treats quoted values differently and may preserve the full string.

2. As you already found, setting the value directly in the service-level environment bypasses the project interpolation pipeline entirely.

To help narrow down the root cause, could you check what's stored in the database vs. what ends up in the container? Specifically:

• Does the Dokploy UI (Project > Environment) still show the full URL with ?ssl=false? (You mentioned it does.)
• When you inspect the service-level env in the UI after saving ${{project.DATABASE_URL}}, does the resolved preview show the query string?

If the double-quote workaround fixes it, the issue is likely in how the dotenv parser handles unquoted values with = on your version. If it doesn't, the stripping may be happening further downstream in the Docker deployment pipeline.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dmrdvn]

Update:

• Dokploy version: 0.29.2 (as in the original report).
• Following @dosu’s suggestion, I set the Project environment value for DATABASE_URL in double quotes (full connection string including the ?… query part).
• Service environment still uses DATABASE_URL=${{project.DATABASE_URL}}.
• After redeploy, docker exec … printenv DATABASE_URL on all affected app containers shows the full URL including the query string (e.g. ?ssl=false is no longer dropped).

So quoting the Project env value fixed the problem for us; we’re unblocked.

Thanks @dosu and the team.

[dosubot]

Glad the double-quote workaround got you unblocked! 🎉

This confirms the issue is in how the dotenv parser handles unquoted values containing = signs in query parameters. The underlying behavior is that unquoted values with multiple = characters can get truncated during parsing, while quoted values are preserved correctly.

This is still a valid bug worth tracking — users shouldn't need to know to quote their env values for URLs with query strings to work correctly. If you're interested in sending a PR, the relevant code is in packages/server/src/utils/docker/utils.ts in the prepareEnvironmentVariables function, specifically around the parse() call on line 404. A fix could either sanitize/quote values before passing them to parse(), or use a custom parser that treats only the first = as the key-value delimiter regardless of quoting.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.