Dokku gives you a tiny Heroku; you still own production

“Deploy this open-source repo” sounds like one task. In practice it is four: run the process, preserve its state, expose it safely, and recover it after failure. Dokku can make the first task beautifully easy while moving the other three into platform-specific services and limits.

This is not an argument that Dokku is bad. It is an argument for reading the runtime contract before trusting a green deploy button.

The constraint that changes the architecture

According to Dokku's current documentation, Git-push deployment on a server keeps the platform compact and understandable. That is a product boundary, not a bug. It becomes painful when the open-source project was designed around ordinary Linux assumptions.

A typical self-hosted repository may expect:

• a continuously running web process and one or more background workers;
• a Docker volume mounted at a stable path;
• local uploads, SQLite, or generated files;
• arbitrary TCP ports or a long-lived WebSocket server;
• a maintenance command run from the same filesystem and network;
• shell access that matches the production runtime.

Every assumption that does not fit must be replaced by another service, integration, or operational procedure. The app may still work well—but “one-click hosting” stops being a useful description.

When Dokku is the right choice

Dokku is a strong fit for developers comfortable operating one Linux host. Managed deployment, TLS, logs, and scaling can remove an enormous amount of undifferentiated work. If the application already externalizes state and respects the platform's lifecycle, using a raw VM can be needless toil.

The mistake is choosing from the homepage instead of the failure model. Ask what happens during a restart, deploy, regional incident, storage exhaustion, and account lockout. A platform is easy when those answers match the software.

Why open-source applications expose the gap

plugins simplify databases and certificates, but recovery, upgrades, capacity, and host security remain operator work. The repository's quick-start usually optimizes for a developer laptop: one Docker network, one local volume, and every service available on localhost. Production adds independent backups, secrets, TLS, monitoring, upgrades, and capacity.

The sharp critique of hosting platforms is not that they charge money. Infrastructure should cost money. It is that a simple deployment UI can hide the architectural translation users are now responsible for. When the translation is undocumented, the first real lesson arrives during an outage.

A VPS is not automatically better

A VPS preserves normal Linux semantics: systemd, files, sockets, Docker volumes, cron, and SSH. It also hands you patching, firewall policy, intrusion response, disk growth, backups, and every 3 a.m. page. Root access is freedom and an invoice for operational ownership.

Use a VPS when the software fits one host cleanly, the team understands Linux, and predictable resources matter more than automatic scaling. Use Dokku when the application fits its contract and managed operations are worth the extra services.

A migration checklist before committing

1. List every process in the project's compose file.
2. Mark every writable path and decide where it persists.
3. Identify background jobs and maximum runtime.
4. Test WebSockets, uploads, email, and private networking.
5. Perform a backup and restore before real data arrives.
6. Price the complete stack, not only the web process.
7. Document how an operator gets logs and a shell during failure.

The operator still needs a control plane

Whether you choose Dokku or a VM, incidents eventually cross a boundary that dashboards do not explain. DNS resolves but TLS fails. The app is healthy but the database refuses connections. A persistent disk is full. That is when an ordinary SSH path and a disciplined diagnostic workflow still matter.

Tryssh is a native Mac SSH workspace with an agentic copilot. It runs read-only investigation automatically, shows exact mutating commands for approval, and keeps SSH keys in the macOS Keychain. It does not make self-hosting free; it makes owning the host less chaotic.

Prepare for the failure path

Pair this deployment decision with the SSH hardening checklist and the website-down incident runbook. Hosting is only finished when the team can enter the system safely, recover its data, and restore service under pressure.