DEV Community: Saimul Islam

How to upgrade Postgres in Docker to 18, and be ready for 19: dump and restore or pg_upgrade --link

Saimul Islam — Mon, 02 Nov 2026 13:44:24 +0000

I moved a Postgres database on Dokploy from 16 to 18 with pg_upgrade. It went fine, with the database down for under a minute, but it stopped twice on the way. First, pg_upgrade stopped at its checks: old cluster does not use data checksums but the new one does. Then 18 started, and my app couldn't connect.

Neither stop was bad luck. Both follow from how the 18 tooling works, and both wait in a typical pg_upgrade of a 14 to 17 database made with the image's defaults. You'll meet them soon: 14 gets its final release on November 12, 2026, and 19 is planned for October 29 (as of October 2026).

This guide is for you if you run Postgres 14 to 18 in a Docker volume, Dokploy and Coolify included. It gives you one timed rehearsal that picks your path: dump and restore, or pg_upgrade --link. Then both paths step by step, the exact errors with their fixes, the rollback for each, and five checks that prove it worked.

Key takeaways

The 18 image moved PGDATA to /var/lib/postgresql/18/docker and the volume to /var/lib/postgresql, so pg_upgrade --link can hard-link inside one mount. A volume mounted at PGDATA itself, as Dokploy does for 18, blocks it.

Rehearse a dump and restore on a copy and time it. If it fits your downtime window, take that path. If not, --link took 12.9 to 14.4 seconds from 1.4 to 8.5 GB in End Point's 2015 test.

A 17 cluster made with the image's defaults has data checksums off, and 18's initdb turns them on. pg_upgrade refuses the mismatch, and the fix you pick follows you to 19.

An upgraded cluster doesn't get the image's pg_hba.conf line for other containers, so your app is refused until you copy your old file back.

Once the new server starts, a restored backup is --link's only way back.

How this guide was checked: I didn't run any of these commands for this post. They're assembled from the PostgreSQL 18 docs, the official image's source (18.6, as of October 2026), and the upgrade image's scripts, and each block says "Untested." Error messages come from that source and from GitHub issues. The examples use a Compose project myapp, a service db, a volume pgdata, and the superuser postgres.

Table of contents

Why the Postgres 18 image moved your data
Dump and restore or pg_upgrade --link: let one timed rehearsal decide
Before either path: rehearse on a copy and time it
Path A: dump and restore into a fresh 18 volume
Path B: pg_upgrade --link in four steps
How to check the upgrade worked
Errors you might see, and what fixes them
On Dokploy: the mount that blocks an in-place upgrade to 19
Upgrading to 19: what's ready and what isn't
When not to use pg_upgrade --link
Check two lines before 19 ships
Sources

Why the Postgres 18 image moved your data

Three answers from a developer would worry me before a database upgrade, because each one skips a step that decides whether the data survives. The first is "just change the version." In Docker, current 18 images refuse it outright.

The 18 image moved the data down one level so that two clusters can share one mount. That's what pg_upgrade --link needs, because a hard link can't cross a mount point.

Here's the mechanism. --link makes one link(2) call per data file instead of copying it. The link(2) manual says the call fails with EXDEV across different mounts, "even if the same filesystem is mounted on both." Docker makes every volume its own mount.

On 17 and earlier, the volume is the data directory (/var/lib/postgresql/data). There's no room inside it for a second cluster, so the new one has to live on a second mount, and linking fails. A maintainer said volumes were "stuck using the slow version" (PR #1259).

From 18, PGDATA is /var/lib/postgresql/18/docker and the VOLUME is /var/lib/postgresql (image docs). Mount the parent, and 17/docker, 18/docker, and later 19/docker sit side by side in one volume.

What the old mount does on 18 depends on when the image was built:

