Skip to main content
Towbar v2 starts with a simple boundary: Git describes what should run, while the control plane proves what actually happened.

​
Configuration that travels with the code

Each repository contains a towbar.yml environment map and separate app or resource files. A commit therefore carries the build mode, server assignment, health policy, domains, resource limits, backup policy, and the names of required secrets. Reviewers can see an operational change beside the code that depends on it. Towbar syncs an immutable repository revision, validates it, and keeps the last successful inventory when a newer revision is invalid. Connecting or syncing a repository does not silently deploy everything. Automatic deployment is explicit per workload and can be paused independently.

​
Values that should not live in Git

Secret values, SSH private keys, provider credentials, OAuth grants, and the control plane’s encryption keys stay outside the repository. Workload manifests declare secret names and provider references without embedding values. Runtime integrations follow the same boundary. An operator enables and validates Git providers, registries, backup storage, notifications, log forwarding, Cloudflare, or external-secret providers through the host environment. The dashboard shows only integrations that are complete and available; it does not become another credential editor.

​
A deployment is evidence

A deployment records the immutable input, stages, output, health decision, and resulting release. A queued request is not reported as a successful change. Promotion waits for the configured health policy, and rollback selects a recorded release rather than rebuilding an uncertain source state. Scout measurements, alerts, vulnerability results, backups, restores, and notifications add operational context without changing the repository contract. Database restores use a fresh target and switch only after validation, preserving the prior volume for rollback.

​
The tradeoff

Towbar is intentionally stricter than a general Docker dashboard. Compose projects cannot use several host-level capabilities, source builders pin their tooling, and provider configurations are singular per installation. That reduces hidden state and makes reviews more meaningful, but it also means some existing workloads need redesign or should remain outside Towbar. The migration guides for Coolify and Dokploy start with that decision. They do not promise an import button. They inventory what exists, map supported workloads into Git, move state with engine-aware tools, verify through temporary domains, and keep the source available until rollback is no longer needed. Start with Core concepts, inspect the deployment manifest, and use Your first deployment for a complete walkthrough.
Last modified on September 22, 2026