rototo introduction

rototo is a control plane for runtime configuration in application code.

Runtime configuration is production control. A value can change which code path runs, what limit applies, which account class receives different handling, which model an agent uses, or what operational message a user sees. Those decisions often need to change after an application is deployed, but they still need review, validation, rollback discipline, and an explanation when production behavior is questioned.

rototo puts that control plane in a Git-versioned workspace. The workspace is the reviewed boundary for runtime behavior, and Git remains the source of truth. Applications do not embed the final values in the binary. They load a workspace source, resolve named variables at runtime, and can refresh from that same source as reviewed configuration changes are released.

Why runtime configuration needs a control plane

A configuration value is rarely just a string or number. It usually answers an operational question:

• What should this service do in prod?
• Does this request match a reviewed account condition?
• Which structured value is valid for the code that will consume it?
• Why did the application select this value for this request?
• Can a running service pick up a reviewed change without redeploying?

When those answers live in environment variables, application branches, feature flag rules, and one-off exceptions, the production behavior becomes hard to audit. The value may be visible, but the reason it was selected is scattered. The validation may happen too late. The rollback path may depend on who remembers where the value came from.

rototo addresses that failure mode by making runtime configuration a workspace that can be inspected, linted, tested, reviewed, loaded, refreshed, and resolved with an explanation.

The smallest model

A rototo workspace contains the files that define runtime configuration behavior:

• A workspace manifest declares the environments the workspace supports.
• Context describes runtime facts supplied by the application, such as account plan, request country, or tenant id.
• Qualifiers turn those runtime facts into named reusable conditions.
• Variables define named configuration values and select among them by environment and qualifier rules.
• Schemas validate context and structured values before application code depends on them.

Those nouns are deliberately narrow. A workspace is the control-plane boundary. An environment names the deployment lane. Context is request-time input from the application. A qualifier is a reviewed condition. A variable is the value the application asks for.

The runtime loop

The production loop is:

review workspace change in Git
  |
  v
lint and test representative resolutions
  |
  v
release the workspace source
  |
  v
application loads the workspace at startup
  |
  v
application resolves variables with environment + runtime context
  |
  v
long-running service refreshes the workspace source

Successful refreshes affect future resolutions. Failed refreshes keep the last successfully loaded workspace active, so a transient source failure does not erase known-good configuration. Immutable commit refs are reproducible, but they do not produce new refresh results because the ref itself does not move.

One concrete resolution

Suppose an application asks for llm-agent-config in prod.

The application supplies runtime context:

{
  "account": {
    "plan": "enterprise",
    "seats": 250
  },
  "request": {
    "country": "DE"
  }
}

rototo validates that context, evaluates qualifiers such as enterprise-accounts, checks the prod rules for llm-agent-config, selects the matching value, validates the selected JSON shape, and returns the value to the application.

The important part is not only that a value was returned. The workspace records where the value came from, which condition matched, which environment was used, and what schema protected the application boundary.

What this lets you do

With this model, teams can:

• Change a production runtime value through Git review instead of an application redeploy.
• Keep deployment-lane defaults and runtime exceptions in one reviewed workspace.
• Validate structured configuration before the application consumes it.
• Reuse named conditions across variables instead of duplicating predicate logic.
• Test representative resolutions before merge.
• Refresh long-running services while preserving last-known-good behavior.
• Investigate why a value was selected for a given environment and context.

Where to go next

Read Why rototo for the production failure modes that led to this model.

Read Quickstart to create a small local workspace, lint it, and resolve one variable.

Read Production workflow for the Git-backed workflow: schemas, qualifiers, variables, tests, application loading, refresh, and observability.

Read The rototo model when you need the full vocabulary and resolution flow.

Use the bundled CLI docs when working from a terminal:

rototo docs
rototo docs -p quickstart
rototo docs -p production-workflow
rototo docs -s refresh