Three Coding Agents, One Deploy

All three agents deployed the app, unaided, in a sandbox with no hints and no custom instructions file. None of them failed on the platform. They all lost time on the same five rough edges in the CLI and the install script, and those are the interesting part.

We shipped the Hostim CLI this month. It was written with coding agents as first-class users, and dogfooded by deploying 30 open-source apps with it. Then I tested whether that actually works, by handing the job to agents that had never seen it.

The CLI, briefly

One line to install, one command to log in, and every write command answers in JSON:

curl -fsSL https://raw.githubusercontent.com/hostimdev/cli/main/install.sh | sh
hostim login                 # device code: approve it in the browser
hostim deploy web --docker-image nginx --plan sa-1-1 --port 80

Two things in it exist only because of agents:

• hostim agent prints the entire manual to stdout. The binary embeds its own README, so an agent reads the manual for the version it has installed instead of guessing flags from a blog post.
• hostim mcp runs a Model Context Protocol server on stdio. Read-only tools by default (list_projects, get_app_status, get_app_logs, …); anything that creates or deletes needs --allow-write.

It is beta. Flags and output can still change between releases.

The dogfooding was real work, not a demo: our 35 curated templates — 30 open-source apps like listmonk, Chatwoot, FreshRSS, Docmost, PhotoPrism, plus five framework demos — are the same template YAML the CLI applies with hostim templates apply. If the format is awkward, we are the first to feel it.

The test

A local harness, one Docker container per run, no host filesystem except the run's own directory. The agents run vanilla: I copy in the auth token and nothing else. No global config, no AGENTS.md, no hints about Hostim — that is the thing under test.

One prompt:

Deploy Miniflux (https://github.com/miniflux/v2) on Hostim

Three agents: Claude Code (Sonnet 5), Codex, and OpenCode driving DeepSeek V4.1 Flash. Same prompt, same app, separate containers, transcripts saved.

I picked Miniflux because it is honest work and not a hello world: a Go binary plus Postgres, migrations on boot, an admin user to bootstrap, a BASE_URL it gets grumpy about, and a /healthcheck endpoint to prove the result.

What happened

All three ended with Miniflux running behind TLS on a *.eu-center.hostim.dev subdomain, migrations at version 132, an admin user created, and — where the agent bothered to check — curl returning 200.

Two things I did not expect.

Claude Code did not reach for the CLI at all. Given the bare prompt it searched the web, read our docs, pulled Miniflux's own contrib/docker-compose/basic.yml from GitHub, generated credentials, wrote a docker-compose.yml, and gave me a numbered list of things to click in the console. A good answer to a question I did not ask. It found the CLI immediately when I said "with cli please", and drove the whole deploy itself when I said "i want you to do it" — including stopping at the device-code step to hand me the code and wait. But unprompted, our docs pointed it at the browser.

Every agent that used the managed database got the credentials right. Not by copying a connection string, but with our placeholder references:

DATABASE_URL=postgres://$(DB_POSTGRES_USER):$(DB_POSTGRES_PASSWORD)@$(DB_POSTGRES_HOST):$(DB_POSTGRES_PORT)/$(DB_POSTGRES_DATABASE)?sslmode=disable
BASE_URL=https://$(BUILTIN_DOMAIN)

Two of them inferred that from template examples, because the manual did not document the placeholders. It does now.

Cost of the resulting stacks: the app on sa-1-1 at €2.50/mo, managed Postgres on the free sp-0 tier. Two agents found the free tier on their own by running hostim regions pricing eu-center --for postgres before creating anything.

The five things they tripped over

Same agents, same friction, three times over. All of it ours, none of it clever:

1. install.sh called sudo unconditionally and died with sudo: not found in a plain container — the exact environment an agent runs in. It now installs to ~/.local/bin when the prefix is not writable and sudo is missing, and warns if that is not on PATH.
2. The success line printed Installed . when the binary was not yet on PATH, because it used command -v. It prints the resolved path now.
3. hostim version was not a command, only --version. Codex tried the obvious form, got error: unknown command "version", and burned a turn on it. Both work now.
4. Device login said "Waiting for you to approve the login…", which reads like something the caller has to poll. Two agents wrote their own polling loop around a command that already polls and saves the token. The message now says so, and the manual says it twice.
5. Nobody found hostim agent. The manual is in the binary and no agent thought to look, so hostim --help now points at it in the first lines.

None of these is a bug in the interesting sense. Every one of them cost an agent a turn or a wrong path, and a human would have shrugged and moved on without telling me.

What I take from it

Agents fail on small, dumb, mechanical things: a missing subcommand alias, a status message with the wrong mood, an install script that assumes a laptop. They do not fail on the hard parts — those they read, infer and get right. "Make it easier for agents" turned out to mean stop lying in your output, not build an agent product.

The other lesson is that discovery is the real gap. Our docs were written for someone with a browser open. An agent with a shell wants to know there is a CLI in the first paragraph, and that the manual ships inside the binary. Fixing that is a docs job, not an engineering one.

This is now a biweekly routine: run the agents, read the transcripts, fix whatever they tripped on. If your platform has a CLI, I recommend it — it is the cheapest usability testing I have ever run, and the tester never gets bored of telling you the same thing.

FAQ

Can a coding agent deploy an app without help?
Yes. In our September 2026 test Claude Code, Codex and OpenCode each deployed Miniflux with managed Postgres, TLS and a working health check from a single sentence of instruction. The one step a human does is authorizing the account: hostim login prints a device code and somebody approves it in a browser. That happens once — afterwards the token is on disk and the agent runs unattended. In CI there is no login step at all, just HOSTIM_TOKEN.

How does an agent authenticate?
hostim login prints a URL and a short code, polls until you approve it in the browser, and saves the token. For CI, export HOSTIM_TOKEN and skip login entirely.

Is there an MCP server?
Yes: hostim mcp on stdio, same binary and token. Read-only tools are always registered; creates and deletes need --allow-write.

How do I give an agent the CLI documentation?
hostim agent prints the full manual to stdout. Pipe it into the agent's context before it writes commands.

If your deploys should be driveable from a terminal, a pipeline or an agent — not only from a console someone has to sit in front of — that is what Hostim is built for. EU-hosted, flat monthly price, managed Postgres, MySQL and Redis with replication and failover on every plan.

Originally published on hostim.dev. Test run on 14 September 2026 with hostim CLI v0.1.20, Claude Code v2.1.270 (Sonnet 5), Codex, and OpenCode on DeepSeek V4.1 Flash.