Linumed Base
An Ansible-based IaC kit that turns a standard Debian 13 installation into a hardened, GDPR-aware healthcare infrastructure platform: HL7/FHIR integration, monitoring, reverse proxy, and encrypted backups.
It is not a Linux distribution. There is no custom kernel, no installer image, nothing to boot. It is a collection of Ansible playbooks and roles that configure a standard Debian 13 (Trixie) server you install yourself.
What it includes
| Component | Role |
|---|---|
| Debian 13 hardening | SSH, ufw, fail2ban, unattended-upgrades |
| Caddy | Reverse proxy with automatic TLS |
| BridgeLink | HL7 v2 / FHIR R4 integration engine (MPL-2.0 fork of Mirth Connect) |
| Prometheus, Grafana, Loki, Alertmanager | Observability stack - log shipping via Grafana Alloy, host metrics via native Node Exporter |
| restic | Encrypted backups |
Status
v0.2.0 is tagged.
Every role passes a full site.yml
double-run against a throwaway VM - idempotent on the second run - and, separately,
against a real Debian 13 netinst install. That double-run now runs in CI on every
change, not only when someone remembers to start it. A second, independent systemd
timer restores backups into a throwaway target weekly and diffs the result against
the live source, so a restore test is not the same thing as a successful backup job.
Equally important: the limits. No bundled identity provider - every management interface (Grafana, Prometheus, the BridgeLink admin UI) binds to loopback only and is reached over an SSH tunnel. No Kubernetes support. Debian 13 is the only supported target. No application software is included - Linumed Base configures the platform underneath, not the app running on it.
System requirements
Measured, not estimated: each row is a real site.yml
(or role subset) deployment against a fresh Debian 13 VM, sized down until it still
deployed cleanly, then measured after a settle period so short-lived install-time
spikes don't inflate the number.
| Stack | RAM (allocated / used) | vCPUs | Disk (used) |
|---|---|---|---|
| common + docker + caddy | 1 GB / 381 MB | 1 | 1.6 GB |
| + monitoring | 2 GB / 903 MB | 2 | 4.6 GB |
| Full stack (+ bridgelink + backup) | 4 GB / 1.6 GB | 2 | 6.0 GB |
| Full stack, comfortable | 6 GB / 1.7 GB | 3 | 6.0 GB |
1 vCPU is the minimum, not a recommendation, even for the smallest stack - a busy first apply (package installs, image pulls) is visibly slower on a single core.
Quick start
git clone https://github.com/Linumed/Base.git
cd Base/ansible
cp -r inventory/example inventory/myhospital
# edit inventory/myhospital/hosts.yml and group_vars/linumed/vars.yml
ansible-playbook playbooks/site.yml -i inventory/myhospital --ask-vault-passDesign decisions
Why BridgeLink, not Mirth Connect
NextGen made Mirth Connect proprietary in March 2025. BridgeLink is the same codebase under an actively maintained MPL-2.0 fork with current container images, so the integration engine stays fully open source and patched.
ADR 0001 →Why the documentation is English
Linumed Base is not German in substance - nothing in the roles encodes German law or infrastructure. The target audience is international IT integrators, so the docs are written for them directly.
ADR 0002 →Loopback-only access, no bundled identity provider
Every management interface binds to loopback and is reached over an SSH tunnel. No identity provider ships with the kit, deliberately - less attack surface on a system aimed at hospitals.
ADR 0003 →VM tests in CI via the host's libvirt socket
Testing a role that touches the bootloader and disk layout needs a real VM, not a mock. This records why the CI runner is granted access to the host's libvirt socket to create one, rather than nesting virtualization.
ADR 0004 →License
MIT - see LICENSE in the repository.
Contact
To report a security problem, use security@linumed.com - never a public issue. See SECURITY.md for details.