A self-serve SaaS for running WordPress on your own cloud. A customer connects a cloud account; the panel creates the server, installs a tuned LEMP stack and a management agent, and from then on runs the site, SSL, PHP, database, cache, backups, files, SSH and WordPress itself from the browser — with Stripe billing on top.
I built it alone over two years and three generations — from a central API for Google Cloud servers in 2023 to a platform that provisions on five clouds — plus a single-server edition sold as a licensed Google Cloud Marketplace image.
Convenient, but the server, the network and the bill belong to someone else.
nginx, PHP pools, databases, certificates, backups and updates all have to be learned, configured and kept running.
The customer keeps the cloud account and the bill. The panel does the operations — provisioning, tuning, certificates, backups, updates and troubleshooting — all from a browser.
Creates an Ubuntu server on five clouds, with regions, sizes and plans fetched live from each provider.
nginx with HTTP/2 and HTTP/3, security and tuning; PHP 8.1 to 8.4 with FPM pool tuning, logs and metrics.
MariaDB databases, users and grants with phpMyAdmin single sign-on; Redis configuration.
Let’s Encrypt over HTTP or DNS through five DNS providers, uploaded certificates, or the panel’s own authority.
Encrypted, deduplicated snapshots to eight storage providers, on schedules from hourly to monthly, with restore.
Install, updates, themes, plugins, cron, maintenance mode, magic login, database tools and migration from other hosts.
A file manager with an in-browser code editor, SSH keys, systemd services, processes and live stats.
About thirty health checks, each with a one-click fix — including configuration drift.
Stripe subscriptions with plan-based site limits, invoices, tax IDs and the billing portal.
The first design modelled servers, domains and sites separately, like a traditional panel. Halfway through, I collapsed them: a site is a server. It removed a layer of indirection from every screen and command, made isolation physical rather than configured, and let one model own the whole stack.
nginx, PHP pools, MariaDB, Redis, logrotate, phpMyAdmin, backup remotes and the install scripts are all rendered per site. The same templates make drift detection possible — and every fix is just a re-render.
The panel never opens a shell on a customer’s server. Each server runs a small agent I wrote in Python — Flask on gunicorn, run by systemd — and the panel talks to it over HTTPS once DNS and the certificate verify. In production, the agent’s port answers only the panel’s address, enforced by the cloud firewall on all five providers.
Every request carries a token that expires within the hour. The agent verifies its signature against the signing key’s published certificates, then checks that its audience is a hash of the server’s own public address — so a token issued for one machine is refused by every other.
File-manager and SSH-key operations switch to the site’s own Linux user before touching the disk, so the agent’s root access is never used on a customer’s files.
Eight modules — processes, Linux users, SSH keys, file manager, file system, MariaDB, stats and systemd — and nothing else. Run by systemd, restarted automatically.
The Python modules are compiled with Cython into native extensions and installed as an operating-system package from a signed repository.
With first-boot data in the format each provider expects.
It checks it is root, exits early if a previous install finished, and fetches the second stage from a signed URL that expires in five minutes.
nginx, MariaDB, Redis, PHP 8.1–8.4, backup and WordPress tooling and the agent, from a signed package repository — with swap on small machines and only the needed ports opened.
A systemd timer re-runs the installer until the agent is present, and does nothing after that.
A scheduled job polls until the agent answers, then turns the deployment into a live site — or gives up cleanly after two hours.
Every step checks before it acts, so running any part twice is harmless.
182 request classes validate every input — domains, directory names, plugin slugs, database identifiers — before anything reaches a server.
28 middleware say when an action is allowed: site online, WordPress installed, certificate type, plan limit. Each has a page guard and an API guard, so the UI never offers what the API would refuse.
Model observers turn edits into server changes. A new hostname reissues the certificate and rewrites nginx; a new alias re-renders exactly the files it affects and restarts only what changed.
Every configuration file is a template, so the panel can compare what is on a server with what it would write — and fix the difference.
Cloud and DNS keys are encrypted at rest and never serialised; a credential cannot be deleted while a site depends on it.
Commands, files, wp-cli and backups run as the site’s own Linux user; the default PHP pool disables process and socket functions.
Commands built from user input — installing a plugin, generating a login link, checking DNS — are passed as argument lists.
Server-side database administration is built and escaped by the framework’s query builder, with system databases protected.
For the installer, email verification, administrator access and phpMyAdmin single sign-on (encrypt-then-MAC, five-minute expiry).
Issues 4096-bit certificates covering every domain and alias, with serial numbers generated to the standard’s rules.
Encrypted, deduplicated restic snapshots shipped through rclone to AWS, Cloudflare, DigitalOcean, Linode, Wasabi, Vultr, Alibaba or Google Cloud Storage. Twelve cadences fan out creation, archiving and pruning, and unique job keys stop two snapshots of one site from overlapping.
Everything through wp-cli as the site user: install, core, themes and plugins with auto-update, options, cache, cron run by the panel on schedule, maintenance mode, salts, magic login links and a full set of database tools.
Every change broadcasts over private, ownership-checked channels, so pages update as servers come online. nginx and PHP-FPM metrics are collected hourly, and files open in an in-browser Monaco editor.
A single-server edition for Google Cloud Marketplace: two more applications — a small central licensing and installer service, and a panel that runs on the customer’s own VM. Launch the image, and it installs, licenses and configures itself with no one in the loop.
First boot receives a signed installer link valid for five minutes. The VM posts its licence codes from the cloud’s metadata server, and every one must belong to a published image — images, regions and zones synced from the Compute Engine API, not typed in.
It adds the signed package repository, installs and verifies each package, prepares nginx, enables services, and adds swap on small machines only if none exists.
Root and a valid licence required; a password checked against known breaches; the hostname’s DNS must point at the VM before a certificate is requested; the panel is then served by Caddy over TLS.
Each site runs under its own Linux user and PHP-FPM pool with open_basedir and disabled process functions; wp-cli and composer run as that user, and passwords reach wp-cli and MySQL over standard input.
It started as a command-line tool — sites, databases, users, certificates and WordPress, each a short shell command — then the logic moved into reusable libraries and the machine learned to read its own cloud metadata.
A JSON API and a Vue interface replaced the commands over the same libraries: 23 pages, 111 routes and 50 validated request types, with one setup command left for the admin account, hostname and certificate.
A central Laravel API managing WordPress servers launched from Google Cloud images, talking to an agent on each server over HTTP.
A server onboarding pipeline — instance metadata, hostname DNS, hostname SSL, web server preparation and agent handshake — plus an admin for images, regions and zones synced from the Compute Engine API; the interface moved to its own TypeScript app.
A second edition branched off: a single-server panel sold as a licensed Google Cloud Marketplace image — first as a 95-command CLI, then as a web panel.
The Marketplace edition ↑A fresh Laravel 11 codebase — servers, sites, domains and certificates.
First large build; teams removed within the month to keep the model simple.
Unified encrypted credentials, WordPress toolkit, Stripe billing, policies, nginx and PHP metrics.
Servers, domains and sites collapsed into one site-per-server model, and the agent rebuilt around it — the largest rewrite of the project.
Self-installing servers, certificate provisioners, restic backups and scheduled cadences.
From “bring your own server” to “create one in your cloud”, on five providers; phpMyAdmin single sign-on.
Cloud-init installer, site migration, support — and the v1 release.
Each generation kept what worked — the agent, the templates, the WordPress toolkit — and made the model simpler: a fresh codebase in 2024, teams dropped early, then servers, domains and sites collapsed into one. Every simplification made later features cheaper to build.
Isolation becomes physical, and one model owns the whole stack.
No shell on customer servers; access is scoped, signed and short-lived.
A token only works on the machine it was issued for, verified on that machine.
A copied install command stops working almost immediately.
Re-running provisioning is always safe.
A command only reaches a server when it can succeed.
The same source renders, audits and repairs a server.
A compromised site cannot reach the rest of the machine.
Backend and UI can never disagree on a value.
A simpler model made every later feature cheaper to build.
It is how the marketplace marks paid VM images, and it needs no customer credentials.
Nothing sensitive in process lists or shell history.
A server created in the customer’s own cloud on five providers, installing and connecting itself.
nginx, PHP, MariaDB, Redis, services, files and SSH managed entirely from the browser.
Scheduled encrypted backups to eight providers, and self-healing checks with one-click fixes.
Stripe subscriptions with plan-based limits, and a licensed Marketplace edition for single servers.
Everything, alone, across both editions: the product itself, the data model, the provisioning flow for five clouds, the install scripts and server configuration templates, the on-server agent and its protocol, the Marketplace licensing service and single-server panel, the security model, billing, and every page. I designed, built and coded it, front to back.
Described generically — product, company and infrastructure identifiers are deliberately omitted.
Shipped to production. Licences verify offline, so a vendor outage never stops a paying customer, and support moved from engineering to audited operator actions.
Read the case study →Infrastructure · Go · Remote executionBuilt in 2026 for an internal product: zero inbound ports on any machine. Commands run in order per machine and in parallel across the fleet, and every command gets an answer.
Read the case study →Next