Deployment architecture

Quick reference

Three models, three decisions

Which model is right depends on three procurement-committee questions: where does PHI live (cloud vs your data centre vs your IT room), who maintains the infrastructure (us vs your IT team vs shared), and what's your data-residency requirement (Frankfurt EU default, on-prem in-country, or air-gapped).

Cloud

Managed multi-tenant

Default option. Hosted by us on Fly.io (Frankfurt by default; region pin available). PHI in EU-region encrypted storage. We manage everything. No infrastructure work for you.

Best fit

Most private hospitals 20-250 beds
Clinics on Starter tier
NGOs and donor-funded facilities

Per-hospital server

Air-gappable

One Linux server in your IT room. One tenant on it (your hospital, your data). Optional air-gap from the public internet. Your data never leaves your premises. We install, you operate (with our support).

Best fit

Private hospitals with strict data-locality requirements
Teaching hospitals that mandate on-premise
Mission hospitals in low-connectivity areas

Private cloud / on-premise

Your infrastructure

We deploy MediCare HIS into your existing infrastructure (your data centre, your private cloud, your colocation). You own the hardware lifecycle. We deliver, maintain, support.

Best fit

Enterprise / group networks with existing data centres
Government/ministry tenders requiring on-premise
Multi-site networks consolidating to one platform

Model 1 · Cloud (default)

Managed multi-tenant on Fly.io

Each customer gets a tenant subdomain at yourhospital.medicarehis.com. Tenants are isolated at the application layer via hospitalId scoping enforced in every database query. The whole platform runs on Fly.io machines in Frankfurt (region pin available for jurisdictional reasons). Cloudflare sits in front as the edge.

INTERNET
    │
    ▼
┌────────────────────────────────────┐
│  Cloudflare (edge)                 │
│  - TLS 1.3 termination             │
│  - WAF + Bot Fight Mode + DDoS     │
│  - Authenticated Origin Pulls      │
│  - Rate limiting                   │
└─────────────┬──────────────────────┘
              │ TLS 1.3 + X-Origin-Auth
              ▼
┌────────────────────────────────────┐
│  Fly.io Frankfurt (origin)         │
│  - Express + Node.js app           │
│  - Immediate deploy strategy       │
│  - Health-check guarded            │
│  - LUKS-encrypted volume           │
└─────────────┬──────────────────────┘
              │
        ┌─────┴─────┬───────────┬─────────┐
        ▼           ▼           ▼         ▼
   ┌────────┐ ┌──────────┐ ┌───────┐ ┌────────┐
   │ Tenant │ │ Audit    │ │ Local │ │ Sub-   │
   │ DB     │ │ chain    │ │ back- │ │ proc.  │
   │ files  │ │ + mirror │ │ ups   │ │ ─────  │
   │        │ │ to B2    │ │       │ │ Resend │
   └────────┘ └────┬─────┘ └──┬────┘ │ Sentry │
                  │           │      │ UR     │
                  ▼           ▼      └────────┘
              ┌──────────────────┐
              │  Backblaze B2    │
              │  - Object Lock   │
              │    Compliance    │
              │    (7-yr ret)    │
              │  - Client-side   │
              │    AES-256-GCM   │
              └──────────────────┘

Sub-processors (cloud model)

Fly.io — application runtime. EU (Frankfurt) by default; region pin per-customer available. DPA signed.
Cloudflare — CDN, WAF, DDoS, DNS, Bot Fight Mode. Global edge. Network metadata only (no PHI body content visible at WAF layer for end-to-end TLS-terminated requests). DPA signed.
Backblaze B2 — off-host backup + immutable audit-chunk storage. EU region. Encrypted backups + audit chunks (client-side AES-256-GCM applied BEFORE upload). DPA signed.
Resend — outbound transactional email (password resets, notifications). EU. DPA signed.
Sentry — error reporting with PHI-scrubbed events. EU. DPA signed.
Anthropic — AI features (per-tenant opt-in only). No PHI without explicit per-tenant consent. DPA signed.

Network requirements

Outbound HTTPS from clinical workstations to *.medicarehis.com (port 443)
No inbound network rules required from your side
Optional: IP allowlisting on admin endpoints (Enterprise tier)
Bandwidth: ~50 KB per page load + ~5 KB per API request. A 50-bed hospital uses ~5-10 GB/month.

Model 2 · Per-hospital server

One Linux server in your IT room

