There's a moment that happens to everyone who works with coding agents long enough. The agent writes the app, writes the tests, fixes the bug you didn't notice — and then it stops and politely hands you a list of commands to deploy it. The most capable collaborator I've ever had suddenly turns into an intern who isn't allowed near production. And I keep wondering: why is the last mile still mine?

I don't think the answer is "because agents can't be trusted." I think it's because our infrastructure was designed for humans clicking through dashboards. Hosting platforms assume a person is on the other end — someone who reads the docs, squints at a web console, and remembers which button not to press. So when an agent shows up, we give it either nothing or everything: no access, or root.

agentic-hosting is an attempt at a third option. It's a self-hosted PaaS for your own bare-metal box where the primary user is an AI agent and the primary interface is a REST API. There is a dashboard, but it's supervisory — it's for you to look over the agent's shoulder, not to do the work.

I want to walk through how it works, how to set it up, and what I think it means.

The idea: give agents a small, safe set of verbs

The design principles in the README read less like a feature list and more like a philosophy of delegation:

  1. Agentic-first. Agents hit the API directly.
  2. One happy path per primitive. One build system (Nixpacks), one router (Traefik), one engine per database type (Postgres, Redis).
  3. Multi-tenant. Every agent or team gets its own API key and namespaced resources, with per-tenant rate limits.
  4. Secure by default. Every tenant container runs under gVisor, with a read-only root filesystem, all Linux capabilities dropped, and no-new-privileges. Secrets are encrypted with AES-256-GCM.

That second principle is the one I find most interesting. With humans, choice is a feature. With agents, choice is surface area for mistakes. If there's exactly one way to build, route, and provision a database, an agent can't get creative in ways you'll regret at 2 a.m. You're not building a platform for agents; you're building a grammar for them.

Under the hood it's refreshingly boring: a single Go binary called ah (the control plane, running as a systemd service on 127.0.0.1:8080), Traefik in front on 80/443, gVisor as the container runtime, Nixpacks for source-to-image builds, and two SQLite databases in WAL mode for state and metering.

Setting it up

You'll need a Linux server (Ubuntu 22.04+ recommended). The README has the full script; here's the shape of it.

1. Install the pieces. Docker, gVisor's runsc, Go 1.25, and Nixpacks. Then register gVisor as a Docker runtime:

cat > /etc/docker/daemon.json <<'JSON' { "runtimes": { "runsc": { "path": "/usr/bin/runsc" } }, "default-address-pools": [{"base":"172.20.0.0/14","size":24}] } JSON systemctl restart docker

2. Start the infrastructure. Create the traefik-public network, run Traefik with the Docker provider, and run a local registry bound to loopback:

docker network create --driver bridge traefik-public docker run -d --name paas-registry --restart unless-stopped \ -p 127.0.0.1:5000:5000 \ -v /var/lib/ah/registry:/var/lib/registry \ registry:2

(The Traefik docker run command is in the README — copy it verbatim.)

3. Build ah and create its secrets.

git clone https://github.com/dennisonbertram/agentic-hosting /agentic-hosting cd /agentic-hosting CGO_ENABLED=1 go build -o bin/ah ./cmd/ah cp bin/ah /usr/local/bin/ah mkdir -p /var/lib/ah/builds /var/lib/ah/backups head -c 32 /dev/urandom | xxd -p -c 64 > /var/lib/ah/master.key chmod 600 /var/lib/ah/master.key openssl rand -hex 32 # this is your bootstrap token

4. Run it as a service. Put the token in /etc/default/ah as AH_BOOTSTRAP_TOKEN=..., install deploy/ah.service, and start it:

systemctl daemon-reload && systemctl enable --now ah curl -H 'X-Forwarded-Proto: https' http://127.0.0.1:8080/v1/system/health # → {"status":"ok"}

If you just want to kick the tires locally, there's a dev mode: ./bin/ah --dev --open-registration --port 8080.

Handing the keys to an agent

Here's where it gets fun. First you register a tenant — think of it as giving one agent its own apartment in the building:

