Every component below is proven and running in production somewhere today. The proposal is not to invent infrastructure. It is to stop selling it as parts, and to run an accountable assistant across the whole thing so the customer never assembles anything.
The pod in OnePod is a pod in the ordinary sense of the word: one or more containers, a persistent volume, and a database, deployed and scaled as a single unit. The brand name is not hiding a different technology. It is naming the unit so the customer has something to call it.
On "you never move". The claim is about the customer, not the infrastructure. Underneath, things move constantly: images are rebuilt, storage is replaced, capacity is rebalanced, regions change, orchestration is upgraded. All of that is the operator's job and is invisible. What the customer never performs is a migration, a plan change, a re-platform, or a cutover. And if they want to leave, the pod exports as ordinary software and data rather than as a proprietary format.
Top to bottom, what a single customer's presence actually consists of.
Assistant agnostic. The customer's existing AI is the control surface, so the platform ships a remote connector rather than a proprietary chat window. A dashboard still exists for people who want one, it is just not the front door.
A remote MCP server with OAuth. Capability scoped tokens with short lifetimes, read only by default, explicit consent for anything that changes state, a full action log, and instant revoke. Infrastructure is a commodity. Accountable agency is not.
As of the July 2026 revision, the protocol itself is stateless: no connection handshake, no session identifier, every request self describing. That matters here for one reason. A pod is files plus a small function that answers tool calls, and that is now the shape the protocol assumes rather than a simplification this design had to argue for. It also means the agent layer runs on ordinary HTTP infrastructure a host already operates, behind a plain load balancer, with no sticky routing or shared session store.
A host owned Git repository per pod, with an optional external mirror for people who already live on GitHub. commit then build then deploy. One primitive replaces four products: file manager, backup, deployment, and audit log, with reversible semantics an assistant can be trusted to operate.
Containers plus a persistent volume plus a managed database, deployed from a head start image. Real runtimes, so existing software runs unmodified, including WordPress, Node, Rails and Postgres. Isolation is per customer, not per directory.
The host's existing global network doing what it already does. DNS is the single coordination layer tying the customer's domain to the pod, and it is the only part of this layer the product has to own. Mail is out of scope at launch: the customer keeps whatever mail they already have and the pod simply leaves those records alone. Rebuilding deliverability is a decade long tar pit, and even reselling someone else's mailbox adds a support surface for no strategic gain. Domain registration is likewise not resold; the customer brings a domain and the pod points at it.
The customer facing promise, your own walls, has to be architecturally true rather than a marketing line. Here is the honest comparison of the four ways this has been attempted.
| Model | Isolation | Runs real apps | Why it is not the answer |
|---|---|---|---|
| Shared hosting | Filesystem only, shared kernel and database server | Yes | Noisy neighbours, a shared blast radius, and a sequence of sizes that forces a migration every time the customer succeeds. |
| VPS | Strong, full virtual machine | Yes | The isolation is fine. The operator is the problem. Someone has to patch, secure, size and watch it, and growing still means resizing or moving. |
| Serverless functions | Very strong | No, restricted runtimes | Cannot run the software small businesses actually use, and state was bolted on late. Excellent for edge logic, wrong as the main substrate. |
| The pod | Per customer namespace, memory, network and storage | Yes, anything containerised | The fit. Separation close to a VM, elasticity close to serverless, no per customer server to administer, and persistent volumes make stateful apps a first class citizen. |
Compromising one tenant's application does not grant reach into another's data, memory or network. In shared hosting that separation is a permissions convention. Here it is an isolation boundary.
Each pod holds its own database and volume rather than a row range in a communal server. Restores, exports and deletion become per customer operations, which also makes data portability and privacy obligations tractable.
Isolated per customer: the application, the data, the storage volume, the database, and the network namespace. Shared, correctly and openly: the control plane, the edge network, DNS, and the physical hosts underneath. Nobody needs their own edge network, and claiming otherwise at small business pricing would not be credible.
Base images are rebuilt and redeployed centrally, so security updates arrive as new deployments instead of thousands of hand patched servers drifting apart. Nothing to forget.
A head start is a maintained image that already contains a working setup. The customer picks the closest one and changes whatever they like. It is a starting point, not a cage, and it is the thing that makes the assistant reliable, because it is assembling from known good ground rather than improvising infrastructure.
Site, shop, booking, membership, or an empty pod with just a runtime and a database for people bringing their own code. Every one of them is a real deployment the customer fully owns from the first minute.
Asking an assistant to invent a stack from nothing is fragile. Asking it to start from a maintained image and make changes is predictable, testable, and reversible. Head starts are what turn platform capability into something an agent can be trusted with.
Images are kept patched and current centrally. The customer's changes sit on top in version history, so updates underneath do not overwrite their work and can be rolled back if something conflicts.
The old sequence of plan sizes made growth a migration event. Here the same deployment gets more instances in more places. Nothing is rebuilt, no address changes, no plan is purchased.
Demand adds instances of the identical image instead of swapping in a bigger machine. There is no maximum plan to hit, so there is no upgrade conversation and no cutover window.
Static assets and cached responses are served from the edge everywhere. Application instances are placed in the regions where requests actually arrive. Writable data stays authoritative in one region with replicas and fast failover elsewhere, because a globally writable database is a genuinely hard problem and the concept should not pretend otherwise at this price point.
Fixed size pricing for customers who want to know the number, measured pricing for customers who want to pay for exactly what runs. Switching between them is a billing setting on the same pod, not a migration, which is what finally lets one platform serve both small businesses and developers.
Handing an assistant the keys to a business's entire online presence is a trust problem before it is an engineering one. The answer is not a liability clause, it is a permission model where the damaging actions are either blocked, confirmed, or reversible.
Because the assistant's write surface is version history, everything it does is atomic, attributed and revertible. Undo what the assistant did is a normal operation, not a support escalation.
Tokens measured in minutes, renewed while the customer is actively working, killable instantly from the account. A leaked token is a small window rather than a standing key to the business.
When the assistant hits its limits, or the customer simply gets nervous, support enters the existing conversation with the full action log in front of them. The escape hatch is what makes people willing to use the automation at all.
For an established host already running containers and a global network, this is an assembly and packaging exercise rather than a research project.
An MCP server covering the full lifecycle: provision, deploy, DNS and account questions, with capability scopes, consent prompts, hard blocks on billing and destruction, and an immutable action log. Everything else in the stack can be bought. This is the differentiator.
A host owned repository per pod with build hooks, wired so a non technical customer never sees the word repository and a technical one can push to it directly.
A small, curated, actively maintained set of working setups rather than a sprawling marketplace. Quality and patch discipline matter far more than quantity here.
Capacity modelling that turns usage based infrastructure into one predictable number, with a clean overflow into consumption pricing for the rare heavy user.
There are things this does not solve yet. They are written down rather than glossed over.
Read the open questions