Command line
One binary, four commands. Every one of them takes its configuration from the environment — see Configuration.
$ runtime --help
Usage: runtime <COMMAND>
Commands:
serve Serve an application model
model Work with a model bundle: validate it, or emit its JSON Schema
db Bring the database in line with the model, or show what that would take
config Print the effective configuration and exit
runtime model validate <bundle>
Check a bundle and report everything wrong with it.
$ runtime model validate myapp
northwind — 1 module, 3 entities — ok
Reports every problem, not the first — a model with four mistakes takes one round trip to fix rather than four. Needs no database and no network, so it belongs in a pre-commit hook and in CI.
Exits non-zero if anything is an error. Warnings (M9xx) do not fail it; see
Diagnostics.
runtime model schema
Print the JSON Schema for the model format.
runtime model schema > app-model.schema.json
Generated from the same Rust types that parse your model, so it cannot drift from what the runtime actually accepts. Point your editor at it and you get completion and inline errors while you type.
runtime db plan <bundle>
Show what provisioning would change, without changing anything.
$ runtime db plan myapp
plan: app 0.1.0 -> 0.2.0 (schema version 1 -> 2)
[additive] add column sales.customer.nickname varchar(40)
[destructive] soft-drop column sales.customer.fax (renamed to _dropped__fax__v2, data kept)
Safe to run against production, and worth running there. This is what a reviewer reads before a deploy: every change is classified, and the ones that would take a lock or lose data say so.
runtime db apply <bundle>
Bring the database in line with the model.
| Flag | What it does |
|---|---|
--allow-drop | Permit changes that lose data |
--dry-run | Print the plan and stop, as plan does |
Everything happens in one transaction — the DDL, the bookkeeping and the advisory lock — so a migration that fails halfway leaves the database exactly as it was rather than in a state no plan describes.
--dry-run exists as well as the plan subcommand so a deployment script can
use one command and a flag rather than branching.
--allow-drop does not override a refusal. If the planner cannot tell a
rename from a delete-plus-add, it refuses and no flag changes that: the flag
means “I meant to lose this”, and a refusal means it cannot tell what you meant.
Declare the rename with previousName.
runtime serve <bundle>
Serve an application model. Needs RUNTIME_DATABASE_URL at a minimum.
RUNTIME_DATABASE_URL=postgres://... runtime serve myapp
Loads and validates the bundle, compiles every flow, connects the database and
discovers the identity provider — all before binding a port. A syntax error in a
script is a failure to start rather than a 500 for whoever calls that flow
first.
runtime config
Print the effective configuration and exit.
$ runtime config
Config { app_addr: 0.0.0.0:8080, admin_addr: 127.0.0.1:9090, ... }
Because “which value actually won” is a question asked at the worst possible moment, and answering it should not require attaching a debugger.