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 beside the live one, switched in with a single atomic step, then health-checked. 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

Built in full before it goes live

Your build, migration and pre-activate steps run inside the new release while the old one keeps serving every request.

If any of them fails, the switch simply never happens. The live release is untouched and the deploy stops safe. You never ship a half-built release.

api · deploy #128 · build
✓ Run build command14s
✓ Apply migrations2.1s
✓ Run pre-activate hook0.8s
✓ release 128 is built and ready to switch 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, fully built
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 can roll itself back automatically to the previous release. Turn on auto-rollback and 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 the new release first, and none goes live until all are ready. Then each switches over, and if one fails to switch or the release fails its health check with auto-rollback on, the ones that switched roll back. No half-built fleet.

A fleet deploy in symflip: every server builds before any of them switches.

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.