Current Debian images (since October 22, 2025): the entrypoint finds old data, or an unused mount at /var/lib/postgresql/data, prints Error: in 18+, these Docker images are configured to store database data in a format which is compatible with "pg_ctlcluster", and exits 1 without touching your data (entrypoint source, PR #1372). Under restart: always, that's a restart loop.
18.0-era images: a deliberate data symlink made Docker fail on many setups with error mounting ... to rootfs at "/var/lib/postgresql/data" ... no such file or directory. Alpine images kept the symlink until January 29, 2026.
Alpine images built before the April 21, 2026 fix: their check missed bind mounts at the old path, so some setups started an empty cluster in an anonymous volume and ran that way for weeks.

A maintainer predicted that last symptom, "a running empty database," for anyone who starts a new major on old data without upgrading (PR #1259). The refusal in the first bullet exists to stop it.

Verify it: check which directory your server writes to.

# Untested.
docker inspect <container> --format '{{ json .Mounts }}'
docker compose exec db psql -U postgres -c 'SHOW data_directory;'

You want one mount whose Destination is /var/lib/postgresql, and a data directory inside it. Next question: do you need any of this, or is a dump simpler?

Dump and restore or pg_upgrade --link: let one timed rehearsal decide

Rehearse a dump and restore on a copy and time it. If it fits your downtime window, use dump and restore. If it doesn't, use pg_upgrade --link.

One published rule of thumb puts a number on it, CYBERTEC's from 2019: dump-and-restore trouble starts "around 100GB." Your own timing beats any general rule.

The PostgreSQL docs call dump and restore the method that "can be slow" and say pg_upgrade finishes "in minutes, particularly with --link mode." Here's what each path does to your data, per the pg_upgrade docs:

Path	What happens to the data	Extra disk during the upgrade	Needs	Way back
Dump and restore	Every row re-inserted, indexes rebuilt	The dump plus a full new cluster	The new image's client tools	The old volume, untouched
`pg_upgrade --copy` (default)	Every file copied	About the cluster's size again	Old and new binaries	The old cluster, untouched
`pg_upgrade --link`	Hard links; nothing copied	Almost none	One mount for both clusters	Rename `pg_control.old` if the new server never started; after that, your backup
`pg_upgrade --clone`	Reflinks	Almost none at first	Btrfs, XFS with reflink, or APFS (not ext4)	The old cluster, untouched
`pg_upgrade --swap` (new in 18)	Directories moved	Almost none	One filesystem	Your backup, once transfer starts

The only controlled comparison with published numbers is from 2015, but its shape is the point. In Greg Sabino Mullane's test (9.3 to 9.4, pgbench data, fsync off on the target, hardware not stated), dump and restore took 210 seconds at 1.4 GB and 1,927 seconds at 8.5 GB. The whole --link run took 12.9 to 14.4 seconds at every size, and --copy landed in between, from 74.7 to 607 seconds.

--link time follows the number of tables and indexes, not bytes. Daniel Westermann measured 13.8 seconds for a --link upgrade of 10,000 tables and 10,000 indexes, from 17.2 to an 18 development build (March 2025).

Two more options sit between them. With --copy, you need no layout move and keep the old cluster as your way back, at the cost of the disk and minutes of copying. With --clone, you keep it too, if your filesystem can do reflinks. And know what you're betting with --link: after first start, your rollback is the restore half of that timing, so check it against the window too.

Dump and restore buys real things, though. The new cluster gets the 18 layout and checksums by default, every index is rebuilt on the new image's C library, and the old volume stays as your rollback. Windmill, BloodHound, authentik, Discourse, Coolify, and Immich's community guide all document dump and restore for the Postgres their apps run on.

My pick: for a production database, I'd use pg_upgrade, because it's faster on big databases. The rehearsal tells you whether yours counts as big.

Either way, the rehearsal comes first.

Before either path: rehearse on a copy and time it

"We have backups" is the second answer that would worry me, when nobody has restored them. Dump your database with the 18 tools, restore it into a scratch volume, and time both halves. The total is your Path A downtime. The restore half is your rollback time for Path B, because once the new server has started, the docs' answer to any failure is "restore from backup."

What you need before you start:

postgres:18.6, the newest 18 minor as of October 2026, pinned.
For Path B, tianon/postgres-upgrade (tags 14-to-18 to 17-to-18).
Free disk for a full dump, plus room for a second cluster on Path A.
A scratch volume, and a quiet hour on the calendar for the real run.

Take the dump with the new version's tools: the docs recommend pg_dump and pg_dumpall "from the newer version of PostgreSQL." Path A shows the commands; for the rehearsal, point them at a scratch volume and leave the app running.

War story: with three weeks of production data on Dokploy, I ran a migration late at night and for about 90 seconds believed I'd wiped the users table. I hadn't. But when I went looking for backups, there were none.

I set up Dokploy's scheduled pg_dump to Cloudflare R2, and the week after, I restored one into a throwaway Postgres service on purpose. It took 10 minutes; the database was a couple hundred MB at the time. A backup you've never restored isn't a backup. It's a file you feel good about.

GitLab learned the same lesson at scale in its January 2017 outage. Its backup job had been failing on a pg_dump version mismatch, the S3 bucket was empty, and "nobody was responsible for testing this procedure."

For Path B, rehearse on a 17 copy, not the 18 restore. Dump with your current image's own tools and restore into a scratch postgres:17 volume created with production's POSTGRES_USER and POSTGRES_INITDB_ARGS, so the install user and checksum setting match. Then move it into the new layout, run --check --link and the real upgrade against it, and time the whole thing. (The docs' own test advice is lighter: "create a schema-only copy of the old cluster, insert dummy data, and upgrade that.")

A logical copy won't carry production's recorded collation version unless the scratch 17 runs production's image, and it never carries damage inside the data files. And run --check against a stopped cluster, production or the copy: it reaches the old server through its Unix socket, which lives inside the other container.

The backup is usually your biggest disk cost. --link needs almost nothing extra; a full dump of your data does. With a timed rehearsal in hand, you know your path.

Path A: dump and restore into a fresh 18 volume

Dump with the 18 client, restore into a new volume mounted the 18 way, and keep the old volume until you've checked. The new cluster gets the new layout and data checksums for free.

# Untested. 1) Stop the app so nothing writes during the dump.
docker compose stop app

# 2) Dump everything with the 18 tools, against the running 17 server.
#    Export PGPASSWORD in your shell first; -e passes it into the container.
docker run --rm --network myapp_default -e PGPASSWORD postgres:18.6 \
  pg_dumpall -h db -U postgres > all.sql

Then point the db service at a new volume and the new image. Keep POSTGRES_PASSWORD: an empty volume won't initialize without it.

# Untested. docker-compose.yml
services:
  db:
    image: postgres:18.6
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pgdata18:/var/lib/postgresql   # new volume, mounted at the parent
volumes:
  pgdata18:

# Untested. 3) Start 18 and wait for its first-run setup to finish.
docker compose up -d db
docker compose logs -f db   # wait for "PostgreSQL init process complete; ready for start up."

# 4) Restore, keep the errors, refresh statistics, start the app.
docker compose exec -T db psql -U postgres -f - < all.sql 2> restore-errors.log
docker compose exec db vacuumdb -U postgres --all --analyze-in-stages
docker compose start app

Wait for that log line: during first init, a temporary server listens on the Unix socket only, and a restore that reaches it gets cut off when the entrypoint stops it. In restore-errors.log, expect role "postgres" already exists (and database ... already exists if you set POSTGRES_DB); anything else needs a look.

Rollback is one edit: put postgres:17 and the old volume back in the Compose file. If your rehearsal didn't fit the window, Path B is for you.

Path B: pg_upgrade --link in four steps

Path B keeps your data where it is and links it into an 18 cluster in the same volume. It takes four steps: move the layout on your current major, check two settings, run the upgrade, then give 18 what it didn't inherit. My own 16 to 18 pg_upgrade hit two of the problems below: the checksum mismatch (step 2) and the pg_hba.conf lockout (step 4).

Step 1: Move your volume into the one-mount layout

Move the existing cluster into <your major>/docker inside the same volume, set PGDATA, and mount the parent. Do it on your current major, so the layout change and the version change happen on different days.

The image docs describe this opt-in: set PGDATA=/var/lib/postgresql/17/docker, mount at /var/lib/postgresql, and first move "all database files into a PG_MAJOR/docker subdirectory." Inside one volume the move is a rename, so it's near-instant at any size.

Stop the database so nothing restarts it. docker compose stop keeps it stopped; for a Swarm service, docker service scale <service>=0 stops all replicas while keeping the service. Compose names the volume <project>_pgdata, so check the real name with docker volume ls; a bare pgdata would create a new, empty volume.

# Untested. Runs as the postgres user so ownership stays the same.
docker run --rm --user postgres --entrypoint sh \
  -v myapp_pgdata:/var/lib/postgresql/data postgres:17 -c '
    cd /var/lib/postgresql/data &&
    mkdir -p 17/docker && chmod 700 17/docker &&
    for f in *; do [ "$f" = 17 ] || mv "$f" 17/docker/; done'

Then change the service:

# Untested.
services:
  db:
    image: postgres:17
    environment:
      PGDATA: /var/lib/postgresql/17/docker
    volumes:
      - pgdata:/var/lib/postgresql   # was /var/lib/postgresql/data
    stop_grace_period: 2m            # default is 10s

Gotcha: both lines matter. Mount the parent on 17 without setting PGDATA, and the image's own VOLUME /var/lib/postgresql/data gives you an anonymous volume that won't survive the container being removed. Don't test it with docker compose up --force-recreate: Compose keeps anonymous volumes across a recreate (docker compose up), so a test row survives anyway. Run SHOW data_directory; instead; it should print /var/lib/postgresql/17/docker.

The longer grace period matters because pg_upgrade refuses a cluster that wasn't shut down cleanly, and the image's Dockerfile asks for a stop timeout longer than Docker's 10-second default. The docs don't describe an undo; moving the files back, dropping PGDATA, and mounting /var/lib/postgresql/data again should work, but that's an inference.

Step 2: Check data checksums and the superuser

This is where my 16 to 18 upgrade stopped first. Two settings decide whether the upgrade runs at all, so check both while 17 is still up.

First, checksums: docker compose exec db psql -U postgres -c 'SHOW data_checksums;'. 18's initdb turns them on by default (18.0 release notes), and pg_upgrade refuses a mismatch:

off (the 17 image's default): pg_upgrade stops with old cluster does not use data checksums but the new one does. Create the new cluster with --no-data-checksums, as a docker-library maintainer suggests in tianon issue #121. That's the flag that got mine through.
on (Immich's Compose file sets it, for example): leave the flag out, or you'll get the mirror error, old cluster uses data checksums but the new one does not.

The upgrade image's README example never hits this, because it creates its 17 test cluster with checksums on. Real 17 clusters made with the defaults don't have them.

Second, the superuser. If your Compose file sets POSTGRES_USER=app, the cluster's install user is app, and the upgrade image's plain initdb creates postgres, so the run fails. The workaround reported in tianon's issues is -e PGUSER=app plus --username=app in POSTGRES_INITDB_ARGS.

Step 3: Run pg_upgrade --check --link, then the real run

There's no official way to get two Postgres versions into one container. tianon/postgres-upgrade is postgres:18 plus 17's binaries from the PostgreSQL apt repository. Its own README calls it a proof of concept to learn from and adapt.

Stop the database again (docker compose stop db) and keep it stopped. Nikolay Samokhvalov of Postgres.ai reported on the pgsql-hackers list a production case where an upgrade's target was started mid-run and corruption surfaced weeks later. The cause isn't proven, but nothing in pg_upgrade prevents it.

# Untested. One volume, mounted at the parent, for both clusters.
# Keep POSTGRES_INITDB_ARGS only if SHOW data_checksums said off.
docker run --rm \
  -v myapp_pgdata:/var/lib/postgresql \
  -e PGDATAOLD=/var/lib/postgresql/17/docker \
  -e PGDATANEW=/var/lib/postgresql/18/docker \
  -e POSTGRES_INITDB_ARGS="--no-data-checksums" \
  tianon/postgres-upgrade:17-to-18 \
  --check --link

Set PGDATAOLD yourself: the image defaults it to /var/lib/postgresql/17/data. Arguments that start with - go straight to pg_upgrade. If the check passes, run the same command without --check.

Pro tip: always pass the mode flag with --check. --check --link makes a test hard link between the two directories and fails with could not create hard link between old and new data directories: Invalid cross-device link if they're on different mounts. A plain --check doesn't test linking at all.

The check writes one thing: the image runs initdb into 18/docker whenever that directory has no PG_VERSION, and skips it on every later run. So after a failed check or run, delete 18/docker (only that one) before you try again. Otherwise a rerun with the checksum fix still meets the 18 cluster the failed attempt created.

Two more things the upgrade container doesn't know about your setup:

Extensions with C code (PostGIS, pgvector, pg_cron) must be installed for both majors. pg_upgrade loads every library the old cluster uses into the new one. The PostgreSQL apt repository has postgresql-18-pgvector and postgresql-18-postgis-3, so build your own image on top of tianon's when you need them.
Settings from command: postgres -c ... don't exist in the upgrade container. Pass them with -o '<options>' for the old server and -O '<options>' for the new one; a missing library in shared_preload_libraries stops the old server from starting.

Where's the point of no return? The moment pg_upgrade renames the old global/pg_control to pg_control.old. Every check, the schema dump, and the schema restore happen before that, so a failure there leaves the old cluster untouched.

Between the rename and the new server's first start, you can remove the .old suffix and start 17 again. After that first start, the docs say: restore from backup.

Step 4: Start 18 and give it what it didn't inherit

This is the step that locked my app out. Before 18's first start, copy your access rules. Then switch the Compose file to postgres:18.6, drop the PGDATA line (18's default is /var/lib/postgresql/18/docker), start it, and finish four jobs the upgrade leaves to you.

Restore client access. The official image adds a host all all all line to pg_hba.conf only when it creates a cluster. An upgraded cluster skips that, so other containers get no pg_hba.conf entry for host. That's what my app got, and blogger Rezha Julio hit it on all four instances he upgraded.

The pg_upgrade docs say the new cluster's configuration files may need adjusting to match the old one's (postgresql.conf, postgresql.auto.conf). In Docker that includes pg_hba.conf:

   # Untested. Before 18's first start.
   docker run --rm --user postgres --entrypoint sh \
     -v myapp_pgdata:/var/lib/postgresql postgres:18.6 -c '
       cp /var/lib/postgresql/17/docker/pg_hba.conf /var/lib/postgresql/18/docker/'

Your ALTER SYSTEM settings are in 17/docker/postgresql.auto.conf; re-apply the ones you still want. If you copy pg_hba.conf after 18 has started, run SELECT pg_reload_conf();.

Refresh statistics the right way. 18 carries most planner statistics across, but not extended statistics or the counters that trigger autovacuum. Run the two commands pg_upgrade prints:

   # Untested.
   docker compose exec db vacuumdb -U postgres --all --analyze-in-stages --missing-stats-only
   docker compose exec db vacuumdb -U postgres --all --analyze-only

Keep --missing-stats-only: without it, --analyze-in-stages replaces the statistics 18 just carried over with coarse ones for a while (vacuumdb docs).

Update extensions and find MD5 passwords. If an extension needs it, pg_upgrade writes update_extensions.sql to the volume root in tianon's image; run it with psql. Role passwords carry over exactly as stored, and the advisory for CVE-2026-6478 notes MD5 hashes that came along from upgrades of 13 or earlier. List them with SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%'; and have those users set new passwords.
Check collations. The images moved from Debian bookworm (glibc 2.36) to trixie (glibc 2.41), and floating tags moved on August 11, 2025. pg_upgrade keeps the old index files and the old recorded collation version. So you may see The database was created using collation version 2.36, but the operating system provides version 2.41.

Whether that changed how ordinary text sorts is unproven. The docs' rule is rebuild, then refresh (ALTER COLLATION notes). Run it before the app starts, because a plain REINDEX blocks most queries on each table it rebuilds:

   # Untested. Rebuild every database's indexes, then refresh each one's recorded version.
   docker compose exec db reindexdb -U postgres --all
   docker compose exec db psql -U postgres -c 'ALTER DATABASE <db> REFRESH COLLATION VERSION;'

Repeat the refresh for each database except template0, which records no version (template1 and postgres included). The refresh alone only silences the warning. REINDEX rebuilds every index, the same work a restore spends building them, so if your 17 ran on bookworm, budget it into your window or take Path A.

Now prove it worked.

How to check the upgrade worked

Five checks tell you the upgrade landed where you think it did. They work after either path.

# Untested. On the upgraded server.
docker compose exec db psql -U postgres -c 'SHOW server_version;'
docker compose exec db psql -U postgres -c 'SHOW data_directory;'
docker compose exec db psql -U postgres -c 'SHOW data_checksums;'
docker compose exec db psql -U postgres -c \
  'SELECT datname, datcollversion, pg_database_collation_actual_version(oid) FROM pg_database WHERE datcollversion IS NOT NULL;'
# Over the network, the way your app connects (export PGPASSWORD first):
docker run --rm --network myapp_default -e PGPASSWORD postgres:18.6 \
  psql -h db -U postgres -c 'SELECT 1;'

What you should see:

server_version starts with 18.6, or whichever 18 minor you pinned.
data_directory is /var/lib/postgresql/18/docker, inside the one mount.
data_checksums matches your choice: off if you passed --no-data-checksums, on after Path A or for a cluster that had them.
The two collation columns: if they differ, step 4's REINDEX and refresh are still due, which is expected after Path B from a bookworm cluster. Matching columns mean the recorded version equals the library's; they never prove a REINDEX ran.
The network query prints one row. no pg_hba.conf entry for host means other containers are still refused, which is the stop I hit. The exec checks above can't catch it: they use the local socket, not the network.

Then read every table once, because --link never reads your data pages. CYBERTEC's Kaarel Moppel checks that a dump to /dev/null "runs through clean": docker compose exec db pg_dumpall -U postgres > /dev/null. It reads tables, not indexes, and takes as long as a dump.

Last, cleanup. After Path B, run the delete_old_cluster.sh script pg_upgrade left in the volume root, and expect it to free almost no space: after --link, the old and new names point at the same files. After Path A, delete the old volume only once the app has run cleanly on 18. If a step stopped with a message instead, find it below.

Errors you might see, and what fixes them

Each of the first five rows points back to where this guide fixes it; the last six are rarer.

Message	Cause	Fix
`Error: in 18+, these Docker images are configured to store database data in a format...`	Old data or a mount at `/var/lib/postgresql/data`	Path A, or step 1 first
`old cluster does not use data checksums but the new one does` (or the reverse)	Checksum settings differ	Step 2, then empty `18/docker`
`could not create hard link ... Invalid cross-device link`	The clusters are on different mounts	One volume at the parent (step 1)
`no pg_hba.conf entry for host`	No rule for other containers	Step 4
`database "<db>" has a collation version mismatch`	Old C library's indexes and recorded version	Step 4: `REINDEX`, then refresh
`error mounting ... to rootfs at "/var/lib/postgresql/data"`	An 18.0-era image with the `data` symlink	Mount the parent; use a current 18 tag
`You must identify the directory where the old cluster binaries reside`	`pg_upgrade` ran inside the plain 18 image (issue #1377)	Use an image with both versions
`The source cluster was not shut down cleanly`	The old container was killed, often by a short stop timeout (tianon #27)	Start 17 on the volume, stop it cleanly, rerun
`FATAL: role "postgres" does not exist`	The cluster's superuser isn't `postgres` (tianon #88)	`PGUSER` plus `--username` (step 2)
`Your installation references loadable libraries that are missing from the new installation.`	An extension's library isn't in the upgrade image for 18	Install it; the list is in `loadable_libraries.txt`
`Only the install user can be defined in the new cluster.`	The new cluster already has extra roles, for example from `/docker-entrypoint-initdb.d` scripts when `postgres:18` was started on it first	Empty `18/docker` and let the upgrade image create it

On Dokploy, one more problem waits for the upgrade to 19.

On Dokploy: the mount that blocks an in-place upgrade to 19

Dokploy mounts a Postgres volume directly at PGDATA for 18 and later, so a --link upgrade to 19 can't happen inside that volume as it is. My 16 to 18 pg_upgrade ran on Dokploy, and my database there runs 18 today, but the routes below are the general ones, not a replay of that run. Check your own service's mount with docker inspect before you plan 19.

Dokploy's source (v0.30.8, the latest release as of October 2026) defaults new Postgres services to postgres:18. For an 18+ image, it mounts the named volume at /var/lib/postgresql/<major>/docker, so 19/docker would sit outside it.

The mount is set once, at creation. A maintainer's PR #5005 says changing the image never moves it, and that postgres:16 to postgres:18 "starts with an empty cluster"; the fix was a warning in the UI. Current Debian 18 images should refuse to start instead, as in the first section.

Platform	Where the volume mounts for 18+	`--link` to 19 in place
Plain Compose (as in step 1)	`/var/lib/postgresql`	Works
Coolify, services created on 18+	`/var/lib/postgresql` (Coolify docs)	Works
Dokploy	`/var/lib/postgresql/18/docker`	Blocked by the mount

You have two routes on Dokploy:

Dump and restore into a new 19 service. Dokploy's backups run pg_dump -Fc --no-acl --no-owner for one database, so they don't carry roles or grants. Take a pg_dumpall with the 19 tools for a full copy.
Remount, then link. Scale the service to 0, move the volume's contents into an 18/docker subdirectory (step 1's command, with 18 in place of 17 and Dokploy's volume name, <appName>-data), then change the mount to /var/lib/postgresql. Dokploy's Volumes settings can edit a mount, but its docs don't cover this route, so rehearse it on a copy.

Either way, 19 itself isn't ready yet.

Upgrading to 19: what's ready and what isn't

As of October 9, 2026, 19 is at Beta 4, with release candidate 1 planned for October 15 and general availability for October 29 (19 Open Items). There's no postgres:19 tag and no 18-to-19 upgrade image yet.

That's where the 18 layout pays off: 18/docker and 19/docker in one volume, linked in seconds. Three things to know first:

Build the upgrade image yourself until tianon publishes one: copy his 17-to-18 Dockerfile and docker-upgrade script and change the versions, including the pinned old-version package. The PostgreSQL apt repository already carries postgresql-18 next to the 19 beta packages.
The checksum choice follows you. An 18 cluster created with --no-data-checksums fails against 19's default initdb the same way. Pass the flag again, or turn checksums on in the stopped 18 cluster with 18's pg_checksums --enable, an offline rewrite of the data files. Online enabling was added to 19 and then reverted in Beta 4.
19's pg_upgrade refuses two things a 14 to 18 cluster can have: btree_gist indexes on inet or cidr columns, and carriage returns or line feeds in database, role, or tablespace names (19 release notes, beta).

Should you go on release day? 18.3 shipped out of cycle with a catalog fix that 18.0 to 18.2 users had to apply by hand, while clusters upgraded straight into 18.3 or later got it for free. So upgrade into the newest minor and treat 19.0 as a test target.

When clients ask me whether to upgrade, I say yes, before support ends, only after a tested backup, and in a quiet hour we've scheduled. On 14 or 15, don't wait for 19 at all: go to the latest 18 minor before 14's final release on November 12, 2026 (versioning policy).

When not to use pg_upgrade --link

Even when your rehearsal doesn't fit the window, think twice about --link in five cases:

You're coming from Alpine. Alpine and Debian use different C libraries and different postgres user IDs, and tianon's image is Debian-based. Take Path A.
You're also moving from bookworm to trixie. pg_upgrade keeps the old text indexes, and the docs say to rebuild them when the library changes. Budget the REINDEX from step 4, or take Path A, which rebuilds them anyway.
You haven't restored your backup. After the new server starts, it's your only rollback.
You can only afford seconds of downtime. Logical replication gets the switchover to "several seconds," per the docs, but it's a project for a small team: schema copied by hand, sequences synced by hand, no DDL during the copy.
You're moving between x86 and ARM. Upgrade on the original machine first, then move. If the data already moved, the docs' --set-char-signedness option exists for this.

The third answer that would worry me is "it's managed, not our problem." Amazon RDS and Supabase run pg_upgrade for you, and Neon has you dump and restore, or replicate, into a new project. Moving to managed Postgres doesn't remove the upgrade; it moves it to someone else's runbook, with the same "restore from backup" as the way back.

Check two lines before 19 ships

Mine went fine, under a minute down, after two stops. I've also seen the other ending, with a client: an upgrade that came up empty, and an app that couldn't connect for a few hours. My two stops are two lines you can check today, on your current server:

# Untested.
docker exec <container> psql -U postgres -c 'SHOW data_checksums;'
docker exec <container> psql -U postgres -c \
  "SELECT type, database, user_name, address, auth_method FROM pg_hba_file_rules WHERE type LIKE 'host%';"

The second (pg_hba_file_rules, superuser only) shows the rule your other containers connect through, the one an upgraded cluster won't have until you copy it. Then make the decision:

[ ] Check the mount with docker inspect (first section): one mount at /var/lib/postgresql, or, for Path B, a layout move first.
[ ] Dump and restore into a scratch volume, and time it.
[ ] It fits your downtime window: Path A, into a fresh 18 volume.
[ ] It doesn't: move to the one-mount layout on your current major, then --check --link, then the real run.
[ ] Either way: copy pg_hba.conf before 18's first start, and run the five checks after.
[ ] On Dokploy: plan the remount or a new service before 19.

Run the first command now. What it prints decides whether you pass --no-data-checksums, at 18 and again at 19.

Sources

postgres official image documentation, docker-library, accessed 2026-09-27.
Pull request #1259, version-specific PGDATA, docker-library/postgres, accessed 2026-09-27.
Pull request #1372, data symlink removed, better detection, docker-library/postgres, accessed 2026-09-27.
docker-entrypoint.sh, 18/trixie at commit e00e1bd, docker-library/postgres, accessed 2026-10-08.
pg_upgrade, PostgreSQL 18 documentation, accessed 2026-10-08.
Upgrading a PostgreSQL Cluster, PostgreSQL 18 documentation, accessed 2026-09-27.
PostgreSQL 18.0 release notes, PostgreSQL, accessed 2026-09-27.
PostgreSQL 18.3 release notes, PostgreSQL, accessed 2026-10-08.
vacuumdb, PostgreSQL 18 documentation, accessed 2026-10-08.
pg_checksums, PostgreSQL 18 documentation, accessed 2026-10-08.
ALTER COLLATION, PostgreSQL 18 documentation, accessed 2026-10-08.
CVE-2026-6478, PostgreSQL security, accessed 2026-09-27.
Versioning policy, PostgreSQL, accessed 2026-10-08.
PostgreSQL 19 Open Items, PostgreSQL wiki, accessed 2026-10-09.
PostgreSQL 19 Beta 4 Released!, PostgreSQL, accessed 2026-10-08.
PostgreSQL 19 release notes (beta), PostgreSQL, accessed 2026-10-08.
pg_hba_file_rules, PostgreSQL 18 documentation, accessed 2026-10-09.
link(2) manual page, man7.org, accessed 2026-10-08.
docker compose up, Docker documentation, accessed 2026-10-08.
docker service scale, Docker documentation, accessed 2026-10-08.
docker-postgres-upgrade, tianon, accessed 2026-10-08.
tianon issue #121, checksum mismatch, accessed 2026-10-08.
Dokploy pull request #5005, Dokploy, accessed 2026-10-08.
Configure persistent storage, Coolify documentation, accessed 2026-10-08.
How fast is pg_upgrade anyway?, Greg Sabino Mullane, End Point, 2015, accessed 2026-10-08.
PostgreSQL 18: swap mode for pg_upgrade, Daniel Westermann, dbi services, 2025, accessed 2026-10-08.
Postmortem of database outage of January 31, GitLab, 2017, accessed 2026-10-08.
Upgrade to a new PostgreSQL major version, Kaarel Moppel, CYBERTEC, 2019, accessed 2026-09-27.
Upgrading four PostgreSQL instances to 18.2 in Docker, Rezha Julio, 2026, accessed 2026-10-08.
Prevent premature startup of pg_upgrade targets, Nikolay Samokhvalov, pgsql-hackers, 2026, accessed 2026-10-08.

Tested with: nothing run for this post. Commands are assembled from the PostgreSQL 18 docs and the official image source for postgres:18.6 and postgres:17.11 (Debian trixie), plus tianon/postgres-upgrade:17-to-18, as of October 2026.

Changelog: First drafted October 2026, rewritten October 9, 2026, and published October 24, 2026.

Postgres 14 end of life: what it means for your business, and what to ask your developer

Saimul Islam — Mon, 02 Nov 2026 13:42:48 +0000

If your app runs on Postgres 14, yes, you need to upgrade, and soon. Postgres is the database many web apps keep their customers, orders, and accounts in, and version 14 stops getting security fixes on November 12, 2026. The upgrade is safe when it's done in the right order, and risky when it isn't.

Here's what a failed upgrade looked like for a client of mine. Their database was upgraded, came back empty, and the app couldn't connect. They were down for a few hours.

My own upgrade, on a database I run myself, went the other way: under a minute of downtime. It still stopped twice, once on a settings mismatch and once because the app couldn't connect afterward.

This guide is for founders and owners whose developer or agency runs their database. You'll learn whether this affects you, what's at stake, your options, and the questions that tell you your developer has it covered.

Key takeaways

Postgres 14 gets its last fixes on November 12, 2026. After that, new security problems in 14 stay unfixed.

A safe upgrade starts with a backup that someone has restored on purpose, with the time it took written down.

"Just change the version" is the risky way. If your database runs in Docker (a tool that packages it to run on a server), Postgres 18 moved where the data lives. A quick version swap can refuse to start or come up empty.

The fastest method can keep downtime to seconds or minutes, but it has no undo once the new version starts. Your restored backup is the undo.

Postgres 19 is planned for October 29, 2026 (as of October 2026). Don't put your live app on it on day one.

Table of contents

Does this affect you?
What's at stake
Why upgrades go wrong
Your options
What to ask your developer
How to tell it's done
When this doesn't apply to you
Upgrade before November, with proof
Sources

Does this affect you?

Ask your developer these four questions. Each takes a minute to answer.

Is our database Postgres, and which version? Version 14 is the urgent one. Version 13 stopped getting fixes in November 2025, and older versions before that, so they're overdue. Version 15 has until November 2027.
Does it run in Docker? If yes, the version 18 change below applies to you.
Is it on a tool like Dokploy or Coolify? These are tools your developer uses to run apps on a server you rent. Dokploy needs one extra decision before the next upgrade.
When was our backup last restored as a test? If the answer is "never," start there.

If you're on 14 or 15 and nobody has restored a backup, this is your next database job.

What's at stake

There are two risks: staying on an old version, and a botched upgrade.

Staying on 14. As of October 2026, the Postgres project's security page lists 38 security problems fixed in version 14 across its last four quarterly releases. Twenty-four of them scored 7.0 or more out of 10 on the standard severity scale. After November 12, problems like those stop getting fixed in 14 at all (PostgreSQL versioning policy).

How likely is an attack? Most of those 38 (28 of them) need someone who can already log in to the database, and none is on CISA's list of flaws known to be used in attacks (as of October 2026). So none of these is known to be under attack. The bigger risk is that every problem found after November 12 stays open.

A botched upgrade. My client's few hours looked like this: the app was down, and the database looked empty. What would a few hours of your app being down cost you?

The worse version is a backup that doesn't work when you need it. In January 2017, GitLab's backups had been failing quietly. Its public write-up of the outage says it lost over six hours of database changes, affecting roughly 5,000 projects, 5,000 comments, and 700 new user accounts.

How likely is the bad version? The research for this guide found no reliable published failure rate for database upgrades, only small, old community polls (as of October 2026). What the documented failures have in common is a skipped step: a backup nobody tested, or a version swap without moving the data.

Why upgrades go wrong

Postgres 18's official Docker setup moved where the data lives on the server. Think of a warehouse that changed which shelf it keeps your stock on. If your developer only changes the version number, the new database looks on the new shelf and finds nothing.

On current versions it then refuses to start, which is the safe outcome. On some older setups it started fresh and empty instead. The analogy stops there: your data isn't gone in that case, it's on the old shelf, as long as nobody "fixes" things by starting over.

Two more things trip people up, and they're the two stops in my own upgrade. Version 18 turns on a data safety feature by default that older databases usually don't have, so the upgrade stops with an error until your developer matches the setting. And the upgraded database starts with fresh access rules, which is why my app couldn't connect. Both are routine to fix when someone expects them.

Your developer can find the full walkthrough in the developer version of this guide.

Your options

Option	What it costs	Risk left	Who it suits
Do nothing	Nothing now	No security fixes for 14 after November 12, 2026	Nobody past November
Copy and reload (dump and restore)	Downtime while everything is copied out and back in. My test restore alone took 10 minutes (the database was a couple hundred MB)	Low: the old database stays untouched as your way back	Most small and medium apps
Fast upgrade on the same server (pg_upgrade)	Seconds to minutes of downtime, plus one-time preparation	In its fastest mode, no undo once the new version starts, except your restored backup	Bigger databases, or apps that can't be down for long
Move to a hosted database (a company runs it for you)	A monthly bill and a one-time move	As of October 2026, some providers (Amazon RDS, Supabase) run the upgrade for you; others, like Neon, leave it to you. You still schedule it and test it	Teams with nobody to own the database

How big is the speed gap? In one published test from 2015, on older versions, copying and reloading 8.5 GB took 1,927 seconds, about 32 minutes. The fast method's quickest mode took about 13 seconds at every size tested (End Point). For a small database, copy and reload is usually fast enough, and it's simpler.

My own pick for a live database is pg_upgrade, the fast method, because it's faster on big ones. On a small database, copy and reload is simpler and fast enough. A practice run on a copy shows which one you have.

When a client asks me whether to upgrade, I say yes, before support ends. But only after a backup has been restored as a test, and in a quiet hour we've scheduled.

What to ask your developer

Three answers would worry me before any database upgrade: "we'll just change the version," "we have backups" from someone who has never restored one, and "it's managed, not our problem." These questions get past all three.

"Which version are we on, and when does it stop getting security fixes?" A good answer is a number and a date: for 14, November 12, 2026.
"When did you last restore our backup, and how long did it take?" A good answer is a date and a duration. "We have backups" isn't an answer until one has been restored.
"Which upgrade method will you use, and how long will the app be down?" A good answer names the method and gives a downtime number from a practice run on a copy.
"If it goes wrong halfway, how do we get back?" A good answer is either "the old database stays untouched until we've checked," or "we restore the backup, and that takes about X minutes."
"After the upgrade, how will you check the app connects and all the data is there?" A good answer mentions logging in to the app, checking key records, and reading the whole database once without errors.
If you're on Dokploy: "Is our database set up so the next upgrade can be the fast kind?" Dokploy's default setup for Postgres 18 (as of October 2026) blocks the fastest kind of upgrade to 19. A good answer is a plan: a copy and reload, or a one-time storage change first.
"Will we move to 19 on release day?" A good answer is "no, we'll wait for the first fixes." Version 18's early months needed fixes, including one that some early adopters had to apply by hand (18.3 release notes).

If you hear "it's managed, not our problem," ask who tests the backup. Someone still has to.

How to tell it's done

Ask for proof, not a promise:

The new version number, shown by the database itself.
The restore test: the date, how long it took, and what was checked afterward.
The downtime: when the app went down and when it came back.
A check after the upgrade: logins work, recent orders or records are there, and the app's logs show no connection errors.

When this doesn't apply to you

You're already on 16, 17 or 18, with a tested backup. You have time. Plan 19 for after its first fixes.
Your database isn't Postgres. The deadline here is Postgres's. Ask your developer when your database's support ends.
A hosting company runs your database. Ask whether it runs the upgrade or leaves it to you, when, and whether you can test first.

Upgrade before November, with proof

My client was down for a few hours. My own upgrade had the database down for under a minute. Both ended with an app that couldn't connect at first. That's what questions 2, 4 and 5 are for.

Here's the decision. On 14, schedule the upgrade before November 12, 2026. On 15, you have until November 2027, and the same steps apply. Either way, start with a restored backup.

Your next step is one message to your developer with questions 1 and 2, and a link to the developer version of this guide for them. A backup you've never restored isn't a backup. It's a file you feel good about.

Sources

Versioning policy, PostgreSQL, accessed 2026-10-08.
PostgreSQL security information, PostgreSQL, accessed 2026-10-08.
Postmortem of database outage of January 31, GitLab, 2017, accessed 2026-10-08.
How fast is pg_upgrade anyway?, Greg Sabino Mullane, End Point, 2015, accessed 2026-10-08.
PostgreSQL 18.3 release notes, PostgreSQL, accessed 2026-10-08.
pg_upgrade, PostgreSQL 18 documentation, accessed 2026-10-08.
PostgreSQL 19 Open Items, PostgreSQL wiki, accessed 2026-10-09.
Dokploy pull request #5005, Dokploy, accessed 2026-10-08.
Known Exploited Vulnerabilities catalog, CISA, catalog version 2026.10.04, accessed 2026-10-08.

10 Essential Tools I Actually Use to Keep My Side Projects From Falling Over

Saimul Islam — Sun, 06 Sep 2026 12:47:56 +0000

Docker management, monitoring that goes deeper than a green dot, backups I have actually restored, and everything else that showed up once deploying stopped being the hard part.

Moving off Vercel solved exactly one problem: deploying. Everything else I used to get for free, quietly, as part of the platform, I now had to go find and wire up myself. A month into running my own server, I had a list of ten tools taped to the inside of my head, each one solving a problem I did not know I had until it happened to me at a bad time.

This is that list, in the order I actually needed them, with the mistake or the moment that made me install each one. I lean JS and Rust wherever I can, partly out of preference and partly because those are the tools that keep pace with how fast the rest of my stack moves. A couple of these are not JS or Rust at all, and I kept them anyway because they were simply the best tool for the job.

1. Dokploy, for everything I wrote about yesterday

This is the one I already spent an entire post on, so I will keep it short here. Push to main, Dokploy builds the container, Traefik points a domain at it, done. Four apps running on one $24 droplet, and adding a fifth would not move the bill. If you deploy anything with Docker and are still doing it over SSH, start here. Everything else on this list assumes you already have a platform under you, not just a server.

2. Neon, for the database half of preview environments

The first crack after Dokploy was previews. Dokploy gives every pull request its own preview URL, which is one of the nicest things about the whole setup, right up until every preview hits the same production database. I corrupted a batch of test data twice before I noticed what was happening. Neon branches Postgres the way git branches code, copy-on-write, so a preview PR gets its own preview database that costs almost nothing until it actually diverges from main. The storage engine underneath is written in Rust, and it quietly closed the other half of preview environments that nobody's setup guide mentions.

3. OpenObserve, for monitoring that actually explains itself

Dokploy's own dashboard will tell you a container is using too much memory. It will not tell you why, which request caused it, or whether it has happened before. I moved to OpenObserve for that: logs, metrics, and traces in one place, shipped as a single Rust binary, one docker-compose file to run it. The first afternoon I had it wired up, I found a query that had been running slow for three weeks, in the trace waterfall, in about four minutes. My old approach to that same investigation was grep and vibes.

4. restic, for the backups Dokploy does not know about

Dokploy's built-in backups cover Postgres, and I use them. They do not cover the config folder for my API, a SQLite file one of my smaller tools writes to, or a volume attached to a service that is not a database at all. restic backs up anything, encrypts it before it leaves the box, deduplicates so a nightly backup of a mostly-unchanged folder costs almost nothing in storage, and restores with one command I have run on purpose more than once, just to check.

restic -r s3:https://<account>.r2.cloudflarestorage.com/backups backup /var/lib/myapp
restic -r s3:https://<account>.r2.cloudflarestorage.com/backups restore latest --target /tmp/restore-test

It ships as a single static binary, which after living through more dependency hell than I would like to admit, I have come to treat as a feature in its own right.

5. Sentry, for the bugs logs make you scroll past

Logs tell you something broke. They do not tell you it broke for the same handful of users, three times a day, on the same line of code, until you have already lost interest in scrolling through them. Sentry groups the exception, attaches the stack trace, and tells me exactly which release introduced it. The self-hosted stack is heavier than I would like, but the JS SDK alone, dropped into a Next.js app, has caught more real bugs before a user reported them than anything else on this list.

6. OpenReplay, for the tickets that just say “it's broken”

A user once emailed to say a form “just doesn't work,” with no other detail, which used to mean opening dev tools and hoping I could reproduce it. OpenReplay records the session and replays it back like a video, console errors and network requests included, exactly as the user hit them. It is open source and self-hosted, and it has turned half-day investigations into two-minute videos more times than I can count.

7. Appium, for testing on an actual device instead of a hunch

Once a project had a real mobile wrapper around it, testing it by hand on my one physical phone stopped being a strategy. Appium drives real devices and simulators the same way Selenium drives a browser, through the WebDriver protocol, so the same testing habits carry over. I script the login flow and the checkout flow on both iOS and Android before every release, and it has caught two platform-specific bugs that a browser would never have shown me.

8. k6, for finding the ceiling before traffic does

A newsletter mention once doubled my traffic for six hours. The API held, barely, and I had no idea by how much margin. k6 lets me write load tests in JavaScript, the same language as the thing being tested, and run them against staging before a launch instead of finding the ceiling live.

import http from 'k6/http';
export const options = { vus: 500, duration: '2m' };
export default function () {
  http.get('https://staging.myapp.com/api/health');
}

Ten minutes to write that tells you more than any amount of guessing.

9. Infisical, for replacing a very bad system

My “secrets management” before this was environment variables pasted into Dokploy's UI and, if I am honest, a couple of .env files sitting in a private Slack channel. Infisical is open source, written in TypeScript, and gives every project versioned secrets, per-environment values, and an audit log of who changed what. Rotating a leaked key used to mean a search-and-replace across three servers. Now it is one dashboard and a redeploy.

10. n8n, for the glue that runs everything else

n8n is the part that quietly holds the other nine together. When OpenObserve crosses an alert threshold, when a restic backup fails, when a new signup needs a welcome sequence, n8n is the thing that notices and does something about it, wired together as a workflow instead of a script I will forget I wrote. It runs on Node, it is free to self-host, and it is the tool I have extended the most since installing it, because every new problem seems to end with “I should probably wire that into n8n.”

So, is this too many tools for a side project?

Maybe. Ten tools running on one box is still one box, and the more of these you add, the more you are choosing to own instead of rent. What changed for me is that each one solves a problem I actually had, in the order I actually had it, rather than a checklist I installed on day one and mostly ignored. If you are one platform migration into doing this yourself, start with whichever one of these already hurts.

Sources and further reading

Stop Paying for Vercel: How to Self-Host Your Deployments on a VPS and Keep the Same Workflow

Saimul Islam — Fri, 04 Sep 2026 05:19:58 +0000

Push-to-deploy, automatic HTTPS, and preview environments on a $24 droplet with Dokploy, plus the four mistakes to skip on the way.

For two years, deploying was the easiest part of my week. I pushed to main, closed my laptop, and the site updated itself. I never thought about servers, which was the entire point of paying for it.

Then I opened the invoice.

$198 for the month. I read it twice, because the number did not match what I was running: a Next.js frontend with a few thousand monthly visitors, a small API moving JSON around, one Postgres database holding a couple hundred megabytes, and a nightly cron job. Four small things, and I knew that launching a fifth would push the bill up again.

Here is what is worth understanding before you decide whether any of this applies to you. You are not paying managed platforms for compute. Compute is cheap. You are paying because somebody else already set up the reverse proxy, the TLS certificates that renew themselves, and the pipeline that turns a git push into a running container. That is real work, and it was worth every cent for two years. So the question got narrower: is it still worth it, now that I know which of those features I actually use?

What follows is the whole setup, end to end: installing Dokploy, connecting your Git provider, getting deploys on every push, domains with automatic HTTPS, object storage for user files, scheduled backups, and monitoring. The workflow you land on is the one you already have. You push to main, you close your laptop, and the site updates itself.

It took me a weekend, and I have left all four of my mistakes in, because those are the parts no documentation warns you about. If you can ship an application but have never really run a server, this is written for you.

Why My First Attempt at This Failed

My first instinct was to do it entirely by hand, and that failure is the reason Dokploy made sense to me later. I rented a VPS, installed Node, set up PM2 to keep the process alive, hand-wrote an Nginx config, and ran Certbot for a certificate. I felt clever for about four days.

Then deploying turned out to mean SSH-ing in to run git pull, which is fine right up until you are doing it from your phone because something has broken. No build logs, no deployment history, and a rollback plan that was really just hope. Adding a second app meant another Nginx block, another port, another process to babysit.

The problem was never that servers are hard. It was that I had hand-built a worse deployment platform and was now responsible for maintaining it. Once I wrote down what I actually wanted, it became shoppable: something that handled the reverse proxy, the certificates, the builds, the restarts, and the rollbacks, on hardware I paid for directly. That is what Dokploy is. So I went and got a server to put it on.

Choosing the Server, and the Mistake I Made in the First Hour

I went with DigitalOcean. Hetzner, Vultr, and OVH are all fine too, and cheaper if you are optimising purely on price, but I already had projects there and wanted one dashboard rather than four.

Dokploy says the minimum is 2GB of RAM. That is technically true and practically a trap, because you build your application on the same box you deploy to.

I found out the hard way. My first build died on the $12 droplet. Not failed, died. The log stopped part way through with no error, and I spent twenty minutes blaming my Dockerfile before finding the kernel had killed it for using too much memory. Skip the entry tiers and start on the 4GB droplet at $24, which fits the app, the database, and the build at once. Ubuntu 24.04, because boring is correct here.

One more thing before you install anything, and I nearly skipped it. Ten minutes on the basics: SSH key instead of password login, password login disabled, firewall with ports 22, 80, 443, and 3000 open. When I checked my auth log a day later there were thousands of failed login attempts. Nobody knew my server existed. That is simply what the internet does to a public IP.

With the box locked down, the install itself is almost anticlimactic.

Installing Dokploy Takes One Command

curl -sSL https://dokploy.com/install.sh | sh

A few minutes of output, and it is done. It is worth seeing what that script did for you, because you now own a real stack rather than a magic box. It installed Docker, set up Swarm mode so containers restart on their own when they die, deployed Traefik as your reverse proxy, and started a small database for Dokploy itself. Every one of those I configured by hand the first time, and got wrong at least once.

Open your server IP on port 3000 and create an admin account. Then, before deploying anything, point a subdomain like panel.yourdomain.com at the server, give the dashboard that domain, turn on HTTPS, and close port 3000. Your control panel should not sit on an open IP with only a password in front of it.

You now have a platform. What it does not have yet is your code.

Connecting GitHub Is the Decision That Pays Off Later

Dokploy pulls your code two ways, and the choice matters more than it looks at the time. The first is a generic Git connection over SSH, which works with GitLab, Bitbucket, Gitea, or anything else that speaks SSH. Generate a key in the SSH Keys section, add the public half to your provider, and use the git@ URL rather than https.

The second, if you are on GitHub, is the Dokploy GitHub App. Two extra minutes, and it is the best decision in this story. That single step gave me automatic deploys on push, watch paths, and preview environments for pull requests, with no further configuration. Those are exactly the three things people assume they give up when they leave managed hosting, and this is where you keep them. Click the right button early, because switching later is far more annoying.

Then create a project, pick your repository and branch, and paste your environment variables into a box that works like a .env file. One detail that confused me: Dokploy clones the repository onto your own server and builds it there, which is why server memory mattered so much a moment ago.

Then I hit deploy. And then I hit it three more times.

My First Three Deploys Failed, and That Was the Useful Part

Every tutorial I read showed a green checkmark on the first attempt, so when mine went red I assumed something was structurally wrong. It was not. Three ordinary mistakes, each of which explained a piece of how the system fits together.

1. The Port

The build worked, the container started, and the site returned a gateway error, because I had never told Dokploy which port my app listens on. That field lives in the domain settings rather than the build settings, which is why I missed it. The lesson is worth keeping: your app is never exposed to the internet directly. Traefik forwards public traffic inward, which is why you never open your app port in the firewall.

The path a request takes, and why the container port lives in the domain settings.

2. Missing Environment Variable

The second was a missing environment variable. It built fine and crashed on startup, and the container log said so in its first line while I was staring at the build log. Those answer different questions: why it would not compile, versus why the compiled thing will not run.

3. The Build Type

The third was the build type, which is how Dokploy turns your repository into a running app at all. There are five options, and the default guesses for you.

If your project is	Choose
A standard Next.js, Django, or Laravel app	Railpack, the modern default, or Nixpacks if it gives you trouble
Already carrying a Dockerfile you trust	Dockerfile, for full control including build secrets
A static site from Vite, Astro, or Hugo	Nixpacks with a Publish Directory, or Static if pre-built
Being moved directly off Heroku	Buildpack, using your existing Heroku or Paketo config

I switched to a Dockerfile because my build needed a step the automatic builders were skipping. Fourth deploy, green checkmark. The site loaded, at an IP address, which did not feel like it counted yet.

Giving It a Real Domain and Free HTTPS

This happens in two steps, and doing them in the wrong order caused my next mistake. At your registrar, create an A record pointing your domain at the server IP. Then in Dokploy, open your app, go to Domains, and add one. Set the Host, Path, and Container Port, flip the HTTPS toggle, choose Let’s Encrypt, and the certificate and its renewal are handled from then on.

My mistake was enabling HTTPS fifteen seconds after creating the DNS record. Let’s Encrypt tried to verify I owned the domain, found nothing, and failed with an error that never mentioned timing. Run dig +short yourdomain.com first, and only enable HTTPS once it prints your server IP back.

One more trap catches a lot of people. If your DNS is on Cloudflare, the orange cloud means Cloudflare is proxying your traffic, and verification fails with an error that never mentions Cloudflare either. Set the record to DNS only until the certificate is issued, then switch proxying back on if you want it.

While you are in the dashboard, add Postgres too. Resist the urge to expose its port, because open database ports are among the most scanned things on the internet. Your app reaches it by service name over the internal Docker network, as in:

postgresql://user:pass@my-app-db:5432/mydb

And that was the setup finished. Custom domain, valid certificate, deploys on push, a database, all for $24 a month. It ran perfectly for two weeks, which is when the real education started.

Two Weeks In: The Monorepo Problem

The first crack was small. My repo is a monorepo, and every push rebuilt everything in it. I would fix a typo in a markdown file and watch three services redeploy and send me notifications for things that had not changed.

Watch paths fix this. In your app’s Git settings you list the files and folders that app actually cares about, and it only rebuilds when something inside them changes:

apps/web/**
packages/ui/**
!apps/web/**/*.md

Two asterisks match across directories, and a leading exclamation mark excludes. One caveat before you go debugging: this works out of the box on GitHub, but on GitLab, Bitbucket, or Gitea you need automatic deployment working first, because watch paths filter automatic deploys. With nothing to filter, they look ignored.

That one was an annoyance. The next one was not.

Three Weeks In: The Day All My User Uploads Disappeared

I shipped a routine change, nothing dramatic, and somebody told me their profile picture was gone. Not just theirs. Every file any user had uploaded since launch.

The cause is obvious in hindsight and catches almost everyone new to containers. I had been saving uploads to a folder inside the application, so when I deployed, Dokploy built a fresh container from my repository and replaced the old one. My repository does not contain user uploads. Containers are meant to be disposable, and that is exactly what makes deploys and rollbacks safe. My mistake was putting data that has to survive inside a thing designed not to.

Why the uploads vanished, and where they should have been living instead.

For user files the answer is object storage, and I picked Cloudflare R2 for one reason: it charges nothing for egress. Everyone else charges you to read your own files back out, and that cost scales with traffic rather than storage. R2 is $0.015 per GB per month with zero egress, against roughly $0.023 per GB plus $0.09 per GB egress on S3, and the free tier covers 10GB and 10 million reads a month.

Best of all, R2 speaks the S3 API. Create a bucket, generate an API token with Object Read and Write, note your account ID, and point your existing S3 client at it:

import { S3Client } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  region: "auto",
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: { accessKeyId, secretAccessKey },
});

Setting that up turned out to be lucky, because a few days later I needed somewhere to put backups.

The Night I Realised I Had No Backups at All

I was running a migration late one night, and for about ninety seconds I believed I had destroyed my users table. I had not, in the end. But in those ninety seconds I went looking for my backups and found something worse than a bad migration. There were none. Three weeks of production data, not a single copy anywhere.

The embarrassing part is that Dokploy had this built in the whole time, in a tab I had scrolled past a dozen times. On the schedule you set, it runs a proper database dump, the same pg_dump you would run by hand, and ships it to S3-compatible storage. Which is why the R2 bucket from the last section quietly became my backup destination too, on the same free tier.

Add the destination once under Settings, then Destinations, using your R2 access key, secret key, bucket, the region set to auto, and the same endpoint as above. Hit the test button before you trust it, because a destination that fails silently is worse than none. Then open your database, go to Backups, and set a schedule. I use 0 3 * * * for daily at 3am.

Now the part that matters more than everything above it. A backup you have never restored is not a backup, it is a file you feel good about. The week after setting this up I spun up a throwaway Postgres service and restored into it on purpose. Ten minutes, and it worked. Do that once while nothing is on fire. Then be as pleased with yourself as I was, right up until you try to back up the next thing.

What to Do When There Is No Database to Back Up

My other service had no database. It kept its state in a folder, which is the shape of anything using SQLite or any self-hosted tool with a working directory, so the backup feature had nothing to point at.

Dokploy handles this with volume backups, which meant finally understanding a distinction I had been ignoring. A bind mount points at a folder on the host machine. A named volume is storage Docker itself creates and manages, referred to by name. I assumed that was stylistic. It is not, because volume backups only work with named volumes, so a bind mount means migrating first.

Creating one is easy. Go to Advanced, then Mounts, and add a Volume Mount with a name like app_data and the path where it appears inside the container. One detail that will confuse you at restore time: for Compose services, Dokploy prefixes the volume name with the app name, so app_data exists as myapp-abc123_app_data.

You also choose whether to stop the container while the backup runs. Stopping is safer, since nothing is writing while files are copied. I stop mine, because forty seconds of downtime at 3am costs nothing and a corrupted backup would cost a great deal.

The finished storage setup: uploads written live, database and volumes backed up on a schedule, all into one bucket.

With that, my data was safe. So naturally the server got slow.

A Month Later: Why Is Everything Suddenly Slow?

Everything got sluggish at once, across all my apps, which is the least helpful symptom possible because it tells you the problem is shared and nothing more.

Under my old setup I would have SSH-ed in, run top, squinted at container-generated process names, and guessed. Instead I opened the dashboard, where every application has its own view of CPU, memory, disk, and network usage. I found the culprit in two minutes: a background job in my API had a runaway loop and was eating almost all the memory on the box. Live logs and deployment history did the rest. A surprising number of mysteries resolve the moment you notice the slowdown began at the exact minute of a deploy.

I fixed the loop, obviously. More usefully, I set a memory limit on that app under Advanced, then Resources, so it can never take the whole server down again. If it exceeds the limit it restarts rather than consuming everything around it. I now set limits on everything at double normal usage, plus alert thresholds pointed at Discord so the server tells me before a user does.

Worth being straight about the limits. Self-hosted gives you per-container metrics, logs, deployment history, resource limits, and threshold alerts. The advanced dashboard is part of Dokploy’s paid cloud tier. For a handful of apps the built-in view is plenty, and if you outgrow it, Dokploy ships a Prometheus extension as a template that gives you Grafana on the same box.

That is the last of my four mistakes. One more warning, though, and it is the thing that quietly kills self-hosted setups around the three month mark.

The Thing That Will Break in Three Months

Your disk will fill up. Every deploy builds a new Docker image, and old images and build caches do not delete themselves. You go from comfortable to out of space with no warning at all, and your deploys start failing with errors that never say "disk full".

df -h                    # how much space is left
docker system prune -af  # remove unused images and caches

Run that occasionally, and update Dokploy itself from the dashboard every month or so, since it is your software now.

So, Was It Worth It?

$198 a month became $24, and R2 is still inside the free tier. It cost me a weekend including every mistake above, and about thirty minutes a month since. Nothing about my day-to-day changed: deploy on push, automatic HTTPS, preview environments, and one-click rollbacks all survived the move. That droplet now runs four applications instead of one, and adding a fifth would not change the bill.

What I gave up is real, and I would rather say it plainly than sell you something. One server is one point of failure, and if the machine dies, everything on it is down until I bring it back. My answer is backups I have actually tested, and knowing a fresh server plus a restore is a couple of hours rather than a catastrophe.

So do not do this if you are pre-launch and your only real job is shipping features, because every hour on infrastructure then is an hour not spent finding out whether anyone wants the thing. Do not do this if nobody can respond when the server has a problem, because a managed platform is partly an on-call rotation you are renting. And if your traffic is global and latency-sensitive, remember that one server is in one place.

What I got beyond the money mattered more than I expected. Deployment used to be a black box I posted code into and hoped about. Now I know what a reverse proxy does, why containers are disposable, and where my data actually lives. The anxiety about next month’s bill is gone too, not because $24 is nothing, but because it does not move when I have a good week.

If you want to try this, rent a box, spend ten minutes on SSH keys and a firewall, run one install command, and deploy something small you would not mind breaking. Give yourself an afternoon. Worst case, you destroy a server costing a few dollars and start again, which is a cheap way to learn how your own infrastructure actually works.

DEV Community: Saimul Islam

How to upgrade Postgres in Docker to 18, and be ready for 19: dump and restore or pg_upgrade --link

Why the Postgres 18 image moved your data

Dump and restore or pg_upgrade --link: let one timed rehearsal decide

Before either path: rehearse on a copy and time it

Path A: dump and restore into a fresh 18 volume

Path B: pg_upgrade --link in four steps

Step 1: Move your volume into the one-mount layout

Step 2: Check data checksums and the superuser

Step 3: Run pg_upgrade --check --link, then the real run

Step 4: Start 18 and give it what it didn't inherit

How to check the upgrade worked

Errors you might see, and what fixes them

On Dokploy: the mount that blocks an in-place upgrade to 19

Upgrading to 19: what's ready and what isn't

When not to use pg_upgrade --link

Check two lines before 19 ships

Sources

Postgres 14 end of life: what it means for your business, and what to ask your developer

Does this affect you?

What's at stake

Why upgrades go wrong

Your options

What to ask your developer

How to tell it's done

When this doesn't apply to you

Upgrade before November, with proof

Sources

10 Essential Tools I Actually Use to Keep My Side Projects From Falling Over

1. Dokploy, for everything I wrote about yesterday

2. Neon, for the database half of preview environments

3. OpenObserve, for monitoring that actually explains itself

4. restic, for the backups Dokploy does not know about

5. Sentry, for the bugs logs make you scroll past

6. OpenReplay, for the tickets that just say “it's broken”

7. Appium, for testing on an actual device instead of a hunch

8. k6, for finding the ceiling before traffic does

9. Infisical, for replacing a very bad system

10. n8n, for the glue that runs everything else

So, is this too many tools for a side project?

Sources and further reading

Stop Paying for Vercel: How to Self-Host Your Deployments on a VPS and Keep the Same Workflow

Why My First Attempt at This Failed

Choosing the Server, and the Mistake I Made in the First Hour

Installing Dokploy Takes One Command

Connecting GitHub Is the Decision That Pays Off Later

My First Three Deploys Failed, and That Was the Useful Part

1. The Port

2. Missing Environment Variable

3. The Build Type

Giving It a Real Domain and Free HTTPS

Two Weeks In: The Monorepo Problem

Three Weeks In: The Day All My User Uploads Disappeared

The Night I Realised I Had No Backups at All

What to Do When There Is No Database to Back Up

A Month Later: Why Is Everything Suddenly Slow?

The Thing That Will Break in Three Months

So, Was It Worth It?

Sources and Further Reading