# Approve Deploy From iPhone at Dinner in 60 Seconds

> Stuck waiting on deploys while away? Stage on laptop, approve from iPhone over Tailscale, ship in one tap. The pending-push pattern inside.

Source: https://boringpush.com/blog/approve-deploy-from-phone

## Deploys that wait for your desk

The fix is ready at 4 p.m. You are at dinner at 7.

The deploy happens at 11 p.m., when you get home. Four hours of users waiting on a fix that existed all afternoon.

Or your co-founder finishes the fix and waits for you to "take a quick look and ship it." The review takes ninety seconds. The desk takes three hours to reach.

Split staging from approval.

The laptop does the careful work. The phone makes the ninety-second decision from anywhere.

## Approval flows, ranked by delay

| Flow | Staged where | Approved where | Delay |
|---|---|---|---|
| Push when home | Laptop | Laptop, tonight | Hours |
| CI auto-deploy | A cloud runner | Nobody | Minutes, no judgment |
| Dashboard promote | A browser tab | Phone browser, fiddly | Minutes, painful |
| Stage, then approve | Laptop or agent | A phone terminal | Minutes, with judgment |

Waiting at a desk is worse than it looks.

**Batches grow while you wait.** Three ready fixes become one Friday deploy. Friday deploys break more than Tuesday one-liners.

**Auto-deploy skips the human.** CI that ships every green build is fast until green is wrong. Ninety seconds of human eyes catches what pipelines cannot price.

**Dashboards hate phone keyboards.** Tiny buttons, expiring sessions, sign-in loops on cellular.

## What to do

Stage the release so approval is one decision.

On the laptop, or through your agent, run the checks and park the finished work on its own branch.

The branch holds code that is gated, reviewed and smoke-tested. Approval later is not re-reviewing. It is confirming that you ship what you already checked.

Then send yourself a ping worth deciding on.

The branch name. How many commits. The one action you want.

No dashboard to open. No diff to re-read on a six-inch screen.

Then approve from the phone.

Open your SSH app.

Go to the checkout on the machine you deploy from.

Switch to the staged branch.

Run `bp deploy`.

It shows the branch, the commit and any unsaved files.

Then it asks before it ships.

A human on a terminal answers the prompt.

There is no flag to type on a phone keyboard.

## What happens after you say yes

`bp deploy` checks your code.

It builds.

It ships.

It waits for the new version to answer.

If it never answers, the server puts the previous version back.

And `bp rollback --yes` restores the last version without a rebuild.

One caveat from reading the code: when the server undoes a release itself, the command may still look as if it finished. Read the output. Open the live site.

## The dinner-table drill

| Check | Action | Pass looks like |
|---|---|---|
| Staged and gated | Checks pass, branch pushed | The branch is on your remote |
| Decidable ping | Phone gets context | Branch and commit count |
| Approve | SSH app: switch branch, `bp deploy` | The prompt shows the branch and commit |
| Verify | Open the live site, place a test order | Page loads, order flows |
| Retreat | `bp rollback --yes`, rehearsed once | One command back |

Practice the approve step once from the couch.

Phone approval works because staging did the real review. Approving unreviewed code from a phone is malpractice with extra steps.

## Know this first

You approve by running the deploy. There is no approval bot. The ready-to-ship ping is a message you or your agent sends.

Phone approval only works if the real review already happened.

## Why BoringPush is the way to do this

Review at your desk. Approve from anywhere.

One command ships it. It checks the code, builds, ships and waits for a health check.

If the new version never answers, the old one comes back.

Shipping stops waiting for you to get home.

## FAQ

### Is it safe to deploy from a phone over cellular or cafe Wi-Fi?

SSH is encrypted end to end, so the network only sees opaque traffic. If you also put the server behind a private network such as Tailscale, scanners cannot even see it. Network trust is not part of the design, so any network works.

### What if I approve the wrong branch?

The previous version stays on the server, one command away. Run `bp rollback --yes` and the last release is back without a rebuild. Drill it once and wrong-branch fear retires.

### Can my co-founder approve while I stage, or the other way around?

Yes, and it is the best version of this pattern. One person stages the branch and sends the ping; whoever is free runs the deploy. Anyone with access to the machine can approve, so give that access only to people you trust with production.

### How is this different from Vercel's Promote-to-Production button?

Same ninety-second decision, different road. Vercel's button needs a dashboard session in a phone browser and per-seat pricing. This route needs an SSH app and a server you already pay for, and the build runs on your own hardware.

### Should every push need phone approval, or only releases?

Only releases someone else staged. Small fixes of your own can ship directly, with the checks as their review. Two lanes: direct for yours, approve for theirs.

### What stops an accidental command from deploying garbage?

`bp deploy` runs a code check first, so a problem stops the run before anything leaves your machine. After the build, a health check decides whether the new version stays live. A mistaken run fails loudly in your terminal within seconds.

## Keep reading

- [Fix Production From Your Phone: The Grocery-Line Drill](/blog/fix-production-from-phone-telegram) — the ping that starts this approval
- [git push production deploy: Skip the 9-Minute CI Queue](/blog/git-push-production-main-deploy) — the hook the approval pushes through
- [How to Ship Code From Your Phone (2026 Setup)](/blog/ship-code-from-phone) — the full 4-app phone stack