A Dokploy Alternative Without Swarm or Traefik on Your Server

Dokploy and Shipown both deploy apps to servers you own, from opposite ends. Dokploy is an open-source web panel you install on a server with a curl script; it sets up Docker Swarm, Traefik and its own PostgreSQL there and runs your apps as containers. Shipown is a desktop app for Windows and Linux that deploys over SSH with no agent on the server, running Node apps directly under PM2 and static sites from Nginx, and deploying Dockerfile and Compose apps when you want containers.

Dokploy fits teams that want a browser dashboard, Compose-native deploys, templates and the option of a multi-node Swarm. Shipown fits developers who want their servers to stay plain Linux and their deploy button on their own machine. The Dokploy facts here were checked against its site, documentation, install script and source code in October 2026.

What is Dokploy?

Dokploy is a self-hosted deployment panel. You install it on your own server with a curl script, or use Dokploy Cloud, a managed panel with a 7-day trial. Either way, your apps run on your servers. The installation docs ask for at least 2 GB of RAM and 30 GB of disk on the panel host (Dokploy installation).

The install script does a fair amount of setup. It installs Docker if it is missing, runs docker swarm init, creates an overlay network, and starts PostgreSQL 16, the Dokploy service and Traefik v3. Servers you add later are prepared as well: according to Dokploy's source code, remote-server setup installs RClone, Docker, Swarm, Traefik, Nixpacks, Buildpacks and Railpack (Dokploy remote servers). Node apps are built with Nixpacks, Heroku Buildpacks or a Dockerfile and run as containers, and Docker Compose is supported natively.

Beyond deploys, Dokploy offers multiple servers and multi-node Docker Swarm, one-click templates such as Supabase, Cal.com and PocketBase, databases (MySQL, PostgreSQL, MongoDB, MariaDB and Redis) with backups, CPU, memory and network monitoring with alerts, roles and permissions, preview deployments, and deploys from git and webhooks. Rollback comes in two forms: Docker Swarm rolls back by itself when a health check fails, and you can roll back by hand to an earlier deployment when an image registry is configured (Dokploy rollbacks).

You use Dokploy through a web dashboard, an API or a CLI. Its "AI Generate" feature writes a Docker Compose file from a plain-language description, using your own key for an OpenAI-compatible provider; OpenAI, Anthropic, Ollama, OpenRouter and Azure OpenAI are named. Its homepage also mentions an MCP connection. The open-source edition is licensed Apache-2.0, apart from a /proprietary directory.

Why developers look for a Dokploy alternative

Dokploy's design makes sense for anyone who wants a cluster they can grow. The reasons people look for something else come from that same design: what it installs, and what it takes to run.

Swarm, Traefik and PostgreSQL on the panel host

Installing Dokploy runs docker swarm init, so the host becomes a Swarm manager with an overlay network, Traefik v3 in front, and PostgreSQL 16 alongside the Dokploy service. That is a sound base for multi-node deployments. On a single VPS serving one Next.js app, it is several more layers to understand when a request fails: the app container, the Swarm service, the overlay network and the proxy.

Each added server gets its own toolchain

Adding a remote server is more than an SSH connection. Per Dokploy's source code, setup installs RClone, Docker, Swarm, Traefik, Nixpacks, Buildpacks and Railpack on it. If you prefer to keep a server down to the packages your apps actually use, each of those is software you will be updating and accounting for on that machine.

2 GB of RAM and 30 GB of disk for the panel

The panel host needs at least 2 GB of RAM and 30 GB of disk. On a small VPS, the panel's share of memory and disk comes out of what your apps could otherwise use, and on Dokploy Cloud the per-server fee replaces that cost rather than removing it.

Rolling back by hand needs an image registry

Swarm's automatic rollback covers a deploy whose health check fails. Going back on purpose to an earlier deployment, for example after a bug that passed its health check, requires an image registry to be configured. For a small project, that is one more service to set up before manual rollback is available.

Every Node app is a container

Dokploy builds Node apps with Nixpacks, Heroku Buildpacks or a Dockerfile and runs them as containers. If you want a Next.js app running as a PM2 process, with PM2's logs and restart policy, that is not the model Dokploy is built around.

How Shipown works differently

A desktop app instead of a cluster manager

Shipown runs on your Windows or Linux computer and talks to servers over plain SSH. It does not create a Swarm, start a proxy container or run a database for itself, and it installs no agent. Gauges are read from /proc over SSH, and Ubuntu, Debian, the RHEL family and Alpine are handled. When a server is missing something your apps need, setup offers it: PM2 preparation, Docker, or a Domains & HTTPS installer for Nginx and Certbot. Connecting your first server takes a host, a port, a user and a key or password, and the connection is tested before anything is saved.

The runtime that fits each app

Dokploy treats Compose as a first-class deploy type, and Shipown deploys Compose files too. Point it at a repository or folder with a Dockerfile or a Compose file, and either build on the server or build images for the server's platform with Linux Docker on your PC, which are sent over SSH for docker load without a remote rebuild. Containers are published behind Nginx (Docker deploys). Docker is one option of three, though. Node apps such as Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify and Express run directly under PM2, and static sites from Vite, Astro or plain HTML are served straight from Nginx, with no process, no port and nothing to restart. The Docker module docs cover managing the containers already on a server.

