Questions operators ask first

Yes. TideGuard is MIT-licensed open-source software. You do not pay us to run it.

You still pay Cloudflare for the Workers and Durable Objects usage on your account, the same way any Worker does. The cost calculator estimates that infrastructure only.

TideGuard is a passion project built around a real need: keep an origin alive during a surge without renting an expensive commercial waiting room. Most launches do not need enterprise-priced queue software — they need fair admission, signed tokens, and a control room you can run yourself.

You deploy on your own Cloudflare account. The getting started path and Integrate guide are aimed at operators who want something live with minimal ceremony, not a platform team and a sales call. Infrastructure cost stays with Cloudflare usage you can estimate before the drop.

Cloudflare is the edge platform TideGuard runs on. Their global network sits in front of your site: Workers run your waiting-room code close to visitors, and Durable Objects hold the live queue state.

You deploy TideGuard on your own Cloudflare account, so the bill is theirs for infrastructure usage — not a TideGuard subscription. We are not affiliated with Cloudflare and receive no payment, commission, or other financial benefit when you use their platform. If you already proxy traffic through Cloudflare, you are on the same stack.

With TideGuard you own the waiting room. You deploy it on your Cloudflare account, keep the code, and pay only for the infrastructure you actually use.

Most commercial waiting rooms sell a managed service with opaque per-event or seat pricing, so a fair side-by-side cost comparison is hard. Here the software is free and the Cloudflare bill is something you can estimate before the surge.

Compared with Cloudflare Waiting Room (a managed product on the same platform): TideGuard is open-source, FIFO or lottery you can read, and a full operator control room you host — not a black-box seat allocation you rent. You trade managed support for code you can audit and a bill that is only Workers / Durable Objects usage.

Commercial suites often charge by event size or concurrent visitors and keep queue logic proprietary. TideGuard’s job is the same — hold the flood, admit at a rate your origin survives — but you deploy the Worker yourself under MIT.

We do not chase every VIP-lane or virtual-queue theater feature. We focus on fair FIFO or lottery, signed admits, origin proxy, and an operator desk you can run during the launch. See Integrate and Capabilities.

Yes. After setup you are in Demo mode: origin paths are not gated. Smoke-test at /demo or /wait?return=/demo, then use Go live in the control room when the launch checklist is ready.

Details: protecting a domain and Integrate.

Yes, for the same crowd. TideGuard’s default timeslot check-ins keep Durable Object status near a fixed ~750 RPS budget while the room is deep (period = max(5s, ceil(waiting÷750))). Adding waiters spaces each browser’s check-ins further apart instead of multiplying RPS — but that budget runs for the whole time the line is open (crowd ÷ admit rate).

Slower admits stretch that open window, so more status traffic hits Workers and Durable Objects and the Cloudflare estimate goes up. It is still not a commercial per-seat meter: dollars follow visitors and how long the room stays open. Use the cost calculator (crowd size + people you can admit per minute) for your numbers.

Each queue defaults to a 1,000,000 waiting-visitor safety cap. That is not a paid seat limit — it protects the Durable Object from unbounded growth. When the room is full, /join returns 503 queue_full.

Raise or lower it in System → Danger zone (up to 50M) via /api/admin/queue-limits. It is separate from MAX_CONCURRENT_USERS, which is how many admitted people your origin can hold at once. See Capabilities and the launch checklist.

Cloudflare infrastructure for one surge: the Workers Paid $5/month account minimum plus Worker requests, Worker CPU, and Durable Object usage at published list rates. It assumes this crowd is already in line (new joins not modeled). Scheduled check-ins stay near ~750/s while the room is open, so slower admits cost more. Monthly included allotments are not subtracted.

It does not include your origin servers, third-party CDNs outside Cloudflare, or SQLite storage overages. The TideGuard license stays $0. Estimates are based on our model — setups differ, and Cloudflare prices can change.

Visitors join a named queue owned by a Durable Object. In Queue Mode, admission is FIFO: first in, first out, so the person who joined earliest is admitted next. In Lottery Mode, each admit picks uniformly at random among everyone still waiting.

When someone is admitted, TideGuard issues a time-limited HMAC token so the protected page can trust access without a session database.

No. TideGuard sits in front as a waiting room and optional origin proxy. Visitors wait at the edge, then continue with a signed admission token — or TideGuard proxies admitted traffic to your upstream URL.

You configure admit rate, branding, and which paths to protect; your origin keeps serving once people are let through at a rate it can handle.

Authoritative queue state lives in a Durable Object per queue name: joins, leaves, due status (which renews liveness), heartbeats, and admits are strongly consistent there. Early status before nextCheckAt is read-only.

KV is for configuration and branding, not the hot path. Status polls and heartbeats do not write KV.

Yes. The admin setup wizard covers colors, copy, font, waiting depth, and an optional Google Analytics Measurement ID (GA4) for /wait, with a live preview before you save.

Tokens are CSS variables, so branding changes without rewriting the waiting-room layout. If you set GA, consent and cookie policy are your responsibility.

After setup, /admin is the launch desk: live queue metrics, traffic controls (opening time, silent pause, origin health), origin proxy, IP allowlist, Pass queue, country block, branding (including optional Google Analytics), and a server-backed traffic chart.

The traffic chart uses ~15-second buckets with about 24 hours of retention in the Durable Object (inflow vs max outflow), with CSV export. Live metrics also show geo-block hits while a country block is active. See Analytics and Capabilities.

Yes. An IP allowlist matches CF-Connecting-IP on proxied traffic so office networks skip the line without consuming a concurrent slot. Pass queue issues an admission cookie for the current admin browser to smoke-test the protected app.

Country block is a CF-IPCountry gate. Allowlist and Pass queue still override. It is not a substitute for Cloudflare WAF.

Yes. The site demos show a full-page waiting room, an embeddable widget, and a custom UI on join/status shaped JSON — including a simulate geo-block control.

Those pages simulate queue progression with the real TideGuard look. They are not connected to a live Worker yet.

TideGuard is being developed by Mikkel Scheike and Victor Scheike. Profiles are on the About page.

Generate a TOKEN_SECRET on the token page (or openssl rand -hex 32), paste it into Deploy to Cloudflare, use the same value for /admin Claim, then finish the setup wizard. Or clone and run wrangler deploy + wrangler secret put TOKEN_SECRET.

See Integrate & deploy for Demo mode, origin proxy, OpenAPI, and the full getting started guide.

Treat github.com/TideGuard/TideGuard and tideguard.dev as canonical. Deploy-to-Cloudflare clones are easy to leave behind; add an upstream remote and follow upgrading when you want security fixes and new operator features.

Useful improvements belong in a pull request against upstream so everyone benefits — not only a private fork. Contributors: CONTRIBUTING.md. AI coding assistants: AGENTS.md.