Self-Hosted Infrastructure Engineering
Virtualization, containers, deployment pipelines and monitoring for systems that have to stay up.
Context
Self-hosted infrastructure engineering gets called in from two directions. Production is already running on something nobody documented: a server under a desk, a cloud account with charges nobody can explain, a set of containers one person knows how to restart. Or the opposite: the workloads should come back in house, for cost or for data residency, and there is no substrate to bring them back to. Either way the requirement is the same. Somewhere for things to run, a way to deploy that is not a person typing on a box, monitoring that notices before a user does, and documentation good enough that the next engineer does not have to reverse engineer it. The point is to hand it over, not to become the only person who can operate it.
Scope
What this covers
- 01Proxmox cluster design and operation, the usual base layer for self-hosted infrastructure engineering: multi-node Proxmox VE clusters, VM and LXC lifecycle, live migration, quorum monitoring and backup verification.
- 02Container platforms: Docker and Docker Compose, Traefik v3 as the reverse proxy and TLS edge, NGINX, and self-hosted PaaS layers with CapRover and Coolify.
- 03Provisioning automation for Debian LXC fleets: DHCP, dnsmasq DNS, systemd service management, SSH key injection and locked-down system users with no shell.
- 04CI/CD and GitOps: GitHub Actions with self-hosted runners, webhook auto-deploy, and infrastructure kept as code across separate repositories for infrastructure, deployment scripts, documentation and network state.
- 05Monitoring platforms: NetXMS, Prometheus node_exporter fleets with custom Python textfile collectors, and purpose-built workers for reachability and resource polling.
- 06Alerting that is actionable: a typed event taxonomy, deep links into the dashboard that shows the fault, and delivery into the channel the team already reads.
- 07Power and environmental telemetry as part of infrastructure: UPS monitoring over NUT, generator run state derived from UPS input status, and battery systems polled over a tunnel chain into the same dashboard.
- 08Database and storage operations: PostgreSQL, self-hosted Supabase, connection pooling, redundant backups, and recovery of failed backup chains.
- 09AWS estate architecture and operation, including IoT Core, RDS, Timestream, SQS, SNS and API Gateway, plus documented migration paths between self-hosted and managed services.
- 10Internal dashboards and operational tooling built to the estate rather than bought: device inventory, live camera detail over vendor APIs, SSH-based host health, and managed switch port and PoE state.
- 11Reliability engineering on the tooling itself: auto-restart wrappers, state pre-seeding on startup, batched writes to avoid write storms, and sequential sampling where parallel fetches produced wrong metrics.
- 12GPU and video workloads: recording platforms on NVIDIA GPUs with TensorRT and Coral accelerators, memory tuning, and diagnosis of container networking faults behind recurring outages.
Record
Work behind this
Delivered work, stated as facts rather than claims. Programs and employers are named where naming them is what makes the record checkable. Clients are not.
Questions
Questions technical buyers ask
Do you build this on our own hardware or in a cloud account?
Whichever the constraints point at, and the constraints are usually cost, latency and where the data is legally allowed to live. Self-hosted on Proxmox is the right answer more often than people expect once GPU or storage-heavy workloads are involved. A cloud account is the right answer when the workload is spiky or the team has nobody to look after hardware. Both get built the same way, as code, so the decision is reversible.
What actually gets handed over at the end?
The repositories, the runbooks, the address and service inventory, the monitoring configuration, and credentials moved into whatever the organization already uses. Nothing here depends on a proprietary tool that only one contractor can operate. If the arrangement ends, the next engineer inherits a documented system rather than an archaeology project.
What does a first engagement usually look like?
An infrastructure assessment: what is running, on what, who can reach it, how it is backed up, whether the backups have ever been restored, and what happens when the one machine nobody has touched in two years stops. The deliverable is an inventory, a topology and a ranked risk list, which is usually enough for the organization to decide what to fix first with or without further help.
Start a technical conversation
Describe the system, the constraint and the deadline. An engineer answers.
Tools and platforms we work with: Proxmox VE and LXC. Docker and Traefik v3. Docker Compose, NGINX, CapRover and Coolify. Debian, Ubuntu. GitHub Actions with self-hosted runners. NetXMS, Prometheus node_exporter, NUT. PostgreSQL and self-hosted Supabase. AWS IoT Core, RDS, Timestream, SQS, SNS and API Gateway.