Why I built symflip

I kept hitting the same wall. I had a handful of small apps running on Linux servers I owned, and every deploy was the same ritual: SSH in, git pull, rebuild, restart, and hold my breath for the few seconds the app was down. If a release was broken, rolling back meant doing the whole dance again in reverse, under pressure, with users watching.

The tools that solve this properly are built for a different world. Kubernetes, service meshes, and CI pipelines are wonderful when you have a platform team and a fleet of microservices. For one developer shipping to a couple of boxes, they are a second full-time job.

symflip is the tool I wanted in the middle: connect a Git repo and a server, click deploy, get an atomic release with live logs and one-click rollback. Nothing to install on the server. No cluster to stand up.

What "zero-downtime" actually means here

The trick is that a new release is never deployed over the running one. Each release lands in its own directory, and going live is a single atomic step: the current symlink is flipped to point at the new release, then the app is reloaded to pick it up.

releases/
  20260803T101500/   ← previous release, kept warm
  20260803T140200/   ← new release, built and health-checked
current -> releases/20260803T140200   (atomic symlink swap)

Because the swap is a single rename(2) on the symlink, there is no moment where the server is pointing at a half-copied directory. Traffic is served by the old release right up until the instant it is served by the new one.

Built and checked before it goes live

The order of operations is what makes it safe. symflip builds the new release and runs its health check while the old one is still serving every request. Only once the release has been built and has passed the check does the symlink swap happen.

If the build fails, or the health check never goes green, the switch simply never happens, and the live release is untouched. And when a release does go live but then fails its check, symflip flips the symlink straight back to the previous release automatically. The old version is always there, warm and ready.

Agentless on purpose

There is nothing running on your server that symflip put there. No agent, no daemon, no sidecar to patch or babysit. Everything happens over a normal, encrypted SSH connection using a key you control. That was a deliberate line in the sand: the tool should make shipping effortless without asking you to trust or maintain one more long-running process on your own hardware.

Where it's going

symflip started as a way to scratch my own itch, and it still deploys the very site you're reading this on. If you deploy to a Linux box you own and you've ever held your breath during a restart, I built this for you.

Try it free. Connect your first server in minutes.