- GitHub repo with branch, Dockerfile path, monorepo build path and push-to-deploy webhook
- Docker image from Docker Hub, GHCR or any private registry
- Inline Dockerfile written in the panel
- One-click templates for Postgres, MariaDB, MySQL, Redis, Mongo, RabbitMQ, MinIO, Meilisearch, Nginx and Uptime Kuma
- Rolling deploys with a port check before the old container is removed
- Build log streamed live, history with commit message and duration, cancel at any time
Four sources, one pipeline
Every service has a source and every source goes through the same deploy job:
| Source | What you set | Typical use |
|---|---|---|
| GitHub | repo, branch, Dockerfile path, build path, auto-deploy | your own apps |
| Docker image | image, tag, optional registry credentials | vendor software, prebuilt images |
| Dockerfile | a Dockerfile written in the panel | glue services, custom images |
| Template | one click | databases, queues, search, object storage |
A deploy clones or pulls, builds with Docker’s layer cache (the previous image is kept so unchanged layers are reused), starts the new container, waits for it to answer on its port, updates Traefik routes and finally removes the old container. You can watch every line of the build live, cancel a running deploy, or rebuild without cache when you need a clean image.
Push to deploy
A GitHub service registers a webhook verified with X-Hub-Signature-256. Push to the configured branch and the deploy starts by itself; the deploy log shows the commit message and sha, and the history keeps the outcome and duration of every run.
Recreate or rolling
Pick a deploy strategy per service:
- Recreate removes the old container first. Simplest, a few seconds of downtime, right for databases and anything that holds a port or a volume exclusively.
- Rolling starts the new container next to the old one, waits for the port check, switches routes, then removes the old one. Zero downtime for web apps and APIs. A failed rolling container is removed instead of lingering.
Env into the build
GitHub and Dockerfile services can have their env written as a .env file into the build folder before docker build, for frameworks that read a file instead of the environment (Laravel, CodeIgniter, dotenv). The path is configurable (app/.env works too), the file replaces a committed one of the same name and is sent even when .dockerignore lists it. Variables still reach the container as environment.
Jobs you can follow
Deploys, migrations, volume restores and permission fixes are persistent jobs. They survive a browser refresh, can be cancelled (the agent aborts builds, clones, transfers and helper containers), and the Jobs page lists every one with its log. Jobs orphaned by a panel restart are marked interrupted rather than left spinning.
dockxo vs Virtuozzo Application Platform (Jelastic): a PaaS on your own VPSes, without the licence
Virtuozzo Application Platform, formerly Jelastic, is licensed per cluster from $192 a month and needs a rack of infrastructure nodes before the first app runs. dockxo does the everyday PaaS jobs on the servers you already rent, free during the beta. A fair, numbers-first comparison.
Sep 22, 2026Zero-downtime deploys with rolling swaps
What happens between a git push and the moment the new container takes over, and why the old one stays until the new one answers on its port.