curl -X POST http://localhost:8080/v1/tenants/register \ -H 'Content-Type: application/json' \ -H 'X-Bootstrap-Token: <bootstrap-token>' \ -d '{"name": "my-agent", "email": "me@example.com"}' # → {"tenant_id": "ten_...", "api_key": "keyid.secret"}

That API key is everything the agent needs. From here on, it's just Authorization: Bearer <api_key>.

Deploy from a git repo. Create a service, then kick off a Nixpacks build:

POST /v1/services { "name": "my-app", "image": "127.0.0.1:5000/tenant/my-app:latest", "port": 3000 } POST /v1/services/{serviceID}/builds { "source_type": "git", "source_url": "https://github.com/org/repo", "source_ref": "main" }

Builds work from GitHub, GitLab, Bitbucket, sr.ht, and Codeberg over HTTPS, and the agent can stream logs from /builds/{buildID}/logs?follow=true — which matters, because an agent that can read its own build failure can fix it.

Give it a database.

POST /v1/databases { "name": "my-db", "type": "postgres" } # or "redis" GET /v1/databases/{dbID}/connection-string

Then wire it in with POST /v1/services/{serviceID}/env. Env vars are encrypted at rest and masked on read unless you explicitly ask for ?reveal=true.

Services end up at http://<service-name>.<tenant-subdomain>.<domain>, routed by Traefik via Docker labels that ah sets for you.

Even easier: let Claude Code drive

The repo ships a Claude Code skill and slash commands, so you don't have to write any of the curl above:

mkdir -p ~/.claude/skills/agentic-hosting cp .claude/skills/agentic-hosting/SKILL.md ~/.claude/skills/agentic-hosting/SKILL.md cp -r .claude/commands/ /your/project/.claude/commands/

Now, inside Claude Code:

/deploy https://github.com/org/my-app web 3000 /db web postgres /logs web /status

The first time I watched this loop — agent writes code, agent deploys it, agent reads the logs, agent fixes the crash, agent redeploys — it felt less like using a tool and more like managing someone. (If you'd rather not use Claude, the same flows exist as plain bash scripts in scripts/.)

The guardrails are the product

What makes me comfortable letting an agent do this isn't the agent. It's the boring stuff around it:

  • A reconciler every 60 seconds syncs the database's view of the world with what Docker is actually doing.
  • A circuit breaker stops restarting a service after 5 crashes in 10 minutes, so a confused agent can't thrash your box. Resetting it is an explicit API call.
  • Disk watermarks warn at 80% and block new deploys at 90%.
  • Rate limits per tenant (100 req/s, burst 200) and globally.
  • Idempotency keys on POST/PUT/DELETE, so an agent that retries a request doesn't deploy twice.
  • ah backup takes WAL-safe SQLite snapshots and keeps the last 10.

Notice that every one of these is designed for a user who is fast, tireless, and occasionally wrong. That's a pretty good description of an agent. It's also a pretty good description of a junior engineer — and we figured out a long time ago that the way you work with those isn't to withhold access, it's to build an environment where mistakes are cheap.

What this changes

I think we're moving from a world where we operate software to one where we supervise it. The skill that matters is less "do you know the right docker run flags" and more "did you set up the boundaries so the thing doing the work can't hurt you." Infrastructure becomes a kind of management: you define the verbs, the limits, and the escape hatches, and then you get out of the way.

agentic-hosting is an early, opinionated version of that idea. It's not trying to be Kubernetes. It's a single binary that turns a server you already own into a place your agents can ship to. It's still evolving — custom domain management, audit logging, mTLS, and per-agent dev environments are on the roadmap or in progress.

Takeaways if you want to try it:

  • Start in --dev mode locally, then move to a real box.
  • Give each agent its own tenant and API key — isolation is the point.
  • Install the Claude Code skill; it's the fastest way to feel the loop.
  • Read the security model section before you hand over a key.

If this way of thinking about agents and infrastructure resonates, give the repo a star on GitHub — it genuinely helps other people find it — and open an issue with what you'd want your agent to be able to do next. I'd love to hear what you build with it.