Fleet

The idea

Self-hosting is great until you have more than one thing to deploy. Suddenly you're manually juggling ports, fighting over 80 and 443, editing Caddy configs by hand, and copy-pasting SSH commands every time something needs an update. Fleet was built to make that boring.

One config file, one command, and your app is live — with HTTPS sorted automatically. Run it again when you push a new version and Fleet figures out what actually changed, only restarting what needs to restart rather than bouncing everything. Wire it into GitHub Actions and you've got a proper deployment pipeline without the complexity of Kubernetes or the cost of a managed platform.

What it does

Fleet deploys Docker Compose stacks to a remote server over SSH, driven by a simple fleet.yml config file alongside your compose setup. The first time you run it against a server, it bootstraps a shared Caddy reverse proxy that handles HTTPS automatically via Let's Encrypt — every subsequent stack you deploy to that server gets its own domain and certificate with no extra configuration.

Each deployment uploads your compose files and environment variables, then uses file hashes to figure out which services have actually changed. Only those containers get restarted; everything else keeps running. When the rollout finishes, Fleet polls your health check endpoint until the stack confirms it's live, so you know the deploy actually worked rather than just that Docker accepted the command.

Secrets can come from inline key-value pairs in the config, a .env file you pass in, or exported directly from Infisical if you're using a secrets manager. Fleet is entirely non-interactive by design, so it slots cleanly into GitHub Actions or any other CI/CD pipeline without modification.

Quickstart

npm install -g @pruddiman/fleet

# Initialise a fleet.yml in the current directory
fleet init

# Validate config and SSH connectivity
fleet validate

# Deploy to the remote server
fleet deploy

License

MIT