Repository navigation
[MongoDB Service] Environment variables not set #4550
Description
To Reproduce
- Create a Database service of type MongoDB - everything default
- Set a Variable on Environment tab, e.g. TEST="tst" (see screenshots below)
- Deploy
- Check variables via terminal
Current vs. Expected behavior
Current:
echo $TEST # prints nothing
printenv #only some built in variables like MONGO_INITDB_ROOT_USERNAME are there
Expected:
I see both "built in" variables from the Dokploy mongo template as well as my own. When I edit Environment (e.g. add a new variable), the variables are updated (e.g. after restart, reload or something). This is how it works for "normal" services.
Provide environment information
Operating System:
OS: Ubuntu 24.04.4
Arch: x86-64
Dokploy version: v0.29.7
VPS Provider: Hetzner
What applications/services am I trying to deploy: Database - MongoDB (using Dokploy built in service type)Which area(s) are affected? (Select all that apply)
Databases
Are you deploying the applications where Dokploy is installed or on a remote server?
Same server where Dokploy is installed
Additional context
No response
Will you send a PR to fix it?
No
Activity
lubos-dataplaza commentedon Jun 5, 2026
Quick update:
Before posting the issue, I tested all combinations of Deploy/Reload/Stop/Start and they do not work.
However - I've found out, then when you do Advanced/Rebuild, it pushes the variables (but that's obviously not usable workaround as it also deletes data etc.).
dosubot commentedon Jun 5, 2026
Thanks for the additional detail — this narrows down the issue nicely.
Looking at the code, I can confirm why this happens:
Start/Stop/Reload only scale the Docker Swarm service replicas (0 or 1) — they never call
buildMongoor reconstruct the service spec, so environment variables are never updated [1].Deploy should work — it fetches the latest env vars from the database, passes them to
buildMongo, and does aservice.update()with an incrementedForceUpdatecounter to force a container restart [2]. However, other users have reported that this in-place update doesn't always propagate new environment variables to the running container [3].Rebuild works because it completely removes the Docker service and recreates it from scratch [4], which guarantees fresh containers get the new env — but as you noted, it also deletes volumes/data.
This looks like a bug where the Docker Swarm
service.update()path isn't reliably injecting updated environment variables into the restarted container. A potential fix would be for the Deploy operation on database services to remove and recreate the service (like Rebuild) but preserve the volumes, giving users a way to apply env changes without data loss.To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
fix: use stop-first update order for all database services (#4560)
🚀 Release v0.29.8 (#4562)
chore(release): 0.37.0 [skip ci]