Dokploy can deploy Git repositories or Docker Compose projects to your own server. You still own the VPS, databases and containers; you just hand the repetitive deployment work to the panel.

It suits these scenarios:

• You want to self-host a Vercel, Heroku or Railway alternative on a VPS;
• You need continuous deployment from GitHub, GitLab, Gitea or Bitbucket;
• You run multiple websites, APIs, workers and databases on one server;
• You want a unified view of build logs, container status, domains and certificates;
• You don't want to maintain Kubernetes from the start.

If you only run a single long-lived container, a Docker Compose production configuration is usually simpler. Dokploy's value lies in multiple projects, frequent releases and team collaboration.

Dokploy's official current recommendation is at least 2GB of memory and 30GB of disk. That's only the starting point for a smooth install and build, not a guarantee that every application fits in 2GB.

Building Next.js, Java or Rust images significantly increases momentary memory and disk usage. On a tight budget, start from 4GB rather than letting build processes and databases fight over the last few hundred MB of memory. For a more detailed selection method, see How to choose VPS specs.

The test systems listed in the official docs include Ubuntu 20.04/22.04/24.04 LTS, Debian 10/11/12, Fedora 40 and CentOS 8/9. For new deployments, prefer an Ubuntu LTS or Debian 12 that is still within its maintenance period.

Prepare a clean public VPS and confirm:

1. You can log in via SSH and obtain root privileges;
2. The domain's A record points to the VPS public IPv4;
3. TCP 80, 443 and 3000 are not occupied by Nginx, Caddy, Apache or another panel;
4. The cloud provider's security group and the system firewall allow access to these ports during installation;
5. The disk has at least 30GB of free space.

Check the ports first:

sudo ss -lntp | grep -E ':(80|443|3000)\b' || true

If there is output, first determine whether the existing service can be migrated. Dokploy uses Traefik to take over 80 and 443, so installing directly on a machine already running a website easily causes port conflicts. For production migrations, prepare a new machine or a maintenance window first.

Run the official install script in a root shell:

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

If the server doesn't have Docker yet, the install script installs it automatically. When it finishes, visit in your browser:

http://你的服务器IP:3000

Create the administrator account immediately. Don't expose port 3000 to all sources long-term; finish the panel domain and HTTPS first, then close the public IP plus port entry point.

If installation fails, check first:

docker version
docker info
docker service ls
docker ps
sudo ss -lntp | grep -E ':(80|443|3000)\b'

Dokploy uses Docker Swarm. If the cloud server has multiple network cards or auto-detection is wrong, you can explicitly specify the advertise address:

curl -sSL https://dokploy.com/install.sh | sudo ADVERTISE_ADDR=你的服务器IP sh

First prepare a dedicated subdomain for the panel, for example deploy.example.com, and point its A record to the VPS. Go to Dokploy's Domains settings, add the domain and enable the certificate.

After confirming you can log in normally at https://deploy.example.com, remove the public mapping of IP:3000 as the official recommendation suggests:

docker service update \
  --publish-rm "published=3000,target=3000,mode=host" \
  dokploy

The order matters. If you remove port 3000 before the domain or certificate takes effect, you may lock yourself out of the panel.

In the end, the firewall only needs to expose the necessary ports to the public internet:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

For a more complete SSH, Fail2Ban and firewall strategy, see the VPS security hardening guide.

Create a Project in Dokploy, then add an Application. The common flow is:

1. Connect GitHub, GitLab, Gitea or Bitbucket;
2. Select the repository and production branch;
3. Choose the build method, such as Dockerfile, Nixpacks or static site;
4. Fill in the container port the application listens on;
5. Add environment variables;
6. Click Deploy and watch the build and runtime logs;
7. Add the application domain and enable HTTPS.

The application must listen on 0.0.0.0 inside the container, not only on 127.0.0.1. For example, a Node application should listen on the PORT passed in by the platform, otherwise the container may show as running but Traefik can't reach it.

Don't commit .env, database passwords or API keys to Git. Put production variables in Dokploy's environment variable settings, and distinguish build-time variables from runtime variables. After changing variables, redeploy and confirm the new container actually loaded the new values.

Application domains in Dokploy are configured dynamically through Traefik; Docker Compose projects usually need to be redeployed after changing a domain so Traefik re-reads the labels.

Troubleshooting order:

dig +short app.example.com
curl -I http://app.example.com
docker service ls
docker service ps 服务名
docker service logs 服务名 --tail 100

Focus on confirming four things:

• Whether DNS really points to the current VPS;
• Whether 80/443 are blocked by the security group or UFW;
• Whether the container port is set to the port the application actually listens on;
• Whether the application process listens on 0.0.0.0.

If you need to understand automatic certificates and the reverse proxy chain, continue with the Caddy automatic HTTPS guide. The two are implemented differently, but the diagnostic approach for DNS, ports and upstream listening is the same.

"The container is running" in the panel doesn't mean your data is safe. You should protect at least three types of data separately:

1. Dokploy's own PostgreSQL and /etc/dokploy;
2. Business databases;
3. Uploaded files or SQLite data in Docker named volumes.

Dokploy's system backups require an S3-compatible destination to be configured first. System backups package Dokploy's PostgreSQL and /etc/dokploy, then upload them to object storage. Business databases should have separate scheduled backups; applications using named volumes should also enable Volume Backups.

Don't put the backup destination on the same disk as the VPS, or the backups will be lost along with the server if it fails. Do a restore drill at least once a quarter to verify credentials, archives and restore steps. You can directly apply the VPS backup and restore drill checklist.

The official command to update to the latest version is:

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

Don't run updates the moment you see them in production. Complete system and database backups first, read the release notes, then choose a low-traffic window to update. Application releases should have health checks configured; only with health checks does Docker Swarm have a reliable basis to stop a bad version or perform a rollback.

Also make sure to:

• Use key-only SSH login, disabling password and root remote password login;
• Enable HTTPS on the panel domain and don't expose 3000 long-term;
• Limit team member permissions and don't share the administrator account;
• Don't map databases directly to the public internet;
• Regularly clean up unused images and build caches, but don't accidentally delete data still in use by Volumes;
• Set alerts for disk, memory, certificate and backup failures.

Portainer is more of a container manager, while Dokploy and Coolify are more like deployment platforms. If you want to directly manage Stacks, containers, networks and logs, read the Portainer Docker management panel tutorial.

What's most appealing about Dokploy isn't "one-click install" but putting Git, builds, containers, domains, certificates, databases and backups into one repeatable release process. The truly production-ready approach is: start from a clean VPS with at least 2GB/30GB, solve ports and DNS first, then deploy applications, and finally complete external backups, health checks and access control.

If you plan to run multiple projects long-term, choose 4GB of memory and an NVMe disk directly, and complete a drill restoring Dokploy from an S3 backup before your first business goes live.

• Dokploy installation docs
• Dokploy domain configuration
• Dokploy system backups
• Dokploy Volume Backups