e-volv

e-volv LaunchOpt-in

Flags your agents clean up

Flags evaluated behind an HTTP API and targeted per environment, with production changes held at an approval gate. Switch it on and an agent removes each flag from your codebase once it is finished with.

  1. Ruleset published
  2. Development
  3. Staging
  4. Approval
  5. Production

One ruleset, three routes set. Development and staging are already serving it; production stands at the gate until a named human clears it. The kill switch is the one change that never waits. Timings illustrative.

What it does

Four things, and two of them are off until you ask. Both of those change something of yours without you watching, so neither is on by default in a new workspace.

  1. Evaluated in your process

    Fetch your environment’s whole ruleset once and resolve every flag locally from then on. A flag check is a memory read, not a network call, so it cannot be slow and it cannot fail your request. When our control plane is unreachable you keep serving the last ruleset you had.

  2. Targeted per environment

    Development, staging and production hold their own targeting and their own keys, so the same flag is independently on in one and off in another. Production can require an approval before a change applies, and the kill switch never waits for one.

  3. Removed when it is doneOpt-in

    Every vendor can tell you a flag is stale. A scheduled agent run finds the flags serving one variant everywhere past their removal date, deletes the branch from your repository and opens one pull request per flag, held at an approval gate, never merged unattended. Switched on per workspace, and off until you ask: it edits your repository.

  4. Watched by ObserverOpt-in

    A rollout that correlates with a new error group raises a finding naming both, with the occurrence count and how long after the change it appeared. Opt a flag in and the guard can kill it outright, writing its evidence to the flag’s history. Switched on per workspace, and off until you ask: it changes production without a human in the loop.

The order a flag is read in

A flag is resolved in one pass, in this order, in your process. The first rule that answers is the answer.

  1. Killed

    Nothing overrides a kill.

  2. Prerequisites

    A gate flag must be serving its variant.

  3. Rules, in order

    First match wins: clauses and segments.

  4. Rollout

    Bucketed on a hash of the flag key and the subject.

  5. Default

    What everyone else gets.

What a reviewer asks

SDKs are available today for Node.js, Browser, Edge runtimes, Python, Go, Ruby, Rust, Java and Kotlin (server), Android, iOS and macOS, and React Native. OpenFeature providers ship for Node.js, Browser, Python, Go, and Java and Kotlin (server). Every other platform is listed on the SDK page with its status.

  1. Your keys, your spend

    Bring your own model credentials. We never hold the bill for your agents.

  2. Append-only history

    Every change records who, what, which environment, before and after.

  3. Approval gates

    Production changes can be held until a second person decides. You cannot approve your own.

  4. Client-safe keys

    A browser or mobile key receives evaluated values, never your targeting rules.

  5. Kill switch

    Beats every rule, applies instantly, and preserves the targeting underneath it.

  6. Evaluations, never metered

    On every plan. You pay for environments and the flags you keep, never per check.

Put a flag behind it

Every workspace has Launch. The two capabilities marked opt-in stay off until you turn them on.

Start freeInstall an SDK

We use only essential cookies to keep you signed in and the app working. With your consent we may enable optional analytics to help us improve e-volv. See our Privacy Policy and Terms.