dockxo beta
FeaturesPricingBlogChangelogGet started Sign in
features/deploys
GitHub, images, Dockerfiles, templatessince v0.1

Deploys

Deploy from a GitHub repository with push-to-deploy, from any Docker image or private registry, from an inline Dockerfile, or from one-click templates. Rolling swaps keep the old container serving until the new one passes its port check.

  • 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.

Related posts