A waiting room for WooCommerce that your own store enforces

The plugin runs in your store, not in front of it

The usual WooCommerce waiting room asks you to put the vendor in the request path — a DNS change, a reverse proxy, or a CDN feature that intercepts before WordPress is reached. From that point on your store is downstream of their infrastructure.

This one inverts that. The queue itself, pass issuance and bot scoring run in our cloud. The plugin runs in yours and does the enforcing: when a shopper arrives with a signed admission pass, the plugin verifies the signature locally, with no network call, and lets them through. The boundary between us is crossed once, when a pass is issued — never on a page load.

What that buys you:

• No DNS change and no reverse proxy. Your origin does not move.
• No per-request callout. Verification is a local HMAC check, so there is no round trip added to a page load and no dependency on our latency.
• None of your traffic is routed through us. Your customers’ payment details never touch our systems.

Shadow mode is the default, and it is the point

Activate the plugin and it enforces nothing. It logs what it would have done — which requests it would have gated, which passes it would have rejected — and lets every shopper straight through. You read the log, decide whether it is behaving the way you expect on your theme, your caching setup and your checkout, and only then switch it on.

We lead with this because “we’ve never heard of you” is a fair objection to putting anything in front of a checkout. The answer is not a logo wall. The answer is that you can install this, watch it for a week, read the source, and have risked nothing.

It fails open, and that is a design decision

If we are unreachable, the plugin keeps selling. It holds a durable last-known-good policy, so gating survives us being down rather than collapsing into either “block everyone” or “gate nothing”. Your store’s availability does not depend on ours.

Order-level enforcement, not just page-level

Gating the page a shopper lands on is the easy half. The half that actually protects a limited run is stopping one admission from becoming five orders.

Each pass is signed and single-use. The plugin enforces that at checkout, so a pass that has already been spent cannot be replayed, forwarded to a friend, or fanned out across parallel sessions by a script that got one legitimate admission. Nobody else in this category ships that as part of a first-class WooCommerce product.

Where the plugin alone is not enough — and we will tell you before you buy

The plugin runs inside PHP. If something in front of PHP answers the request, the plugin never executes. That is not a bug and it is not fixable inside WordPress:

• Full-page caching that bypasses PHP — LiteSpeed cache, nginx microcaching, Varnish, or a CDN caching your HTML — will serve a cached page to a queued shopper. The plugin’s cache suppression cannot pre-empt a cache that answers without invoking PHP.
• Headless storefronts and Store-API-driven front ends. The plugin does not gate the read path there at all.

For either of those you need the edge connector as well — a Cloudflare Worker that gates in front of the cache, with the plugin still doing order-level enforcement behind it. The edge stops your store being hammered; the plugin stops one admission becoming five orders. Running both is the strongest configuration, and it is an honest architectural requirement rather than an upsell.

On standard WooCommerce hosting with page caching disabled for logged-in and cart sessions, the plugin alone gates every page load and every order. Two limits remain even then, and they are the honest reason to add the connector rather than a sales one: the WordPress REST catalogue (/wp-json) is never browse-gated at the origin, because the hook the plugin gates on does not fire for it — so a queued visitor can still read product data; and every queued shopper polling for their turn costs a full WordPress and WooCommerce bootstrap, so the store still has to survive the crowd even though the allocation is fair. With the connector in front, the crowd never arrives.

How you go live safely

1. Upload the plugin and activate it. It is in shadow mode: it logs what it would have done and enforces nothing.
2. Paste your setup code — one string from the console. No DNS, no proxy, no origin change.
3. Watch the log during a normal trading day, then during a small drop.
4. Turn enforcement on when you are satisfied. Set your admission rate — there is no floor and no cap, on every plan.

If we are unreachable at any point after that, the plugin keeps the last policy it pulled and keeps selling on it. Going live is a switch you flip, not a cutover.

The whole thing is MIT-licensed, so you can read exactly what it does before step one.

What it does not do

No priority or invite codes — the gap we are asked about most, and it is not shipped. Shoppers always see their position; two optional, per-store extras are off until you turn them on — an estimated wait at the current pace (hidden while the line is paused) and a countdown to a scheduled presale draw. No public API, SDK or webhooks. Multiple stores are billed per store today, which is worth knowing if you run several.