DHIS2 Hosting Guide: Production Architecture, Security, Backups and Scale
A practical guide to production DHIS2 hosting covering architecture, PostgreSQL, monitoring, backups, security, availability and cloud deployment choices.
DHIS2 can be simple to install and still be difficult to operate well in production. A real deployment must account for application availability, PostgreSQL performance, security, monitoring, backups, upgrades, sensitive health data and the people who will maintain the system over many years.
The official DHIS2 hosting requirements describe the application server, PostgreSQL database, proxy and monitoring components that support production use. DHIS2 implementation guidance also stresses that production hosting requires much more planning than a basic development installation, particularly around security, performance, availability and long-term operations.
Design the production architecture around the workload
Start with user count, data volume, tracker versus aggregate workloads, analytics frequency, integrations, reporting peaks and availability requirements. A national-scale tracker system has different database and infrastructure needs from a small pilot or district implementation.
Separate the main responsibilities: reverse proxy and TLS, DHIS2 application runtime, PostgreSQL data, monitoring and backups. Larger systems may distribute those functions across multiple hosts or availability zones, while smaller systems can consolidate components if performance and recovery requirements still remain acceptable.
The correct DHIS2 hosting architecture is the one your team can secure, monitor, back up, restore and upgrade reliably—not simply the one that is easiest to provision.
Plan four production layers
A durable implementation should cover:
- Application layer: supported DHIS2 release, JVM/Tomcat configuration, patching and controlled upgrade process.
- Database layer: PostgreSQL performance, storage latency, access controls, backup, retention and recovery testing.
- Edge and security: TLS termination, firewall policy, identity, SSH controls, logging and restricted network paths.
- Operations: monitoring, alerting, capacity management, certificate renewal, incident response and maintenance ownership.
Backups only count when restore has been tested
DHIS2 guidance emphasizes automated backups and off-site retention. The operating team should know how frequently backups run, where they are stored, how long they are retained and who can restore them.
- Database backups: capture PostgreSQL consistently and protect backup credentials separately from production.
- Off-site copies: avoid keeping the only recovery copy on the same server or failure domain.
- Restore drills: periodically restore into a safe environment and document recovery time and missing dependencies.
Choose hosting by responsibility and constraints
On-premises, national data centers, commercial cloud and managed DHIS2 services can all be valid. Compare data-residency rules, available skills, procurement, support hours, connectivity, cost predictability and who is accountable during an incident. For sensitive health systems, the operating model is as important as the infrastructure provider.
Tanco Tech designs DHIS2 architectures, integrations and operational support around data protection and long-term maintainability. Explore our DHIS2 & Digital Health Services or discuss a production deployment.
