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

Installation

FerroEHR is a single static binary that connects to a PostgreSQL 18 database. There is no application server to install and no runtime to provision — you choose how to run the binary and where the database lives. This part covers the three supported paths and the full configuration surface.

  • Docker Compose — the fastest way to run the server plus a preconfigured PostgreSQL 18, for development and evaluation: one downloadable file that pulls the published images and needs no configuration. Optional admin console, OIDC, and observability overlays.
  • Kubernetes & Helm — the production path: a hardened, non-root, default-deny workload that connects to an externally managed PostgreSQL 18.
  • From source — building the binary yourself with the pinned Rust toolchain.
  • Configuration reference — every FERROEHR_* environment variable, grouped by area, with types, defaults, and meaning.

Whichever path you take, the server is configured entirely through FERROEHR_* environment variables (with optional mounted TOML files for values that do not fit cleanly in env, such as a Basic-auth user store or an OIDC block). The database schema is created and updated by the binary’s migrations, which run automatically at boot.

Choosing a specification generation

One top-level key, spec_profile, selects which openEHR specification generation set the deployment runs — development (the default: Reference Model 1.2.0 with BASE 1.3.0) or stable (the latest released generations: Reference Model 1.1.0 with BASE 1.2.0). It is a single coupled choice, and stable → development is always safe while the reverse is not, so decide it before you commit clinical data. The full semantics, defaults, and the direction contract are in spec_profile.

Note

A Clinical Data Repository stores PHI. In production the database must be an externally managed, backed-up, point-in-time-recoverable PostgreSQL 18 — never a throwaway sidecar. The Kubernetes chart deliberately ships no in-cluster database for this reason.