Features / Environments, Deploy & Promote
Environments, Deploy & Promote
Test and Live are two parallel worlds. Every feature's status, every pack, plan rule and targeting rule, the version number and the pending-changes counter — all of it exists twice, once per environment. You shape things in Test, deploy them so test builds can try them, then Promote the result into Live and deploy there for real users. Production keys only ever read Live.
Test vs Live
Which world a running app reads is set by one thing: ONELO_FEATURE_ENVIRONMENT — test or live. The SDK forwards it on every feature call and the backend honours it.
| SDK | How you set the feature environment |
|---|---|
| Swift | The featureEnvironment: init argument → the OneloFeatureEnvironment Info.plist key → the ONELO_FEATURE_ENVIRONMENT process variable (first one set wins). |
| Python | The feature_environment= argument → the ONELO_FEATURE_ENVIRONMENT environment variable. |
test on staging, live or unset in production). If you leave it unset, the SDK falls back to the environment implied by the key — but since secret keys are always live, the explicit variable is the only unambiguous way to point a backend at the Test world. The keys themselves are about trust — a publishable key (onelo_pk_live_*) for the client, a secret key (onelo_sk_live_*) for the server — not about which feature world you read.The Test / Live toggle at the top of the Features section scopes everything below it — Registry, Packs, Plans, Targeting, Inspect — and the choice is sticky per app. Each environment has its own version, its own pending counter, and its own Deploy button. Editing in Test only bumps the Test counter; deploying Test only publishes Test.
test: 1 pending when the other environment has unsaved changes — so you don't deploy Live having forgotten that Test still has drift, or vice-versa.Deploy — staging, then publishing
Nothing you edit is live immediately. Edits stage as pending; the SDK keeps serving the last deployed snapshot until you press the Deploy button for that environment.
Edit anything
unsaved changes).Click 🚀 Deploy to test / Deploy to live
ONELO_FEATURE_ENVIRONMENT), not by which key an app holds. Apps on the live stream pick up the change almost immediately; apps on the polling fallback on their next poll; offline apps on their next reconnect.The snapshot is promoted and broadcast
Connected instances — who's online, on which version
The deploy panel shows your live fleet — N apps online, a per-platform breakdown, and version bars (how many instances run each config version, and the % on the latest). Expand Show N connected instances for the detail; rows are grouped by (platform, app version, SDK version, config):
| Column | What it shows |
|---|---|
| Platform | The SDK platform — swift, python, electron, js, react-native, android, flutter. |
| App ver | Your app's version (— if the SDK doesn't send one). |
| SDK ver | The Onelo SDK version (e.g. 0.5.0a20). |
| Config | Which deployed version (e.g. v196) that instance is currently on — so you can see who is still behind right after a deploy. |
| Instances | How many running copies are in that group — shown as N when all are online, or online/total. |
| Last seen | "online" if live now, otherwise the time it last connected. |
Two filters: Platform (all, or a single platform) and Online only (on by default — uncheck to also list instances that are offline now, with their last-seen time and the last config version they held).
Promote to Live
Promote brings Live up to date with Test — it's the only way features enter Live, and the dashboard runs it in one direction (Test → Live). From the Registry in the Test environment, click ⤴ Promote to live. A summary modal opens — header "Promote to Live · Bring Live up to date with Test" — with "Everything's included. Review & choose what to hold back."
The diff is grouped into four dimensions, each collapsible, each with checkboxes so you can hold parts back:
| Group | What it carries across |
|---|---|
| ● Feature visibility | Each feature's status, what users on other plans see, and whether tapping it opens the upgrade flow — each shown as from → to. Uncheck one to leave Live's current setting untouched. |
| ● Plan access | Each feature's targeting rules as a matrix. Promote makes Live's rules for the feature a copy of Test's: markers show new (○), changed (●) and removed (✕) rules, and a “rule order” column when Live takes Test's order. |
| ● Packs | Packs to create or delete in Live, feature memberships joining or leaving a pack, and each pack's own rules (copied from Test like a feature's). Packs are matched across environments by name. |
| ● Targeting | Per-user targeting rules — added, changed, or removed — grouped by feature/pack. |
If Test and Live already match, the modal says so — "Test and Live are already in sync — nothing to promote." The Promote button reads Promote <N> → Live and is disabled if you hold everything back.
An AI agent connected to Onelo's MCP server makes the same choice with you, item by item. features.promote needs a hold_back list — the changes you chose to keep out, or an empty list to move everything — and without it moves nothing and hands the agent the list to ask you about. Releasing Live still waits for your click in the Onelo panel, and that approval lists every change the release publishes.
Clear all features
🗑 Clear all features (Registry header) is the nuclear option. It permanently deletes every feature for the app — both active and archived, across Test and Live — together with:
- All targeting rules and plan mappings
- All feature packs and pack items
- All per-user feature overrides
- All monitor events, aggregates, and history
ONELO_FEATURE_ENVIRONMENT=test) will re-register its slugs as hidden on the next batch-ping; builds running in Live are read-only, so the slugs stay gone until you re-add them.