DB wipe after possible automatic Docker path update

[ciscoheat]

To Reproduce

I had a Postgres DB that yesterday got wiped out after some update that is possibly related to #3017. Note: I'm using Dokploy Cloud, so I haven't done any updates on the Dokploy platform.

What I did was upgrading packages with apt, and the kernel, so a reboot was needed, after that the DB was just gone. I looked at the application in Dokploy, and what I found on the Advanced tab was that the docker image was docker:18 and the volume path /var/lib/postgresql/18/docker. I have used Postgres 17 and have not updated or changed anything there.

So what I wonder is if the aforementioned issue, or something else, auto-updated the Postgres application so it just cleaned out the DB after reboot. Fortunately I had backups (all labeled 17.3, so I know it was version 17 before this happened), so I created a new Postgres instance and restored to there, but it still took many hours to figure out what had happened, and of course the uncertainty of if it will happen again. For example, how to ensure certain data like the database is always left on the drive, even if something like this happens with Docker?

Current vs. Expected behavior

I expect of course the package and volume path not to change automatically! Also note that I tried to set the Docker image in advanced to postgres:18.3, but when saving and deploying, Dokploy reset it back to just postgres:18.

Provide environment information

OS: Ubuntu 24.04 LTS
VPS Provider: Hostinger
Application: Postgres database

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

Databases

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

Remote server

Additional context

No response

Will you send a PR to fix it?

Maybe, need help

[dosubot]

This looks related to a known issue with PostgreSQL volume mount paths. Here's what likely happened:

Root cause: The volume mount path /var/lib/postgresql/18/docker is specific to PostgreSQL 18. If your database was originally created with PostgreSQL 17, the mount path would have been /var/lib/postgresql/data. The mismatch means your actual data wasn't being persisted to the volume - so after reboot, PostgreSQL initialized a fresh database.

Important clarification: Dokploy does not automatically update database Docker images. The dockerImage field is stored in the database and persists once set. However, mount paths are set only during database creation and are never updated afterward. This creates a critical issue if the image tag was manually changed at some point - the mount path wouldn't update to match.

Regarding the image resetting from postgres:18.3 to postgres:18 - this shouldn't happen as the update API preserves the exact value you set. Could you confirm:

1. When you created the original database, what image was shown?
2. Is there any chance someone (or some process) changed the Docker image from postgres:17 to postgres:18 at some point?

For your new instance, to prevent this happening again:

1. Pin to an exact version (e.g., postgres:17.3) rather than a major version tag
2. Consider setting the Docker stop timeout to at least 60 seconds in advanced settings - the default 10 seconds can cause WAL corruption during restarts
3. Verify the volume mount path matches your PostgreSQL version

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ciscoheat]

@dosu I can confirm:

1. When creating the original database, the image postgres:17 was shown, since all backups done since then contains the exact DB Version (Debian 17.7-3.pgdg13+1).
2. Nobody touched anything, I know how sensitive Postgres is regarding updates and would never increase the major version. I was happy at version 17, but now I fear using it if this happens again. Unfortunately the backup script needs to be rewritten because of this as well, as it only supported v17. And again, I'm using Dokploy Cloud so I'm not in control (and don't want to be) of any updates.

I'm trying to pin it to postgres:18.3, but Dokploy resets it to postgres:18 after deployment. Shouldn't be hard to reproduce: Set a minor version as package and deploy - it should revert to the major version only.

How to set the stop timeout to 60 seconds? I'm not sure where to change Docker configuration.

[dosubot]

Thank you for confirming those details - this is very concerning and definitely sounds like a bug, especially since you're certain you never changed the image from v17.

For the Stop Grace Period setting:
Go to your PostgreSQL database → Advanced → Cluster Settings → Swarm Settings → Stop Grace Period. Values are in nanoseconds, so for 60 seconds you'd enter 60000000000.

Regarding the image version reset issue:
I've checked the backend code and the deployment logic does not modify Docker image tags - it should preserve postgres:18.3 exactly as you set it. The update API also saves the dockerImage field as-is.

If you can reliably reproduce the reset from postgres:18.3 to postgres:18, that's a separate bug worth documenting here. Could you share screenshots of the Advanced tab before saving and after deployment? This would help identify whether it's a frontend UI issue (form not preserving the value) or something else.

As for the original v17→v18 change - since you're on Dokploy Cloud and didn't make any changes, this might need investigation from the Dokploy team to check if there was any backend migration or process that affected database configurations.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Siumauricio]

@ciscoheat

I tried to follow these steps, but the docker image field is saved correctly. Databases that have already been created previously do not update the docker image, so the information is always preserved.

I tried to create a database with the postgres:18.3 image. I deployed it, and the docker image is still 18.3, not 18

[ciscoheat]

I understand, it seems to be working fine after the incident (with postgres:18), and I didn't change anything before that, so the only thing I can think of is a change like #3017 was applied automatically for Postgres applications on the Dokploy cloud platform.

[Siumauricio]

Good point, I guess you have a postgres:18 version and then we update this which change the volume path and then you make a new deployment and then you lose the information I guess?

[ciscoheat]

I'm quite certain it was postgres:17 since the backups are stamped with version 17, but yes, if it changed, when the server rebooted it must have created that situation if a different volume path was found.

[Siumauricio]

Fixed here #4013