I Built a WordPress Host Where AI Is the Operator - MojoShine

I Built a WordPress Host Where AI Is the Operator, Not a Feature

February 13, 2026 15 min read Founder Story

I didn't set out to build a better managed WordPress host. I set out to build one that doesn't need managing at all.

That distinction matters. Every hosting company on the market is essentially the same product: servers, a control panel, and a team of humans who keep things running. Some have nicer dashboards. Some have faster support. But the fundamental architecture is identical -- you're paying for people to operate infrastructure on your behalf.

I wanted to know what happens when you remove the people entirely. Not the customer-facing support (that matters), but the operational layer -- the provisioning, the configuration, the monitoring, the incident response. What if all of that was handled by an autonomous system that could execute a 20-step provisioning workflow with zero errors at 3am on a Sunday?

The result is MojoShine. And as far as I can tell, nothing else works this way.

What "autonomous" means here: A customer signs up, pays, and three minutes later has a fully configured WordPress site with SSL, security hardening, isolated infrastructure, and monitoring. No human touched anything. No ops team reviewed a ticket. No engineer ran a script. An AI agent handled the entire pipeline from payment to live site.

Why This Category Needed to Exist

I kept running into the same frustration with managed WordPress hosting. Providers charge $30-50/month and then add extra fees for SSL certificates (which are free), staging environments, basic security plugins, and CDN access. The actual cost of running a WordPress container on decent hardware is a few dollars a month. The rest is margin on manual labor -- the ops team that provisions your server, the support staff that resets your password, the engineer who debugs your nginx config at 2am.

That labor is the entire cost structure. And it's the reason managed hosting is expensive, slow to provision, and inconsistent in quality. Human operators make mistakes. They have capacity limits. They take vacations. They cost $80k-150k/year each.

What if that labor layer just... didn't exist? Not because you replaced it with worse service, but because you replaced it with something that could execute complex operational workflows with zero errors, 24 hours a day, at marginal cost approaching zero?

I'd been building tool-calling agent systems and had a realization: Claude isn't just good at answering questions about infrastructure. It's good at doing infrastructure -- if you give it the right tools and constraints. That's not "AI-powered hosting." That's a fundamentally different operational model. That's autonomous hosting.

The Architecture of Zero-Intervention Operations

The core of MojoShine is a control plane that sits between the customer and the infrastructure. When someone signs up and pays through Stripe, a webhook fires, a background task is queued, and an AI agent takes over.

The agent operates through a tool-calling loop. I built a registry of 67 tools spanning Docker container management, MySQL provisioning, nginx configuration, SSL certificates, DNS records, Cloudflare integration, encrypted secrets management, and email notifications. The agent gets a structured task ("provision a site for this customer on this plan") and a set of rules about what to do and in what order.

It then calls tools one at a time, inspects the results, decides what to do next, and continues until the site is live or something goes wrong. There's a hard ceiling of 30 iterations -- more than enough for provisioning, tight enough to prevent runaway loops.

Why this isn't a bash script: The agent adapts. If a tool returns an unexpected result, it doesn't blindly proceed. It evaluates the error, decides whether it's recoverable, and either retries with different parameters or triggers a full rollback. A bash script follows a fixed path. The agent navigates a decision tree in real time.

The rollback itself is a 9-step teardown -- stop the container, remove the volume, delete the network, drop the database and user, remove the nginx config, clean up DNS records, remove encrypted secrets, and update the customer status. The agent executes this autonomously if any step in the provisioning chain fails irrecoverably.

The Full Provisioning Workflow

The entire provisioning workflow hits about 20 distinct steps. Here's what actually happens when a customer pays:

  1. Create the customer record in PostgreSQL
  2. Select a target server using resource-aware scheduling
  3. Generate encrypted credentials (database password, WordPress admin password)
  4. Create an isolated Docker network for the site
  5. Spin up a MariaDB database with subnet-restricted access
  6. Create and mount a dedicated storage volume
  7. Launch a WordPress container with hardened Linux capabilities
  8. Wait for container health (WordPress needs ~15s before WP-CLI works)
  9. Install and configure WordPress via WP-CLI
  10. Install security plugins (Wordfence)
  11. Configure email delivery (WP Mail SMTP + Postmark)
  12. Configure nginx as a reverse proxy
  13. Provision SSL via Cloudflare
  14. Set up DNS records
  15. Verify the site is accessible and healthy
  16. Send a welcome email with credentials
~3 min Average provision time
67 Tools in the registry
20+ Provisioning steps
0 Humans in the loop

Average time: about three minutes. The SLA is five. Every step is logged, every tool call is recorded, and the entire operation is auditable after the fact.

The Stack

I'm going to be specific here because vague architecture descriptions are useless. If you're building something similar, the details matter.

Control plane: FastAPI running on Uvicorn, backed by PostgreSQL for state management. Celery with Redis as the task broker for background jobs (provisioning, patching, deletion). The API handles billing webhooks, the customer portal, and the admin dashboard.

