Overview

dpl is a single-binary deploy tool for one host. It reads your unit configs, builds and runs containers with Podman, routes HTTP through nginx, and runs databases from official images.

Why containers

A by-hand deploy means installing a runtime, a database, and a web server, then keeping their versions and connection strings in sync. dpl runs each unit in its own container instead:

• The host stays clean. No runtimes or database packages on the base system - each unit carries its dependencies in its image.
• Versions are pinned per unit. They do not depend on what the distro ships, and upgrading one app does not touch the rest.

What dpl manages

dpl uses units. A unit is one thing you want to deploy.

Unit type	What it solves
app	Builds the app image, runs the container, copies static assets to the http-server, and runs scheduled tasks.
db-server	Runs a database server container (PostgreSQL, MariaDB, or MySQL).
db	Creates a database and its user on a db-server.
http-server	Runs nginx and exposes HTTP/HTTPS ports on the host.
domain	Adds an nginx vhost for a hostname: reverse proxy, uWSGI backend, or static files.

How it works

1. You place unit files in <base>/conf.
2. You store secrets with dpl secret.
3. You run dpl check <unit> to find broken config or references.
4. You run dpl deploy <unit>.
5. The dpl serve daemon starts or restarts runtime containers.

Requirements

dpl needs Podman to build and run containers (build, run, exec, and named volumes).

Fedora Server (versions 42 or 43) is the recommended host OS, as Podman is included by default.

In production, run dpl serve under systemd. Deploy commands such as dpl deploy run once and exit.