Rollback from release directories, with no registry for Node and static apps

Every Shipown deploy lands in its own release directory, and the live pointer moves only after the build and the health check pass. If a deploy fails, the previous release comes back by itself. If a bad release passes its health check, rolling back is choosing an earlier release in the app. Node and static apps have no images, so no registry is involved. For containers, the previous container is kept until the new one passes its health check, images are labelled with the commit they came from, and retained images support rollback. The guide to rolling back a deployment on a VPS explains the release-directory pattern in general.

AI that works on the live server

Dokploy's AI Generate writes a Compose file for you. Shipown's AI terminal works on the running server instead. With your own Anthropic, OpenAI or DeepSeek key (Claude Opus 5, Claude Sonnet 5, GPT-5.4 and DeepSeek V4 Pro are among the choices), you describe a symptom, and the model inspects the server and proposes one shell command at a time with its reason. Nothing runs until you approve it, and destructive commands such as recursive deletes, reboots, firewall flushes or stopping SSH are always held for confirmation.

Branch tracking instead of auto-deploy

Shipown does not deploy on push; a person presses deploy. What it does is track the branch: it reads the commit each deployment is running on the server, compares it with the branch on GitHub, and puts the number of waiting commits on the deploy button. Promoting from staging ships the exact commit staging ran, not whatever the branch points to by the time the deploy runs.

A live feed without a collector

Dokploy monitors CPU, memory and network and sends alerts. Shipown's live feed streams Docker events over the SSH connection you already have, so a container that exits, runs out of memory or turns unhealthy shows up in about a second, and a crash loop is reported once as a loop. PM2 apps are re-read every fifteen seconds, and a server that stops answering is reported once, with its recovery reported too. The trade-off is that these checks run from the desktop app, so it must be running and your PC awake.

Dokploy vs Shipown: feature comparison

Pricing compared

Prices are as of October 2026, from Dokploy pricing. Annual billing saves 20% on Dokploy's paid plans. Whichever you choose, the servers your apps run on are paid to your provider on top.

Shipown is a free trial, then a paid licence for a fixed period that does not renew by itself; current prices are on the pricing page. Self-hosted Dokploy costs nothing beyond the server it runs on, and if price is the deciding factor, that matters.

When Dokploy is the better choice

• You plan to run more than one node and want Docker Swarm managed for you, or your apps already live in Compose stacks.
• You want deploys from git pushes or webhooks, and preview deployments for review.
• You want Supabase, Cal.com, PocketBase or another template running in one click.
• You want MySQL, PostgreSQL, MongoDB, MariaDB or Redis created and backed up by the platform.
• Several people need access from a browser with roles and permissions; the Cloud Startup plan adds unlimited users and 2FA.
• You automate deploys through an API or a CLI.
• Open source and free self-hosting are requirements.
• People on your team use macOS; Shipown has no macOS app yet.
• You want monitoring alerts that do not depend on a desktop app being open and a PC being awake.
• You want AI to draft a Compose file from a description.

When Shipown is the better choice

• You want servers that stay plain Linux: no Swarm, no Traefik, no panel database, no agent.
• You run Node and static apps and want them under PM2 and Nginx, using Docker only where an app needs it.
• You want to roll back a Node or static app to an earlier release without setting up an image registry.
• You want a person to decide when a deploy happens, with waiting commits counted and a health check before anything goes live.
• You want an AI terminal on your own key for diagnosing the live server, with every command approved first.
• You want server chores in the same app: cron, firewall, swap and log rotation, fail2ban, deploy users, and backups for database engines already installed.
• You prefer that SSH keys and environment values never leave your computer for licensing or telemetry.

Moving from Dokploy to Shipown

Start by finding out exactly what Dokploy is running, then rebuild it on a fresh server and move traffic with DNS. The guides to deploying a Docker Compose app and a Next.js app cover the target setup step by step.

# On the Dokploy server: what is running, and how it is configured
docker service ls
docker stack ls
docker service inspect <service> --format '{{json .Spec.TaskTemplate.ContainerSpec.Env}}'
docker volume ls

1. Inventory every app and database. Use the commands above alongside the dashboard. Record each app's repository and branch, build type (Nixpacks, Buildpacks, Dockerfile or Compose), port, environment variables, domains and volumes.
2. Decide the runtime for each app. A Node app that Nixpacks or Buildpacks built can run under PM2; a Compose app can stay a Compose app.
3. Prepare a fresh server. Connect it in Shipown and let setup install only what those runtimes need. Leaving the Dokploy server untouched gives you a fallback, and avoids Traefik and Nginx contending for the same machine.
4. Move databases and volumes. Dump each database with its engine's own tool (pg_dump, mysqldump or mariadb-dump, mongodump), restore it into an engine installed on the new server, and copy volume data across.
5. Deploy and read the logs. Choose the source, correct the detected plan, add the environment variables and deploy. The release goes live only after its health check passes.
6. Switch DNS, then HTTPS. With the TTL lowered a day in advance, point each domain at the new server, then ask Shipown for the certificate so Certbot can verify the domain there.
7. Keep Dokploy until you are sure. Leave it running for a few days while you confirm traffic, logs and backups on the new server, schedule daily database backups in Shipown, and only then shut the old server down.