00 / project detail
Infrastructure automation system that consumes messages from a RabbitMQ queue and executes provisioning scripts on a Linux server - creating containers, configuring networking, installing software, and managing SSL certificates entirely through message-driven commands.
01 / the problem
Running a multi-tenant web hosting platform on Linux containers means repeating the same sequence of manual steps every time a new client arrives: clone a template container, configure its network interface, update the proxy routing table, generate an SSL certificate through Let's Encrypt, and then install whatever application stack they need. Do this a dozen times and you've introduced a dozen opportunities for inconsistency.
Each container also lives in isolation from the others, which is exactly what you want for a hosting environment - one tenant can't affect another's file system or processes. But isolation doesn't mean homogeneity is free. Without automation, containers drift: slightly different permissions here, a missing package there, a cert renewed on one host but not another.
The answer is to reduce every provisioning action to a single, atomic operation - one that runs identically every time, whether triggered by a control panel, an API, or a developer's terminal.
Provisioning from scratch takes 20+ minutes
Cloning a template, writing netplan YAML, pushing it to the container, restarting networking, and verifying connectivity - manually, every time.
SSL setup is fiddly and frequently wrong
Certbot's HTTP-01 challenge requires a correctly configured document root and a reachable .well-known/ path before it'll issue a cert. One misconfiguration and the whole thing silently fails.
SFTP access requires coordinating two servers
Granting a client SFTP access means creating a user inside the container, opening an SSH port via the LXC proxy, then SSHing into a separate proxy server to write iptables rules and persist them. Four separate systems touched.
App installs are repetitive and version-sensitive
Installing Laravel isn't one command - it's Composer, symlinking, SQLite, migrations, permissions, and restarting PHP-FPM. Every framework has its own multi-step ritual.
02 / architecture
A central consumer.go process connects to RabbitMQ and listens on the lxc_commands queue. Incoming messages are space-separated command strings, for example:
The consumer parses the verb and routes to the matching compiled Go binary. Each script handles a single concern - from cloning an LXC container template to configuring iptables port-forward rules on a proxy server over SSH.
Domain names are derived algorithmically from container names (mysite-co-uk → mysite.co.uk), so no manual DNS config is needed during provisioning.
03 / live demo
Simulated consumer - try the suggested commands or type your own. Use ↑↓ for history.
04 / tech stack
Language
Go
Consumer and all provisioning scripts compiled to standalone binaries - no runtime deps on the host.
Message Queue
RabbitMQ
AMQP queue decouples command dispatch from execution, allowing fire-and-forget provisioning requests.
Containers
LXC
Linux containers provisioned from a base template with custom netplan networking per container.
SSL / TLS
certbot
HTTP-01 webroot challenge. Domain auto-derived from container name (e.g. site-co-uk → site.co.uk).
Networking
iptables
PREROUTING / FORWARD rules pushed to a proxy server over SSH for per-container SFTP port-forwards.
Web stack
Apache2 + PHP-FPM
Installed on containers on demand - Laravel, WordPress, or CodeIgniter with a single queue message.
hey, I built this AI too!