Frequently asked questions

About two minutes. Sign up, create a project, copy the client SDK key, install @nightroll/js, and call client.isEnabled() — that's the full setup.

No. The 15-day trial requires only an email. At the end of the trial your workspace is frozen (read-only) until you choose a plan — your data is preserved.

Today: JavaScript, TypeScript, React, and Node.js as official SDKs. The REST API works from any language. SDKs for Python, Go, Java, Ruby, and PHP are on the roadmap and follow the same shape.

Most flag configs map directly: name, default variation, targeting rules. We'll add a CLI import tool when there's demand — in the meantime, the REST API accepts the full flag schema and you can script it.

In your process. The SDK keeps the latest flag config in memory and evaluates rules locally on every call — no network round-trip per check.

Sub-millisecond. Calls are local lookups, not network requests, so they stay fast even under heavy load.

Up to your SDK's refresh interval (default 30 seconds; configurable). The dashboard write is immediate; the SDK picks it up on the next refresh.

Each user gets a stable bucket per flag. A 10% rollout means roughly 10% of your users see it, and the same user always lands in the same bucket — across devices, sessions, and SDK upgrades.

We run on AWS across multiple regions and target 99.9%+ uptime. Flag config is cached in several layers — at the CDN edge, in the SDK's in-memory store, and (in browsers) in local storage — so even during a rare outage your code keeps evaluating with the most recent values.

We count unique user IDs per calendar month. Counting runs in the background, batched asynchronously, and never adds latency to your flag checks.

Your product keeps working. Flag config is cached at three independent layers — at the CDN edge, inside the SDK in memory, and (in browsers) in local storage. Your code keeps evaluating against the most recent values even if our service is unreachable. We run on AWS with multi-region redundancy.

Your product keeps working. The SDK falls back to its cached flags and slows polling until the next billing cycle or an upgrade. No errors propagate to your users.

No throttle — we don't block evaluation. Overage is billed at $1.00 per 1,000 additional MAU. We email warnings at 80% and 100% of plan so there are no surprise bills.

SDKs that still hold the deleted flag fall back to the default value you passed at the call site. No exceptions, no 500s.

Rotate it from the dashboard. Each project supports two active keys per type during a grace period so you can roll out the new key without downtime, then revoke the old one once you're confident.

Existing flags and projects are grandfathered — nothing breaks. You'll be blocked from creating new resources above the new plan's limits. Use the Billing page to start a downgrade; the dashboard will list anything you need to delete first.

Your workspace becomes read-only. All data is preserved; pick a paid plan to unfreeze. SDKs continue to serve the last config they fetched.

You keep full access until the end of your current billing cycle, and you can undo the cancellation any time before then. After it completes, your dashboard becomes read-only and SDK calls stop returning config — your code falls back to whatever default you pass to isEnabled() (typically false).

Conditions still match against attributes. Percentage rollouts can't fire (we need an id to assign a stable bucket), so the default variation gets served.

Solo $9/mo — 1 project, 1,000 MAU, 1 seat, 20 flags. Starter $19/mo — 5 projects, 25,000 MAU, 5 seats, 100 flags. Team $99/mo — 25 projects, 250,000 MAU, 25 seats, 1,000 flags. Enterprise — unlimited everything, contact sales. See /pricing for the full breakdown.

A unique userId passed to an isEnabled() / variation() call during the calendar month. Counted once per month, no matter how many evaluations.

Talk to us. Owner-controlled per-org overrides let us grant you a temporary or permanent increase on any limit without forcing a tier change.