WordPress infrastructure: Each customer gets their own Docker container running WordPress + MariaDB. Per-customer network isolation -- every site gets its own Docker network with inter-container communication disabled, so one compromised site can't reach another. Nginx as the reverse proxy with TLS 1.3 only. Cloudflare in front for CDN, DDoS protection, and DNS management.

Billing: Stripe handles subscriptions, trials, and payment processing. Webhooks drive the entire lifecycle -- subscription created triggers provisioning, subscription cancelled triggers teardown.

Email: Postmark for transactional email (welcome emails, password resets, billing notifications). WP Mail SMTP plugin installed on every container so WordPress can send email through Postmark rather than relying on local sendmail (which doesn't exist in the containers).

Why Hetzner Over AWS

I chose Hetzner dedicated servers over AWS for a straightforward reason: cost. A server that costs $50/month on Hetzner would run $400+ on EC2 for equivalent specs. When your margins depend on running containers efficiently, that 8x cost difference is the difference between a viable business and a money pit.

The three servers form a high-availability cluster with Cloudflare load balancing. PostgreSQL streams replication to a standby. Redis uses Sentinel for automatic failover. The API runs on all three servers behind the load balancer.

Resource-Aware Server Selection

When the agent provisions a new site, it doesn't just pick a random server. It queries Prometheus for real-time CPU, memory, and disk usage across all three servers, calculates a composite score, and places the container where it'll have the most headroom. Fill-first strategy, 100 sites max per server.

Per-Customer Network Isolation

Each WordPress site runs in its own Docker network. Inter-container communication is disabled. MariaDB is restricted to the site's subnet. If one site is compromised, the attacker has no network path to any other customer's data.

Encrypted Secrets Management

Database passwords and WordPress admin credentials are encrypted at rest. The agent generates unique credentials per customer, encrypts them, and only decrypts them at the moment they're needed during provisioning.

The Moment It Became Real

I remember the first time the system provisioned a site end-to-end without me watching. I'd been testing individual tools for weeks -- the Docker wrapper, the MySQL provisioner, the nginx template generator -- but always with me as the human reviewing each step.

Then I wired up the Stripe webhook, pointed a test card at the checkout, and walked away to make coffee. When I came back, there was a welcome email in my inbox with credentials for a live WordPress site. SSL working. Wordfence installed. Email delivery configured. The agent had made 24 tool calls, encountered zero errors, and completed in under three minutes.

That was the moment I knew this wasn't a demo. It was a product. And more importantly, it was proof of a category: hosting where the AI isn't an add-on chatbot answering questions about your bill. The AI is the operator.

Self-Healing: The Other Half of Autonomous

Provisioning is the flashy part. But autonomous hosting means the system also has to keep itself running without human intervention. That's where the self-healing agents come in.

Five operational agents run on scheduled timers across all three servers:

Container Doctor (every 10 minutes)

Checks every WordPress container for health status. Restarts unhealthy containers with throttling (max 2 restarts per hour per container). Detects nginx IP drift when containers get new addresses. Finds orphaned resources.

Service Doctor (every 10 minutes)

Monitors Celery workers, Redis, the API, and MySQL. Detects stuck background tasks and stale distributed locks. Restarts services that have stopped responding.

Provisioning Doctor (every 15 minutes)

Catches provisioning tasks that got stuck (pending for more than 10 minutes). Can auto-retry failed provisioning. Verifies that provisioned sites are actually accessible and healthy.

State Reconciler (every hour)

Audits consistency across four systems: Stripe subscriptions, PostgreSQL records, Docker containers, and nginx configs. If a customer has an active subscription but no container, that's a problem. The reconciler finds it.

Resource Guardian (every hour)

Manages disk space, memory pressure, and Docker cleanup. Rotates logs. Removes dangling images and unused volumes. Prevents the servers from slowly filling up.

All five agents together are about 2,200 lines of Python. They run with distributed locking so only one instance executes across the three-server cluster at a time -- you don't want three copies of the Container Doctor restarting the same container simultaneously.

An important distinction: The self-healing agents are not AI-powered. They're straightforward operational scripts with safety rails (restart throttling, never delete customer data, always validate before nginx reload). The AI handles the complex, creative work of provisioning -- interpreting errors, deciding on retry strategies, executing rollbacks. The self-healing handles the repetitive, predictable work of keeping things running. Right tool for the right job.

Things That Were Harder Than Expected

Building this took about as long as you'd expect a solo founder to build a production hosting platform. Some things worked on the first try. A lot of things didn't. Here's what cost me the most time:

SSH Escaping

The agent executes commands on remote servers via SSH. The escaping nightmares when you're constructing shell commands programmatically and passing them through multiple layers of quoting are real. A command that works perfectly when you type it in a terminal will silently do the wrong thing when it's been through three layers of string interpolation.

Docker DNS Across Hosts

Nginx can't resolve Docker container names when the containers are on a different host. This seems obvious in retrospect but cost me two days. The solution is to bind containers to specific IPs and use those in nginx configs, which means the Container Doctor needs to detect when a container restarts with a new IP and update nginx accordingly.

Container Startup Timing

WordPress needs about 15 seconds after container start before WP-CLI will work. The agent has to wait for the container health check to pass before attempting any WordPress configuration. Too eager and you get cryptic errors. Too conservative and provisioning takes too long.

TLS Session Tickets

Running TLS termination across three servers behind a load balancer means session tickets need to be synchronized, or users get random SSL errors when their requests hit a different server than the one that initiated the session. This is the kind of thing that works perfectly in testing (single server) and breaks immediately in production (multi-server).

Distributed Locking

Five self-healing agents, three servers, scheduled timers that can overlap -- you need distributed locks or you get race conditions. I built this on Redis with Sentinel failover. Getting the lock expiry timing right so that a crashed agent doesn't hold a lock forever, but a slow agent doesn't lose its lock mid-operation, took more iteration than I'd like to admit.

The honest version: About 40% of the development time was spent on the agent and provisioning system. The other 60% was spent on the boring operational details -- DNS propagation, certificate renewal, log rotation, backup scheduling, health check endpoints, Prometheus metrics, and the hundred other things that have to work correctly for a hosting platform to be trustworthy.

What "Autonomous" Doesn't Mean

I want to be precise about what I'm claiming, because the AI hype cycle has made it hard to talk about this stuff without people assuming you're exaggerating.

Autonomous hosting does not mean:

What autonomous hosting does mean: the operational pipeline from payment to live site to ongoing maintenance runs without human intervention. That's a specific, testable claim. And it's what makes it possible to offer hosting at $9/month that would cost $30-50/month if humans were doing the work.

Where It Is Now

MojoShine is live. Real customers can sign up, start a 30-day free trial, and have a WordPress site running in about three minutes. Pricing starts at $9/month on an annual plan -- about 40% less than WP Engine or Kinsta for comparable features, because the cost structure is fundamentally different when your operations run autonomously.

$9/mo Starting price (annual)
30 days Free trial
3 HA servers
5 Self-healing agents

The platform includes things that other hosts charge extra for: SSL certificates, CDN via Cloudflare, security hardening with Wordfence, email delivery via Postmark, container isolation, automated backups, and a customer portal where you can manage your sites, domains, and subscriptions without submitting a support ticket.

If you want to understand the technical details of how autonomous WordPress hosting works under the hood, I wrote a separate deep-dive on the architecture. And if you're curious about what distinguishes this approach from traditional managed hosting at a conceptual level, there's a breakdown of what autonomous hosting actually means as a category.

What I'd Tell Another Solo Founder

If you're considering building something with AI agents as the operational core rather than a bolted-on feature, here's what I learned:

Tool design matters more than prompt engineering. The quality of the agent's output is directly proportional to the quality of the tools you give it. A well-designed tool that returns clear, structured results makes the agent's job easy. A sloppy tool that returns ambiguous output forces the agent to guess, and guessing at 3am with a customer's site on the line is not what you want.

Constrain before you trust. The 30-iteration ceiling, the explicit tool registry, the structured task definitions -- these constraints are what make the system reliable. An unconstrained agent is a demo. A constrained agent is a product.

Rollback is not optional. If your agent can create something, it must be able to undo that creation completely. The 9-step rollback wasn't fun to build, but it's the reason I can sleep at night. A failed provisioning that leaves orphaned resources across Docker, MySQL, nginx, and DNS is worse than a provisioning that never started.

The boring stuff is most of the work. The agent provisioning system is maybe 20% of the codebase. The rest is billing integration, customer portal, admin dashboard, health monitoring, backup systems, self-healing agents, deployment automation, security hardening, and documentation. The AI part is the most interesting 20%. The other 80% is what makes it a business.

Start with the hardest workflow. I built provisioning first because it's the most complex and the most valuable. If the agent can handle 20 interdependent steps with rollback on failure, everything else (patching, deletion, domain management) is simpler by comparison. Prove the hard thing works, then expand.

See Autonomous Hosting in Action

Start a 30-day free trial. Your site will be live in about three minutes -- no humans involved.

Start Free Trial

The Category Bet

The hosting industry has been doing the same thing for 20 years: rent servers, hire ops teams, build control panels, charge a markup on labor. AI chatbots and "AI-powered" marketing pages are getting bolted onto this same model, and it changes nothing fundamental about the economics or the architecture.

Autonomous hosting is a different bet. It says: the operational layer itself can be automated by AI agents, not just assisted by them. The agent doesn't help a human provision a site -- the agent is the operator. That changes the cost structure, the consistency, the speed, and the scalability of the entire business.

I don't know if MojoShine will be the one that defines this category. But I'm confident the category exists, because the economics are too compelling to ignore. A hosting platform that runs itself at near-zero operational cost will always be able to offer better pricing, faster provisioning, and more consistent operations than one that depends on human labor for every step.

The question isn't whether autonomous hosting will happen. It's whether it's happening now. I think it is. And I built the system to prove it.

MojoShine Founder

Solo founder building the first autonomous WordPress hosting platform. Formerly spent too much time configuring nginx by hand.