for AI agencies and product studios
One address per client, one panel for all of them.
Run each client's agent in its own container, at its own domain, with its own keys and its own memory — and stop rebuilding the same stack for every pitch.
The demo problem
An AI agency does not have one agent. It has a demo for the retail prospect, a staging agent for the bank that is still in security review, and a production guest for the client who signed in March. Put them all on one shared box with hand-rolled Docker commands and they start sharing things they should not: a port, an env file, a key, and eventually a fate.
AgentHotel makes the separation the default rather than the discipline. Every guest is its own container with its own RAM and CPU cap, its own subdomain with automatic HTTPS, and its own volumes. One client's agent cannot starve another's, and redeploying one does not touch the others.
What is left is the part you actually sell: the harness, the tools it reaches, and the workflow you designed for the client.
one host, many doors
A guest list, not a shared demo server
Each room is a container, capped at its own RAM and CPU, behind its own hostname. TLS is issued per subdomain, so the URL you send a client is the URL they will still have next quarter.
When the engagement ends, you do not unpick a monolith. You delete one guest, or move it into the client's own hotel with a one-time transfer link.
What an agency actually needs
Isolation with a one-line boundary
Every agent is its own container with its own CPU and RAM cap, its own volumes and its own domain. No guest starves the others — or the hotel.
Templates as recipes
A template can be an image, a compose file or a repository, built from its Dockerfile or run with its compose file. Deploying one fills in the form a person would otherwise fill in.
Declared secrets, generated per deployment
A template says what is secret and how to make it — hex, password, or a JWT signed with another generated secret. No template ever carries a credential, and two deployments never share one.
Identity per agent
A shared data store derives who is writing from the key in the header, so each agent gets its own. Sharing one key would make the store unable to tell whose work is whose.
Export, import, hand over
One-click instance backup and VPS-to-VPS migration, plus per-service export and import as a zip — optionally with the agent's persistent volume, for a consistent copy.
Move to another hotel
An agent's memory is its harness's own files, and they go with it. The old hotel issues a one-time link, the new one fetches it server to server, memory included.
Where a guest's code comes from — repository, ref, compose file, which service the domain points at — is edited on its own panel, with the commit it is running.
AgentHotel README · on where a guest's code comes from
Questions that come up in a pitch
Can two clients share one installation?
Yes — that is the point. They share the panel and the host, not a container, a domain, a key or a volume. Each guest is capped at its own RAM and CPU, and the panel warns you before you overbook the host.
What does a client actually receive at handover?
Their own hotel, or a guest imported into theirs — with its memory, its workspace files and its configuration. Admin credentials are never part of an export.
How do we script the repetitive part?
The panel exposes an MCP server and a REST API that can do everything the UI does: list, create, redeploy and delete agents, check system status and pull logs.
How do we keep a client's model choice private?
Providers are configured once and injected per agent. Point one agent at a frontier API and another at the client's own vLLM or llama.cpp server; each agent picks its own provider and model.
Is this a SaaS we are reselling?
No. It is a self-hosted panel under the MIT licence, running on a VPS you choose. There is no account to create and no rent to pay.
Your next three builds could share one box without sharing anything else.
Hand the hotel a client, get a guest with an address, a certificate, a key and a memory that survives the next deploy.