Sovrium

Write one config file. Run a complete web app.
Database, REST API, sign-in, pages, forms, automations, AI agents and an admin console, interpreted from YAML, JSON or TypeScript by a single binary you run wherever you like.

Website · Docs · Quick start · CLI · Templates · Changelog · Issues

1. Write a config. Twenty lines of YAML:

# app.yaml
name: my-crm

tables:
  - id: 1
    name: contacts
    fields:
      - { id: 1, name: name, type: single-line-text, required: true }
      - { id: 2, name: email, type: email, unique: true }
      - { id: 3, name: status, type: single-select, options: [Lead, Active, Lost] }

auth:
  strategies:
    - type: emailAndPassword

pages:
  - name: home
    path: /
    components:
      - { type: text, element: h1, content: My CRM }
      - { type: table, dataSource: { table: contacts } }

2. Run one command.

sovrium start app.yaml
# → http://localhost:3000
# → Admin console: http://localhost:3000/_admin/login

3. Here is what you now have — every row observed on a running instance of exactly that file:

There is no code generation step: Sovrium interprets the config at runtime, so the file stays the single source of truth. Under sovrium start --watch, saving the file reloads the running app.

• What Sovrium is
• Features
• How it works
• Install
• Quick start
• Templates
• CLI reference
• Configuration
• Built for AI agents
• Deploy
• Where Sovrium fits
• Free and paid
• How this is built and tested
• Documentation
• Status
• Contributing
• Security
• License

Sovrium is a configuration-as-code interpreter. You describe what your application contains (tables, roles, pages, forms, automations, agents) in one configuration file, and the binary builds and runs the whole application from it, together with the operational console to run it.

• Sovrium is a way to build internal tools, CRMs, back offices, client portals, content sites, documentation sites and APIs from a file you keep in Git.
• Sovrium is not a framework you program against, a no-code builder you click through, or an in-app editor. The configuration is code: it is written in a file, reviewed, committed and redeployed.

Sovrium runs on your own machine or server. Sovrium Cloud is the optional managed hosting for teams that would rather not run it themselves.

Each row is a part of the configuration you declare. The feature documentation covers every option.

  app.yaml / app.json / app.ts            sovrium (one binary)                     a running app
 ┌───────────────────────────┐      ┌─────────────────────────────┐      ┌──────────────────────────────┐
 │ tables, auth, pages,      │      │ 1. decode + validate        │      │ /           your pages       │
 │ forms, automations,       │ ───▶ │ 2. migrate the database     │ ───▶ │ /api/...    REST API + auth  │
 │ agents, design, buckets…  │      │ 3. serve, schedule, watch   │      │ /_admin     operator console │
 └───────────────────────────┘      └─────────────────────────────┘      └──────────────────────────────┘
           in your Git                SQLite or PostgreSQL, local             reloads when the file
                                      disk or S3, your AI provider            changes (--watch)

1. Validate. The config is decoded against one schema. An unknown key or a wrong value is refused with a message naming the path and the fix; nothing is silently ignored. sovrium validate runs this step alone, with no database.
2. Migrate. On boot, Sovrium compares the declared tables with the database and applies the difference in a transaction.
3. Serve. One process serves the pages, the API, authentication, file storage, automations and the admin console. Under --watch, a saved change reloads the app.

The standalone binary needs neither Node nor Bun.

# macOS / Linux — install script (verifies the published sha256)
curl -fsSL https://sovrium.com/install | sh

# Homebrew (macOS / Linux)
brew install sovrium/tap/sovrium

# Scoop (Windows)
scoop bucket add sovrium https://github.com/sovrium/scoop-bucket
scoop install sovrium

# Docker
docker pull ghcr.io/sovrium/sovrium:latest

Desktop app. Sovrium also ships as a desktop app for macOS (.dmg, Apple silicon and Intel), Windows (installer) and Linux (AppImage or .deb), from the download page or the latest release. It is the same engine in a window: it creates a project folder from a template, runs the server for you and shows the app. The config it writes runs unchanged under sovrium start. See The Sovrium App.

Already installed? sovrium update keeps you current whichever way you installed: it replaces a raw binary, or hands over to brew upgrade / scoop update.

The sovrium npm package is deprecated: Sovrium ships as a binary, and nothing is published to npm. A TypeScript config needs no package either (see Configuration).

Requirements. None for a trial: Sovrium defaults to embedded SQLite and local file storage. For production, point DATABASE_URL at PostgreSQL 15+.

# 1. Scaffold an app from a template (drop the template flag for a blank starter)
sovrium init my-crm --template crm
cd my-crm

# 2. Check the config without starting anything
sovrium validate app.yaml
# → Valid configuration: kestrel-crm

# 3. Optional: load the template's sample data (accounts take this password)
SOVRIUM_SEED_PASSWORD='choose-a-password' sovrium seed app.yaml

# 4. Run it, reloading on every save
sovrium start app.yaml --watch
# → http://localhost:3000

