Git integration
Connect GitHub or GitLab, choose the branch that means production, and deploys start on push. Manual deploys of any commit stay one click away.
Snappy Deploy
Deploy your apps to your own servers.
Snappy builds your application into a Docker container and deploys it to servers you own. Connect a machine over SSH, point it at a repository, and every push ships with zero downtime and a valid certificate.
snappy deploy — api.myapp.dev
$ snappy server add fsn1 --ssh root@142.132.x.x✓ docker present · daemon installed · proxy up$ snappy app create api --repo myorg/api→ building image · node:22-alpine✓ certificate issued · api.myapp.dev✓ live in 41s · zero downtime
How it works
Four steps, then you forget about it.
- 01
Add a server
Any Linux host you can reach over SSH. Snappy installs Docker if it is missing and brings up the reverse proxy.
- 02
Connect a repo
Your Dockerfile if you have one, an auto-detected build if you do not. Environment variables and secrets live with the app.
- 03
Push
Snappy builds the image, runs the release command, and starts the new container alongside the running one.
- 04
Traffic swaps
Health checks pass, the proxy moves traffic over, the old container drains. If they fail, nothing changes.
Features
Everything a small team actually needs to ship.
Container builds
Your Dockerfile is the contract. Layer caching on the build host keeps repeat builds short, and the resulting image is a plain image you can run anywhere.
Zero-downtime deploys
New container up, health checked, traffic swapped at the proxy, old container drained. Requests in flight finish where they started.
Rollback to any release
Previous images stay on the server, so going back is a container swap rather than a rebuild.
Automatic SSL
Point a domain at the server and the certificate is issued and renewed for you, wildcards included, with HTTP redirected to HTTPS.
Logs from both sides
Stream container output and reverse-proxy access logs in the same view, so a 502 stops being a guessing game.
Secrets and config
Environment variables live per app and per environment on your own server. Changing one triggers a normal, safe rollout.
Workers and scheduled jobs
Background processes and cron-style jobs deploy from the same image as the web process and restart with it.
More than one server
Run staging on a small box and production on a bigger one, or spread one app across several hosts. Same commands either way.
Requirements
What you bring, what Snappy brings.
The whole thing is deliberately unexotic. No Kubernetes, no agents to babysit, nothing you cannot inspect over SSH.
| Piece | What it takes |
|---|---|
| Server | Any Linux host with SSH access — Hetzner, DigitalOcean, AWS, bare metal, a machine in your office. |
| Runtime | Docker, installed by Snappy if it is not already there. |
| Repository | GitHub or GitLab, public or private. |
| Build | Your Dockerfile, built on the server or on a dedicated build host. |
| TLS | Issued and renewed automatically. Bring your own certificate if you prefer. |
| Databases | Run them as containers with persistent volumes, or point at a managed database you already have. |
Every pull request can have its own environment too.
Snappy Review builds the same image for every open PR, gives it a URL on your server, and destroys it on merge.
FAQ
Deploying to your own servers, answered.
How do I deploy a Docker container to my own server?
Add the server with its SSH details, connect a git repository, and push. Snappy builds the image, starts the new container, health-checks it, swaps traffic at the proxy and drains the old one.
Which hosting providers work?
Any provider that gives you a Linux box with SSH — Hetzner, DigitalOcean, Vultr, OVH, Scaleway, AWS EC2, or your own hardware. There is no provider integration to wait for.
Do I need to write a Dockerfile?
Bring yours if you have one; it is the contract and it is what gets built. If you do not have one, Snappy can detect a standard build for common stacks.
How does zero-downtime deployment work?
The new container starts alongside the running one. Only after health checks pass does the reverse proxy move traffic across, so requests in flight finish where they started. If checks fail, nothing changes.
Are SSL certificates automatic?
Yes. Point a domain at the server and certificates are issued and renewed for you, wildcards included, with HTTP redirected to HTTPS.
Can I run databases on the same server?
Yes — as containers with persistent volumes — or point your app at a managed database you already run. Both are normal setups.
How do I roll back a bad release?
Previous images stay on the server, so a rollback is a container swap rather than a rebuild. Pick the release and it goes back.
Can one app span several servers?
Yes. Run staging on a small box and production on a bigger one, or spread one application across multiple hosts, with the same commands either way.
Can I see logs?
Container output and reverse-proxy access logs stream in the same view, so a 502 stops being a guessing game.
Is there vendor lock-in?
No. What is left on your server is plain Docker containers built from your own repository. If you stop using Snappy, everything keeps running.
Try Snappy Deploy in beta.
Leave an address and we will send a server-setup guide with your invite.