App Metadata

Four scalar root properties shape your application's identity: name, version, description, and badge. Only name is required. The first three anchor Sovrium's append-only migration history; badge controls the "Built with Sovrium" attribution pill.

name: '@acme/crm'
version: 2.1.0
description: 'A CRM workspace for managing contacts, deals, and tasks.'
badge: false # optional — removes the "Built with Sovrium" badge

name

The app name follows npm package naming conventions. It is lowercase, URL-safe, and the only required property in the entire schema.

# Valid names
name: my-app
name: task-tracker-v2
name: '@acme/dashboard'

version

A Semantic Versioning 2.0.0 string (semver.org). Optional, but recommended — when present it labels the migration history described below.

version: 1.0.0 # Stable release
version: 2.0.0-beta.1 # Pre-release
version: 1.0.0+build.42 # Build metadata

description

A single-line description shown in the admin UI and metadata.

description: 'Full-featured e-commerce platform with cart, checkout & payment processing'

badge

A boolean controlling the "Built with Sovrium" badge — a small link pill rendered bottom-right on every page of your app. Optional; shown by default.

name: my-app
badge: false # removes the badge — one line, free, forever

The badge is pure server-rendered chrome with zero telemetry: a single static <a> linking to sovrium.com — no beacon, no pixel, no client-side JavaScript. Its label follows the page's active locale (English "Built with Sovrium", French "Construit avec Sovrium", English fallback for other locales); the text itself is not customizable. It appears on app pages, the default homepage, error pages, and standalone form pages — and is always absent from the /_admin operator console and from embedded (?embed=true) form variants.

Version history

Sovrium is a configuration-as-code interpreter: an app's configuration lives in its app.ts / app.yaml file (or the APP_SCHEMA environment variable) and changes only when that source changes and the app re-deploys. There is no runtime config-editing surface — no draft, no publish API, no admin-dashboard schema editor (the dashboard reflects runtime data, never configuration). Your own version control is the authoritative history of what the config was and when.

For observability, Sovrium keeps an append-only migration history inside the app's own database. Each time a schema change is applied on boot, one row is recorded with the applied version, a checksum of the schema, and the schema snapshot — an audit trail of exactly which schema the running app is on. Additive changes (new tables, new fields) apply live on boot; destructive changes are deferred to a restart for safety. See Migrations for how schema evolution is applied.

Reloading a running server

sovrium reload signals a running server to re-read its config file without a full restart, so an edit to app.ts / app.yaml takes effect in place. Because the file (or APP_SCHEMA) is the single source of truth, the live app never diverges from it at runtime — there is nothing to reconcile.

Next steps

• Schema Overview — all root properties at a glance.
• Configuration Files — how config-file and env transports load your app.
• CLI Reference — sovrium reload to reload the config in place.