Skip to main content
One-time setup at decision points. No code changes after that.Level 1: Hook Points (One-Time)You wrap your existing code at decision points:
// Before
func handlePayment(req PaymentRequest) Response {
    result := paymentService.Process(req)
    return result
}

// After (with LiveOps)
func handlePayment(req PaymentRequest) Response {
    ctx := liveops.BuildContext(req)
    decision := liveops.Evaluate(ctx, "http.request")

    if decision.ShouldBlock() {
        return decision.BlockResponse()
    }
    if decision.HasFallback() {
        return decision.Fallback()
    }

    result := paymentService.Process(req)
    return result
}
This is the only code change. You add it once per hook point.Level 2: Policy Changes (Zero Code)
ScenarioWithout LiveOpsWith LiveOps
Block a tenantCode change, PR, Review, DeployUpdate policy JSON, Hot reload
Add timeout overrideCode change, DeployUpdate policy JSON
Return fallback responseCode change, DeployUpdate policy JSON
Change retry countCode change, DeployUpdate policy JSON
Rollback bad changeRollback deployRevert policy JSON
Once hooks are in place, runtime changes require no code changes.
Feature flags toggle pre-coded variants. LiveOps injects new behavior.Feature Flags (LaunchDarkly, etc.)
// You must pre-code ALL variants
if featureFlag.isEnabled("use-new-timeout") {
    timeout = 500  // Hardcoded!
} else {
    timeout = 1000  // Hardcoded!
}
Limited to what you anticipated and coded.LiveOps
// Value comes from policy at runtime
decision := liveops.Evaluate(ctx, "call.before")
timeout := decision.TimeoutOverride()  // ANY value
Not limited to pre-coded variants.
This is the core architectural insight behind LiveOps.Invariants (Your Code)Structure, flow, and contracts that don’t change during incidents:
  • Request validation logic
  • Database schema and queries
  • API contracts (input/output shapes)
  • Business rules
  • Integration points (which services exist)
Dynamic Values (Policy)Operational parameters that might need to change at runtime:
  • Which requests to allow/block?
  • What timeout for this dependency?
  • What to return when dependency fails?
  • Who gets the new behavior?
  • How many retries?
The ProblemMost code mixes invariants and dynamic values. When “dynamic” parts need to change, you change code. That’s a deploy. That’s risk.The SolutionSeparate invariants (code) from dynamic values (policy):
InvariantsDynamic
ChangesMonthlyHourly / Per-incident
RiskHigh (deploy)Low (policy reload)
RollbackRedeployRevert JSON
OwnerEngineersEngineers + SRE + On-call
Yes. LiveOps is designed with production safety as the primary constraint:
  • Fail-open: Errors in patch evaluation allow requests through
  • Hard timeout: Evaluation terminates in under 10ms regardless of policy complexity
  • Pure evaluation: Engine returns decisions, never performs I/O
  • Deterministic: Same input always produces same output
  • Blast radius controls: Canary %, tenant targeting, region filtering
Test before you deploy:
  • Traffic capture: Record live production traffic for simulation
  • Policy simulation: Replay captured traffic against new policies to see exactly what would change
  • Diff reports: See which requests would be blocked, modified, or passed through before deploying
  • Canary rollouts: Start with 1% of traffic, validate metrics, then gradually increase
You know exactly what a policy will do before it touches production.
LiveOps policies are meant to be temporary runtime patches, not permanent infrastructure. Here’s the lifecycle:Step 1: Incident ResponseDeploy a policy to mitigate the issue immediately (seconds).Step 2: StabilizationPolicy runs in production. You validate it’s working. Days or weeks pass.Step 3: Code PromotionWrite the equivalent logic in your codebase. Deploy with the policy still active as a safety net.Step 4: Disable PolicyOnce the code is verified, disable the policy:
liveops disable payment-fallback
# or set canary_percent: 0
Takes effect in seconds.Step 5: Code Bug? Instant RollbackIf your new code has issues, re-enable the policy immediately:
liveops enable payment-fallback
You’re back to the known-good behavior in seconds while you fix the code.
PhaseWho handles the behavior
IncidentLiveOps policy (instant)
StabilizationLiveOps policy (validated)
Code deploymentBoth (policy as fallback)
Post-verificationCode only (policy disabled)
Code bug discoveredRe-enable policy instantly
Key insight: LiveOps acts as a safety net during code transitions, not a replacement for code.
Config and policy languages (CEL, OPA/Rego, flags) are designed to decide when something applies:
  • allow / deny
  • routing
  • targeting
  • percentage rollouts
They intentionally avoid executing new behavior.During incidents, you often need to introduce behavior that did not exist in the binary:
  • construct a degraded fallback response
  • change retry / timeout algorithms
  • apply temporary business logic to stabilize a dependency
That requires executing code.WASM is used because it is the safest way to execute late-bound code inside a running service:
  • strict sandboxing (no network, filesystem, or syscalls by default)
  • bounded CPU and memory
  • deterministic execution
  • language-agnostic authoring (Rust today)
CEL/OPA still play a role:
  • they decide when a patch applies and its blast radius
  • WASM defines what behavior executes when it does
Config selects. WASM acts.
This system does not try to make coding faster. It reduces time-to-safe mitigation by skipping the deployment pipeline.A normal deploy requires:
  • touching the main codebase
  • CI, builds, approvals
  • rolling restarts
  • coarse-grained rollout and rollback
Even small changes often take 60–120 minutes end-to-end.A WASM patch:
  • is compiled in seconds
  • can be simulated on recorded production traffic
  • can be applied to a 1–5% canary or specific tenants immediately
  • can be rolled back instantly without redeploy
This typically reduces mitigation time to 20–30 minutes during an incident.This is not a replacement for deployments. Patches are temporary stabilization tools used while the permanent fix is being deployed.

See It In Action

20-minute demo. No sales pitch.