• A blank TypeScript starter: sovrium init my-app --typescript writes a typed app.ts with its tsconfig.json. (--typescript cannot be combined with --template: a template ships its own config.)
• The first admin: set AUTH_ADMIN_EMAIL and AUTH_ADMIN_PASSWORD before the first start, or run sovrium admin create [email protected]. The three ways are in Admin & Maintenance.
• A static site: sovrium build app.yaml writes the pages to ./dist for content that needs no server.

sovrium init --template <name> copies a complete, runnable app, and sovrium templates lists the names the binary you run carries. Each one is also published as its own GitHub repository, which the same flag reads when given <owner>/<repo> instead of a name (for example sovrium/crm-template), and each can be opened from the desktop app.

sovrium --help prints all of this; sovrium docs cli-api/cli explains it in full. A config path is optional wherever it is shown in brackets: Sovrium finds app.yaml, app.json or app.ts in the current directory.

Environment. Every variable is optional; Sovrium runs with none. The ones you meet first: PORT (default 3000), BASE_URL, DATABASE_URL (PostgreSQL; omit for SQLite), AI_PROVIDER, STORAGE_PROVIDER, SOVRIUM_ENCRYPTION_KEY. The full list is in .env.example and Environment variables.

A config is one object, written in the format you prefer:

• YAML or JSON, split across as many files as you like with $ref.

• TypeScript: run sovrium types and the binary writes the types it accepts next to your config, so your editor completes and checks it. No package.json, no node_modules, no install:

  // app.ts
  import type { AppConfig } from 'sovrium'
  
  export default { name: 'my-app' } satisfies AppConfig

• In your editor: point it at the published JSON Schema, https://sovrium.com/schema/app.json, or print the one your binary accepts with sovrium schema.

The root keys are name, tables, auth, pages, forms, automations, agents, connections, buckets, design, languages, analytics, redirects, links, assets, env and a few more; Schema overview describes each.

Sovrium is written to be read and edited by a coding agent as easily as by a person.

The edits always land in the config file, and the ordinary watcher applies them. There is no editing endpoint over HTTP.

The same config runs everywhere the binary or the container runs:

Before going live, read Security hardening and set a public https:// BASE_URL.

Sovrium covers, from one config, the jobs teams usually spread across separate tools.

Moving data in: Migrate from Airtable and Migrate from Zapier.

What stays the same whatever you build: the app is a file in your Git, the code is source-available, and it runs on your own machine or server as one binary or one container.

The Sovrium engine, the desktop app and local AI editing with your own key are free; Sovrium Cloud sells managed hosting, collaborative and managed-AI editing — the hosted config-editing plane — because the line is whose compute runs it, and the self-hosted product never ships a visual or AI config editor.

This repository is a filtered mirror of a private development monorepo. The test suite, CI workflows, lint configuration and internal tooling are excluded by an allowlist in the release pipeline, so you will not find them here. They exist: more than 1,250 Playwright spec files holding more than 15,000 end-to-end tests, traced to more than 1,250 user stories, plus co-located unit tests for the domain model and the tooling. A small number of specs are still tracked test.fixme() placeholders.

Every acceptance criterion is one @spec test carrying the ID of the user story it satisfies, and each spec file also has one @regression test that replays those criteria as a single continuous workflow. CI runs the regression tier and a packaging tier against the compiled binary.

There is deliberately no published code-coverage percentage, because none is measured: the gate is a test-file presence invariant, not a line threshold.

How Sovrium Is Built covers all of this in full, along with why the development infrastructure is private, the security posture (including the absence of any third-party penetration test), and what happens to your instance if the company stops.

The full documentation lives at sovrium.com/docs, and the same manual ships inside the binary (sovrium docs).

Runnable example configs ship in src/templates/; sovrium templates lists them.

Sovrium is a feature-complete MVP under active production hardening. Every domain listed above is implemented; a small number of specs, scattered across domains, are still tracked test.fixme() placeholders.

"Implemented" means the behaviour is built and locked by a spec. That is a distinct bar from long-term production hardening, which continues as the platform matures. Release notes are in CHANGELOG.md, and sovrium changelog --since <version> prints what changed since your upgrade.

Sovrium is developed and maintained by the core team. The most valuable way to help is to tell us what you need:

• Found a bug? Run sovrium report (or sovrium report --last-error after a failed command): it prints a prefilled issue address with your version and platform, and sends nothing. Add clear steps to reproduce.
• Want a feature? Open an issue describing the use case it solves.

Every issue is read and triaged.

This repository is a filtered mirror of a private development monorepo, so a pull request here cannot run the test suite or the CI pipeline that gate a change. How Sovrium Is Built explains what that means for contributions.

Opening issues is open to everyone. Submitting code requires becoming a certified contributor: write to [email protected] to get started. This keeps the contributor community small and reviewed. CONTRIBUTING.md has the full process.

To report a vulnerability, follow SECURITY.md, which also states the continuity commitment. Do not open a public issue for a security report.

Sovrium is source-available under the Business Source License 1.1: free for internal and non-commercial use; it prevents offering Sovrium as a competing hosted service. Commercial hosting licenses: [email protected].

The name and logo are covered by the trademark policy.

_{© 2025–2026 ESSENTIAL SERVICES · Sovrium is a trademark of ESSENTIAL SERVICES.}