Self-HostedInfrastructure

Scope: technical owner. Architecture, build, deployment and operations — with no dedicated ops or platform team behind it.

Virtualization and hosting. Everything runs on Proxmox — bare-metal virtualization, meaning the machines, the VMs, the networking, the backups, and the upgrades are all owned. Not a managed platform; the hard parts are mine. Dokploy provides a self-hosted PaaS layer for application deployment on top.

ERP. Deployed and maintained Frappe/ERPNext, and wrote installation scripts to make the deployment repeatable. Frappe is a notoriously involved install; the script means the deployment can be rebuilt after a failure instead of being a one-off.

Telephony. Custom applications and scripts integrating with Asterisk and FreePBX, both to extract operational data from the phone system and to streamline the work of the operators using it. Most web developers never touch a phone system.

Automation. n8n for workflow automation, plus cron jobs and shell scripts across multiple servers for scheduled operations. This layer decides whether the stack runs itself or needs someone watching it.

Data collection. KoboToolbox — the standard humanitarian data-collection platform, used across the sector for field surveys and needs assessments.

Security and support. Self-hosted Bitwarden for credential management, RustDesk for remote support.

Applications. Websites and web applications built, architected and maintained across the organization's programmes. One public-facing site among them was built on a purchased template. The claim here is the infrastructure, not that site.

Self-hosting turns recurring per-seat licence costs into hardware and one engineer's time — if someone can operate it. That operating capability is what this page demonstrates.

The result: an ERP system, a phone system, workflow automation, secure credential management, field data collection, and the organization's web presence, all running on infrastructure the organization owns outright, with no vendor able to raise prices or discontinue a product they depend on.

Eight production services, and no second person to catch a mistake before it reaches users. Every update has to land without breaking the systems that depend on it.

Backups are automated and offsite — the compute may sit on one machine; the data never does.

That forces a discipline a larger team never has to develop: anything done twice gets scripted, anything that depends on someone remembering gets automated, and every change to a live, stateful system is planned before it's made.

Backups are automated, offsite, and restore-tested. On top of scheduled verification, every migration and upgrade is performed by restoring from backup — so the recovery path is proven against real data each time the infrastructure changes, not just when a test says so. If a restore fails, it fails visibly, long before an emergency needs it.

Incidents in this environment aren't exotic: a mobile-signal coverage drop takes telephony quality down, or a power cut reboots a host and the operator panel doesn't come back on boot. The fix for the second is service supervision and start-order dependencies, so the next power cut passes without incident. Infrastructure work here means designing for an environment where electricity and signal are part of the threat model, not just disks and processes.