symflip
How it works

Zero downtime,
no magic.

symflip is agentless: nothing runs on your server that it put there. Every deploy happens over an ordinary SSH connection — the new release is built and health-checked beside the live one, then switched in with a single atomic step. Here's exactly what happens.

A deploy streaming live in symflip — every step, in your browser.

1 Connect & fetch

An SSH connection you control

symflip opens an encrypted SSH connection to your server using a key you hold, pinning the host key on first contact so the identity can't be swapped later. There is no agent to install, patch, or babysit — nothing extra runs on the box.

It fetches the exact commit you're deploying into a fresh, timestamped releases/ directory. The release that's currently serving is never touched.

ssh · deploy.acme.io
Open SSH channel0.4s
Verify pinned host key0.1s
Fetch main @ a1b9f301.2s
Prepare releases/1280.3s
2 Build & verify

Built and checked before it goes live

Your build and migration steps run inside the new release while the old one keeps serving every request. Then symflip runs your health check against the prepared release.

If the build fails, or the check never goes green, the switch simply never happens — the live release is untouched and the deploy stops safe. You never ship a half-built or unhealthy release.

api · deploy #128 · build
Run build command14s
Apply migrations2.1s
Health-check :8080/healthz0.8s
✓ health check passed — release 128 is ready live release 127 still serving all traffic
3 Atomic go-live

One symlink flip — 0ms downtime

Going live is a single atomic step: the current symlink is re-pointed at the new release with one rename, then the app is reloaded to pick it up. There is no moment where the server points at a half-copied directory.

Traffic is served by the old release right up until the instant it's served by the new one — which is why a release costs zero downtime.

~/apps/api
releases/
  126/          ← older, still kept
  127/          ← previous, kept warm
  128/          ← new, health-checked
current → releases/128   (atomic swap)
$ ln -sfn releases/128 current ✓ switched — 0ms downtime
4 Roll back

The previous release is always warm

symflip keeps old releases on the box, so rolling back is another instant symlink flip — no rebuild, no scramble. One click returns you to the last good version.

And if a release goes live but then fails its health check, symflip rolls itself back automatically to the previous release. A bad deploy heals itself before you even reach for the button.

api · deploy #129 · auto-rollback
Switch traffic to release 1290.2s
✗ post-activation health check failed $ ln -sfn releases/128 current ✓ auto-rolled back to release 128 — service restored
Scale & teams

The same deploy — across your whole fleet.

Add more servers to a project and they ship in lock-step: every server builds and health-checks the new release first, then they all switch over together. No half-updated fleet.

A fleet deploy in symflip — every server switches together.

See it on your own server.

Connect a repo and a Linux box, click deploy, and watch the whole thing happen live. Your code and servers stay yours — symflip just makes shipping effortless.