auth · tutorial

Admin Allowlist: Stop Paying Customers Entering Admin

Admin pages need a velvet rope, not a role system: email allowlist checked first, everything else unchanged. The 5-line pattern inside.

A uniformed hotel doorman standing at attention, Washington, 1921
A uniformed hotel doorman standing at attention, Washington, 1921 · Photo: National Photo Company Collection, public domain, via Wikimedia Commons

Your admin pages are open to every customer

Your admin dashboard shows revenue, emails and refund buttons.

Guard it with the same paywall as the user dashboard, and any paying customer who guesses the URL walks into your control room.

The opposite mistake is just as costly. A full roles system, permission matrices, invitation flows. Weeks of work to protect a page two people visit.

You need something in between. A velvet rope, not a fortress.

Four ways to guard admin

Option Setup Security Upkeep
Same paywall as users None None, paying users get in None
Obscure URL only None Theater, URLs leak None
Full roles and invitations Weeks Excellent Forever
Email allowlist Minutes Strong for a handful of people One list

Three facts decide it.

Paying is not trusted. Customers pay for the product. Not for refund buttons and email addresses.

Obscurity is not access control. A secret URL lives in git history, browser history and referrer headers. It is a public fact on a delay timer.

Roles rot below team scale. The old contractor stays admin. Nobody audits the permissions. Complexity nobody maintains becomes a hole.

Five people or fewer? Use an allowlist.

What to do

Keep the list of admin emails in your server settings. Not in the database.

Database rows can be edited through the very admin you are guarding. Settings cannot.

Add a person with one edit. Remove them with one edit.

Make an empty list mean nobody. No fallback account. No default login.

Once a month, read the list. Ask whether each person still needs to be there.

Test the rope

Probe What to do Pass looks like
Stranger Visit admin logged out Sent to sign in
Customer Visit admin as a paying non-admin Sent to their own dashboard
Admin Sign in with a listed email Admin views open
Removal Delete the email and reload The old admin is turned away

Run it every quarter. A rope you never tested is a rumor.

Guard the actions too

The door is only half of it.

Destructive actions deserve a second look.

Refunds. Bulk emails. Deleting a user.

Ask for a typed confirmation before they run. The list guards the door. The confirmation guards against the misclick and the stolen session.

Phones are fine for reading. Revenue, a glance at orders. Save the irreversible moves for a desk.

Outgrowing it

Three signs it is time for real roles.

More than about five admins. A compliance request for role evidence. Or someone who needs to read but must not refund.

When that day comes, move the emails into a roles table.

Until then, keep it small. Small things get checked.

Temporary access

A contractor needs admin for a week?

Add the email. Set a reminder. Remove it on the date.

Three motions. No new system.

Short access beats permanent access with good intentions.

Know this first

An email list is all-or-nothing. There are no read-only admin roles. And BoringPush keeps no admin visit log for you.

For a handful of admins, that is plenty.

Why BoringPush is the way to do this

Your admin pages open for the emails you list. Everyone else is turned away.

If the list is empty, nobody gets in. That default is built in.

One list. One edit to add a person. One edit to remove them.

Your customers never see the control room.

FAQ

Is an admin allowlist enough for real businesses?

For teams under about five people with a few admin pages: yes. The threat is curious customers and leaked URLs, and an email list kept in server settings handles both. Past that (support teams, granular permissions, compliance audits), graduate to table-backed roles.

Should admin routes live on a separate subdomain?

Not at solo scale. A second subdomain adds a second certificate, a second sign-in context and cookie puzzles. Admin pages on the same site with an allowlist give the same protection with nothing extra to run.

How do I give temporary admin to a contractor?

Add their email, set a calendar reminder, and remove it on the date. Three motions. A reminder you set is a weaker guard than automatic expiry, so keep contractor access short.

What admin actions deserve extra confirmation?

Destructive or outward-facing ones: refunds, bulk emails, user deletions, plan changes on someone else's account. Ask for a typed confirmation before they run. The allowlist guards the door; a confirmation guards against the misclick and the stolen session.

Should admin pages work from the phone too?

Read-only views, yes: a revenue glance from the grocery line. Destructive actions are better at a desk. The allowlist checks your email, not your device, so the phone works like any browser.

When do I graduate from allowlist to roles?

Three triggers, any one: more than about five admins, a compliance need for role evidence, or a need for granular access such as support who can read but not refund. Move the emails to a roles table and keep everything else the same.

Keep reading

+ all the boring stuff (analytics, auth, SQLite ↔ Supabase, full marketplace, webhooks)

The Agent-First Shipping Kit

Command from your phone.

Built so autonomous AI agents build what you want without breaking what's already paying you.

$199

Get BoringPush

One-time payment · Lifetime updates · Unlimited projects.

Keep reading