Instant Rollback is just an alias reassignment

When production breaks, the only number that matters is how long it stays broken. Everything else — the root cause, the fix, the post-mortem — can wait. Getting a good version back in front of users cannot. That's the entire design goal of Instant Rollback, and the reason it earns the word "instant" is almost boringly simple: nothing gets rebuilt.

Deployments are immutable; production is a pointer

Every time you deploy on Triangle, we build your files once and store the result as an immutable deployment. It never changes again. It has its own permanent URL, and it will serve those exact bytes forever. Your fifth deploy doesn't overwrite your fourth — they both exist, side by side, complete and independent.

"Production" is not one of those deployments. Production is an alias — a named pointer that currently points at one of them. When you deploy, the alias moves to the new deployment. When you roll back, the alias moves to an older one. That's the whole mechanism.

# before — production points at the broken deploy
production  ->  dpl_9f2a  (just shipped, broken)

# rollback: move ONE pointer. no build, no upload.
production  ->  dpl_8c14  (previous, known-good)

# dpl_9f2a still exists, untouched, at its own URL.

Because the older deployment is already built, already uploaded, and already cached at the edge, there is nothing to wait for. The pointer moves and traffic follows it. No compile step, no cold path, no "deploying…" spinner. It's the difference between reprinting a book and turning a sign to point at a different shelf.

A rollback that has to rebuild isn't a rollback — it's a redeploy wearing a costume. If it takes as long as shipping did, you haven't actually recovered any faster.

The rolled-back state is sticky — on purpose

Here's a subtlety that matters when you're mid-incident. After you roll back, Triangle turns off automatic production assignment. Normally your newest deployment becomes production automatically; once you've rolled back, that stops. Production stays pinned to the version you chose, and new deploys land as previews without silently taking over.

This is deliberate, and it prevents the worst failure mode of a rollback: rolling back, pushing a "quick fix," and having that unverified fix auto-promote itself straight back into the outage you just escaped. The sticky state gives you room to breathe — you fix, you preview, you verify — and production doesn't move again until you say so. When you're ready to resume normal flow, you hit Undo, auto-assignment comes back on, and the newest deployment takes over as usual.

• Roll back — production repoints to a known-good deployment, instantly.
• Auto-assignment pauses — new deploys stay as previews, not production.
• Verify at leisure — test your fix on its own URL with no pressure.
• Undo — auto-assignment resumes and the newest deploy is production again.

Hobby vs. Pro: how far back you can go

The mechanism is identical on every plan — it's always just an alias moving. What differs is your target:

• Hobby can roll production back to its previous deployment. One step back — the fastest and most common recovery, and it's free forever.
• Pro can roll back to any deployment in your history. Reach past the last one to any known-good build you've ever shipped, no matter how far back the regression started.

Both are instant because both are pointer moves. Pro just gives you a longer reach when the bad version wasn't the most recent one. If you've ever chased a regression that turned out to have shipped three deploys ago, that reach is the whole feature.

The lesson we keep relearning: the fastest operations are the ones that don't do work. Rollback feels magical, but there's no magic in it — just immutable deployments and a pointer we're willing to move the instant you ask.

Priya Nair works on Deployments at Triangle and believes the best recovery is the one you barely have to think about.