Windlass

A self-hosted panel for Docker Compose that never rewrites your compose file.

Windlass gives one server Git deployments, HTTPS domains, logs, a terminal, metrics,
backups and users, and does all of it by running the real docker compose CLI on your own
compose.yaml. No Swarm, no Postgres, no Redis: one Go binary, one SQLite file and Caddy.
The process idles at about 24 MB, and CI fails any build that reaches 40 MB.

curl -fsSL https://get.windlass.run | sudo sh

Runs on Linux, x86_64 or arm64. Claiming the instance and setting the panel domain are under
Install.

Why Windlass

• Your compose file stays yours. Windlass adds no labels, networks or renamed volumes to
  it. Routes go to Caddy through its API, so docker compose up -d by hand still works, and
  the panel reads the same files you edit.
• The panel is not in the request path. Stop Windlass and your sites keep serving: the
  containers are ordinary Compose containers with a restart policy, and Caddy keeps its
  routes. See life without the panel.
• Nothing to migrate off. Everything that defines an app is a plain file in
  /var/lib/windlass/projects/<name>/. Uninstall Windlass and you keep a folder of Compose
  projects that run with docker compose alone.
• Small enough for the cheapest VPS. No database server or cache to feed besides your apps.
• Staging that promotes what it tested. A project can have a staging copy with its own
  domains, .env and data. Pushes reach staging first, and Promote deploys the same commit
  and image digests to live. See Staging.
• An MCP server for AI agents. Claude Code, Cursor, VS Code or Codex can read projects,
  logs and deployments, and with a Deploy only token can deploy, roll back and promote. The MCP
  server cannot edit a compose file or .env. Its eval results across Claude models are
  published. See AI agents (MCP) and Evals.

Status

Windlass is in production use: real projects are deployed and served with it. It is still
0.x, so a release can contain a breaking change; when one does, its release notes say so and
what to do. The plugin SDK is held stable. Version 1.0 will mean the
/api/v1 API, the plugin SDK and the project directory layout are frozen, and an outside
security review has been done. Until then, read Security before putting it
on a server you cannot rebuild.

How it compares

Checked against each project's own docs and source on 30/10/2026. Corrections welcome.

If you want a Heroku-style git push workflow, Dokku is the better fit. If you already write
Compose files and want a panel that leaves them alone, that is what Windlass is for.

More screens in docs/screenshots, and the full guides at
windlass.run.

Source-of-truth model

Application configuration lives under the projects directory:

<projects>/<name>/
├── compose.yaml       # services, images, ports, volumes, networks, env references, limits
├── .env               # optional standard dotenv file; mode 0600
└── .windlass.json     # source repository, branch, auto-deploy, and domains

Windlass executes the real docker compose CLI in that directory. Hand-editing the files
and running docker compose up -d is supported. The Files and Environment screens read the
same files, and Scan directory rebuilds the SQLite project/domain index.

SQLite is not application configuration. It contains platform state such as users, sessions,
audit entries, deployment history, jobs, backup records, settings, encrypted credentials,
and rebuildable project/domain/environment indexes. Removing SQLite does not stop running
containers; filesystem scanning restores the application index, but platform history and
accounts require a platform backup.

Main features

• Manual, Git, webhook, template, and rollback deployments
• Crash-resumable deployment jobs and replayable deployment events
• Staging per project: pushes deploy to a copy with its own domains and data,
  and Promote deploys the commit and image digests it verified to live
• Caddy application domains and a Settings-managed HTTPS domain for the panel itself
• Raw file editing plus individual or bulk-paste environment variable editing
• Compose-native CPU/memory limit visibility and application readiness checks
• Container logs, browser terminal, host/container metrics, and image cleanup
• Local and S3-compatible backups with optional schedules
• Local users, roles, TOTP, and optional GitHub or Google sign-in
• Personal API tokens for scripts and CI: read only, deploy only, deploy and edit, or admin
• An MCP server for AI agents: Claude Code, Cursor, VS Code or Codex can read
  projects, logs and deployments, and deploy with a deploy only token
• Private registry credentials, applied to the host with a real docker login
• Optional external-process plugins

Application readiness is configured with ordinary Compose labels:

services:
  web:
    labels:
      windlass.health.url: https://app.example.com/health
      windlass.health.status: "200"
      windlass.health.contains: ready
      windlass.health.stability_seconds: "10"

Install

curl -fsSL https://get.windlass.run | sudo sh

Claim the instance using the one-time token from sudo journalctl -u windlass | grep setup_token, then open Settings, General, Panel domain after pointing a DNS record at
the server. Caddy obtains and
renews the panel certificate automatically.

See Installation for systemd, container, configuration, update, and
uninstall details.

Contributing

Building, testing and the architecture rules a change has to keep are in
CONTRIBUTING.md. Vulnerabilities go to SECURITY.md, never a
public issue.

Licence

Apache-2.0