Publish runtime state

Console configuration does not affect app traffic until the environment has runtime state the data plane can serve. Publish after changing product actions, meters, limits, credits, plans, or customer rules that your app expects Valqio to enforce.

Publish flow

1. Model or update the product action, meter, usage control, plan, or customer policy.
2. Preview the runtime state for the selected environment.
3. Check resource counts and published product actions.
4. Publish the environment.
5. Generate or refresh the SDK client if your app uses generated bindings.
6. Run Workbench for a safe preview.
7. Run one app request and inspect decision evidence.

What publishing proves

A published runtime state should answer:

• Which product actions can the SDK call?
• Which meters, limits, and plans are active for the environment?
• Which environment sequence is the data plane serving?
• Are generated client bindings aligned with the published configuration?
• Can Workbench and app traffic reach the same allow or deny outcome?

Publishing is the handoff from configuration to runtime decisions.

Generated clients

When product actions are part of the published state, generated clients can expose domain-shaped helpers such as:

await customer.actions.sendInvoice.enforce({
  quantity: 1,
  idempotencyKey: `sendInvoice:${requestId}`,
})

Refresh generated clients after publishing changes that add, remove, or rename product actions. Your application should fail readiness checks rather than run billable work with stale bindings.

Generated client files come from Console or Valqio's SDK tooling for your project.

Safe rollout

Use separate environments for staging and production. Publish and test staging first, then publish production when the app, SDK bindings, runtime key, and evidence checks are ready.

If production behavior looks wrong, stop new product rollout traffic, inspect decision evidence, and publish a corrected runtime state before retrying.