Private Cloud Infrastructure: our own services, run like production
A virtualized server environment that hosts 15+ services across web apps, automation, monitoring and home systems. Every service follows the same deployment standard, sits behind layered security, is covered by three tiers of backup, and is documented in runbooks we actually use. Built and operated by Agentas.
- Status
- In daily production use
- Scope
- 15+ services, each in its own container
- Stack
- Proxmox, Docker, ZFS, GitHub Actions
- Source
- Private — walkthrough on request
What it does
One way to put a service into production
A written playbook takes a new service from an empty container to production: a dedicated container, a standard folder layout and port range, firewall and access rules, and uptime monitoring from the day it goes live. A service is not done until it passes the security conformance check.
Push to deploy, one key per repository
Deploys run from GitHub Actions over a private network, and each repository has its own deploy key. Under the deployment standard, that key can only start one pinned script on the server, which pulls, builds and restarts the service and fails loudly on a stale deploy.
Security in layers
Nothing is port-forwarded from the internet: public sites come in through an outbound tunnel and a reverse proxy with TLS. Admin access runs over a private network with access rules, every container has its own default-deny firewall, and SSH accepts keys only.
Three tiers of backup
Hourly ZFS snapshots of the data volumes, nightly backups of the containers, and a daily encrypted copy offsite, each with its own retention policy. Offsite capacity has a runbook of its own, from reading the warning signs to cleaning up safely.
Recovery we have actually done
A restore playbook says which backup to use for which kind of loss, with step-by-step runbooks. It has been used for a real recovery: 24,655 files, 1.9 GB, checked byte for byte against the original.
Monitoring from one list
One list of sites feeds both the service dashboard and the uptime monitors, so a new service is watched from the moment it goes live. Metrics dashboards track the hosts, pending updates are collected from every container, and alerts go straight to a phone.
Relevant if you're looking for…
We built and run this environment ourselves, and this is how it answers some common needs.
- A private cloud for your business: we run customer systems with the same standard way to deploy, security in layers and documentation that matches what is running.
- Self-hosting services in production: every service gets its own container, the same folder layout and deploy mechanism, uptime monitoring from day one, and a security conformance check before it counts as done.
- Backup and recovery that has been tested: hourly snapshots, nightly copies of the containers and a daily encrypted offsite copy, plus a restore playbook used for a real recovery of 24,655 files, checked byte for byte.
- A dashboard for self-hosted services: one list of sites feeds both the service dashboard and the uptime monitors, so a new service is watched from the moment it goes live, and alerts go straight to a phone.
We build this for clients: Custom software and internal tools · Software for the public sector
How it works
- 01
Define
Every service's configuration lives in git. Secrets never do.
- 02
Deploy
A push starts CI, which deploys over a private network with a key scoped to one repository.
- 03
Verify
A conformance check, then real tests from outside the host, positive and negative.
- 04
Recover
Three backup tiers and a playbook for which one to reach for.
How it's built
The environment runs on a Proxmox virtualization host with ZFS storage. Each service gets its own lightweight container running Docker Compose, with the same folder layout and deploy mechanism everywhere, so every service can be understood, updated or removed the same way. Removal has a playbook too: public routes come down first and storage is destroyed last, so every step before that can still be undone.
Verification is the core discipline. Reading a config file back does not prove what a running system does, so changes are checked with real traffic from outside the host. The same care applies to AI assistants working on the platform: they are part of the threat model, hold no standing root access, and deliver privileged changes as reviewable, dry-run-first scripts that a person runs.
Engineering highlights
- Key-only SSH; every deploy key belongs to exactly one repository
- A conformance script checks every container against the written security standard
- Configuration in git, secrets kept on the host
- An interactive architecture map of 220+ components, with a view of the internet-facing attack surface
- Self-hosted CI runners trialled, measured at about 10× slower, and rolled back the same day
- Incidents written up with root cause and a guard against recurrence
Questions
What is the environment built on?
A Proxmox virtualization host, with each service in its own lightweight container running Docker Compose. Deploys run from GitHub Actions over a private network, with one deploy key per repository.
How is the environment secured?
In layers. Nothing is port-forwarded from the internet, admin access runs over a private network with access rules, every container has its own default-deny firewall, and SSH accepts keys only.
Can the systems you build for us run on-premise, on our own servers?
Yes. We can deploy on your infrastructure or ours, and the same operating discipline applies either way.
Want something like this?
The same operating discipline goes into every system we run for customers: one standard way to deploy, security in layers, backups you have actually restored from, and documentation that matches what is running.
Get in touch