--- title: "AgentHotel for AI agencies — one address per client" description: "Run every client's agent in its own container, at its own domain, with its own keys and memory. Templates make each build repeatable, export makes it handover-ready." theme: editorial footer: "AgentHotel · a hotel for agents · source at github.com/magnusfroste/agenthotel" --- ::nav{brand="Front desk"} - Runtimes and templates → https://github.com/magnusfroste/agenthotel#runtimes - The manual → https://github.com/magnusfroste/agenthotel/blob/main/docs/MANUAL.md - Repository → https://github.com/magnusfroste/agenthotel :: ::hero{eyebrow="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. [Read how it maps to an agency](#problem){.primary} [The repository](https://github.com/magnusfroste/agenthotel){.ghost} :: ::text ## 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. :: ::split{eyebrow="one host, many doors" image="https://images.unsplash.com/photo-1481277542470-605612bd2d61?w=1200&q=80" imageAlt="A hotel corridor with numbered 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. :: ::features{title="What an agency actually needs" columns="2"} - icon: ◇ title: Isolation with a one-line boundary body: 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. - icon: ✳ title: Templates as recipes body: 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. - icon: ▤ title: Declared secrets, generated per deployment body: 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. - icon: ◉ title: Identity per agent body: 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. - icon: ⌘ title: Export, import, hand over body: 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. - icon: ▸ title: Move to another hotel body: 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. :: ::quote{by="AgentHotel README" role="on where a guest's code comes from"} 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. :: ::faq{title="Questions that come up in a pitch"} - q: Can two clients share one installation? a: 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. - q: What does a client actually receive at handover? a: 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. - q: How do we script the repetitive part? a: 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. - q: How do we keep a client's model choice private? a: 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. - q: Is this a SaaS we are reselling? a: 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. :: ::cta ## 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. [Read the repository](https://github.com/magnusfroste/agenthotel){.primary} [The manual](https://github.com/magnusfroste/agenthotel/blob/main/docs/MANUAL.md){.ghost} :: ::footer{note="AgentHotel is MIT licensed. The metaphor is not decoration — it is how the panel is built."} - Source → https://github.com/magnusfroste/agenthotel - Runtimes and templates → https://github.com/magnusfroste/agenthotel#runtimes ::