Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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.

FlagWhat it does
--allow-dropPermit changes that lose data
--dry-runPrint 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.