Security  /  Going live

Going live

Every Onelo app is either in Development or Production mode. Development is deliberately fail-open so you can build without fighting the security gates; Production enforces every one of them. To stop a fail-open app from ever receiving a real key, Onelo won't issue or rotate a live key until the app has cleared the readiness bar for its type — a live app is verified by construction.

App Mode — Development vs Production

The mode is a single flag on the app (applications.is_live), toggled under Settings → App Mode with Go Live / Back to dev. It decides whether the SDK-facing security checks are enforced or skipped:

ModeWhat’s enforcedUse it for
DevelopmentFail-open. SDK requests are accepted from anywhere — no Allowed Domains check, no Bundle ID / attestation check, no IP allowlist. Nothing is blocked.Building and iterating. You can wire the SDK, test locally, and run on any device before your identity checks are set up.
ProductionEvery gate is enforced: Allowed Domains (web origin), attestation / Bundle ID (native binary), and the IP allowlist (server). Requests that don’t match are rejected.Shipping to real users. Turn it on once your domains and/or bundles are verified.
Development mode being fail-open is a convenience, not a hiding place. The moment you go live, the same requests that "just worked" are held to the full security posture — so verify your domains and app identity before you flip the switch, not after users hit errors.

What Development mode limits

Development mode is meant for building, not running a real product on — so a draft app carries two caps. They are the same for every app type and every language (web, native, server), and both lift automatically the moment you go live. You never configure them.

LimitWhat happens at the ceilingWhy
10 usersunique signed-up usersThe 11th sign-up is refused with go_live_required (403) across every sign-up path — hosted auth, OAuth, and the store. Existing users keep working. The app owner also gets a one-time email.A forcing function: once a draft has real users, it should be secured. The cap is flat and plan-independent — you can’t buy your way past it, you go live (verify a domain or register a bundle).
50,000 requests / dayper app, per UTC dayOver the cap, SDK requests are refused with draft_volume_exceeded (429) until the next UTC day.A generous anti-abuse backstop on an un-secured draft key — high enough never to bother real development, low enough to blunt a bot hammering a leaked draft key.
Both caps are fail-open on Onelo's side — a transient database blip never blocks a sign-up or a request; the caps are a business/anti-abuse gate, not a security boundary. And to be clear about the flip side: because Development is fail-open on security too (no domain / binary / IP checks — see above), the caps are what keep an unsecured draft key from being used as a free production backend. Going live lifts the caps and turns the security gates on — they move together.

The Production Readiness gate

Going live and getting a live key are two separate things — and the live key is the one Onelo guards. A developer could otherwise mint a pk_live_* with nothing configured, ship it in a binary, and only discover at runtime that the gate is wide open (no verified domain, no bundle ID). So Onelo will not issue or rotate a live key until the app passes the readiness checks for its type.

This is enforced server-side, not just in the dashboard UI. A rotate request for a live key on an app that isn't ready is refused with HTTP 412 and the error code live_key_preflight_failed — the response carries the per-check preflight breakdown so you can see exactly what's missing. Nothing is minted until every blocking check passes.

The gate re-runs on every live-key rotation, not only at first issue. If your readiness regressed since the key was created — say the verified bundle row was deleted — Onelo refuses to mint a fresh key with that weaker posture. Clearing the bar is the developer's responsibility; Onelo only guarantees it was cleared.

What each app type must clear

The readiness requirement mirrors the security gate that matters for that platform. A check that reports missing hard-blocks the live key; a pending check is a non-blocking advisory that still surfaces in the UI.

App typeRequirement to issue a live key
WebAt least one verified domain — a domain added and passed through domain verification (DNS TXT record or the hosted well-known file). See Allowed domains.
NativeiOS, macOS, Android, Electron, React Native, Flutter — at least one cryptographically verified Bundle ID. A hand-typed Bundle ID does not count: it must be registered from a real build via the discovery window (App Attest / codesign / Play Integrity, depending on platform). See App identity.
ServerNo hard requirement — the IP allowlist is advisory and the live pk is only an app identifier (real auth happens via your secret key). You're reminded if no secret key is configured, but it won't block going live.
Why so strict for native? A verified Bundle ID means the request genuinely came from a build Onelo can attest to — a value a developer can type but can't forge. Registering it through the discovery window on a real device (or a Play/TestFlight build) is what makes the guarantee hold once the key ships to users. Full walkthrough in App identity.

Next

Going live — Security — Onelo Docs