Runtime configuration, reviewed like code.
rototo keeps your application's runtime configuration in a Git workspace: validated by lint, changed through pull requests, and resolved at runtime into typed values your services can trust. No config database, no side channel around review — the repository is the control plane.
One workspace, three guarantees
Declared
Variables, qualifiers, and JSON Schemas live as files under
rototo-workspace.toml. Every change has an author, a
diff, and a history.
Validated
Lint understands the workspace semantically: unknown qualifiers, values that break their schema, and rules that can never match are caught before merge, not in production.
Resolved
Applications load the workspace by source URI and resolve named variables with runtime context. Long-running services refresh from the same source and keep last-known-good state when a fetch fails.
What it looks like
# variables/checkout-redesign.toml
schema_version = 1
type = "string"
[values]
control = "classic"
treatment = "redesign"
[resolve]
default = "control"
[[resolve.rule]]
qualifier = "premium-users"
value = "treatment"
rototo variable resolve checkout-redesign \
--workspace git+https://github.com/acme/config#main \
--context user.tier=premium
SDKs that share one engine
The Rust core owns loading, lint, evaluation, and refresh; every SDK is a thin binding over it, so resolution behaves identically in every language.
Operate it from the console
rototo console serves a web console from the same binary as
the CLI: browse workspaces, trace how a variable resolves against saved
contexts, edit drafts on real branches, and publish pull requests. Run it
on your laptop with your own GitHub token, or behind your proxy with
GitHub OAuth for the whole team.