A single dedicated Linux server, installed in your facility, runs your tenant of MediCare HIS. No other hospitals share the server. PHI never leaves your premises. We deploy via a hardened install script; you provide the hardware; we provide remote support via a tunnel that you can shut off at any time.

Hardware specifications (reference)

Small (clinic — up to 4 clinicians)

CPU: 4 cores (any modern x86_64 or ARM64)
RAM: 8 GB
Storage: 256 GB SSD
OS: Ubuntu 24.04 LTS or Debian 12
Network: Gigabit LAN + UPS-backed
Reference cost: ask your local hardware supplier — entry-level rack server

Medium (hospital 20–100 beds)

CPU: 8 cores
RAM: 16 GB (32 GB for 50+ beds)
Storage: 1 TB SSD (RAID-1 mirror recommended)
OS: Ubuntu 24.04 LTS or Debian 12
Network: Gigabit LAN + UPS + battery backup
Reference cost: ask your local hardware supplier — mid-range rack server with RAID-1

Air-gap option

Some hospitals require complete network isolation. The per-hospital server can run fully air-gapped — no outbound internet at all. Trade-offs: no automatic Cloudflare-edge protection (replaced with your firewall), no automatic backup to off-host storage (replaced with weekly USB-drive rotation), no automatic DHIMS2 submission (replaced with manual CSV export). Updates delivered via signed offline package. We document this option for procurement teams who need it.

Connected-but-isolated (recommended)

The middle ground: server runs on your LAN, outbound HTTPS to *.medicarehis.com for updates and backup, inbound limited to your hospital's LAN. PHI never leaves your premises during operation; backup goes off-host (client-side encrypted; your encryption key) for disaster recovery. This is what we'd suggest for most facilities.

Model 3 · Private cloud / on-premise data centre

Deploy into your existing infrastructure

For enterprise / group / ministry-scale customers who already operate their own data centre or private cloud (VMware, Proxmox, OpenStack, AWS GovCloud-equivalent in-country, etc.). We deliver MediCare HIS as a containerised application that runs on your infrastructure. You own the hardware lifecycle; we own the application lifecycle.

What we provide

Container image (signed) deployable to Docker, Kubernetes, Podman, or bare-metal Linux
Deployment scripts for the major orchestrators
Configuration documentation including secrets management, TLS, backup rotation, DR runbook
Update channel: signed binary releases on a quarterly cadence (or faster for security fixes)
Support per the support model document

What you provide

Compute, storage, network infrastructure
TLS certificate management (or use Let's Encrypt; we can configure)
Backup infrastructure (we'll integrate with your existing backup posture)
Monitoring infrastructure (we integrate with Prometheus, Grafana, ELK, Splunk if you have them)
IT team capable of routine Linux administration

Across all three models

Tenant isolation and data residency

Application-layer tenant isolation — every database query is scoped by hospitalId. Cross-tenant access attempts return 404 (not 403) to defeat enumeration. Pinned by 21+ cross-tenant unit tests.
Per-tenant subdomain — your hospital reaches the system at yourhospital.medicarehis.com (cloud) or your own domain (on-prem). Session cookies are host-scoped; no cross-tenant cookie bleed possible.
Per-tenant encryption keys — Stage 2 capability for highest-sensitivity field-level encryption. AES-256-GCM envelope primitive already in the codebase; rollout per-field is a clinical + compliance decision.
Data residency — Cloud default is Frankfurt EU. Region pin to Singapore, Sydney, Johannesburg or São Paulo available at Enterprise tier. On-prem and per-hospital server models put data in your facility by definition.
Sub-processor disclosure — full list with EU-region designations in our compliance roadmap. Any change is customer-notified ahead of activation per our DPA template.

Migration between models

You can change deployment models later

Cloud → per-hospital server and the reverse are both supported. Cloud → private cloud is supported. Migration is a flat fee (scoped to your data volume) — not a percentage of your contract. Full data export is one click at any time regardless of deployment model.

Companion documents: Procurement evidence pack · Brochure · Security whitepaper · Compliance roadmap · SLA · Support · Onboarding

Deployment architecture

Three models, three decisions

Managed multi-tenant on Fly.io

Sub-processors (cloud model)

Network requirements

One Linux server in your IT room

Hardware specifications (reference)

Small (clinic — up to 4 clinicians)

Medium (hospital 20–100 beds)

Air-gap option

Connected-but-isolated (recommended)

Deploy into your existing infrastructure

What we provide

What you provide

Tenant isolation and data residency

You can change deployment models later

Want a deployment-specific walkthrough?