DEV Community: Dennison Bertram

I Let My AI Agent Create Its Own Databases. Here's How the Passwords Stay Locked Up.

Dennison Bertram — Thu, 29 Oct 2026 14:29:55 +0000

There's a moment in almost every project when the app needs to remember something. My agent has written the code and shipped it, and now it needs a database. For a long time, that was where I took over. I'd click around a dashboard, copy a password, paste it into a .env file, and then paste it into the chat so the agent could use it.

By the end of that, the password lived in four places, and I'd chosen none of them on purpose. So I started wondering what it would look like if the agent could just ask for a database, wire it up, and never show the password to anyone, including me.

This post walks through how agentic-hosting does that. It's an open-source tool I built that turns a Linux server into a place where AI agents can deploy apps and databases on their own. By the end you'll know how to create a Postgres or Redis database with one API call, connect it to an app, keep its password out of chat logs, and remove it cleanly.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

A few words first

agentic-hosting is one program, ah, that runs on your server. Agents talk to it over an HTTP API. Each agent (or team) is a tenant with its own API key, and an app it runs is called a service.

The examples below use two shell variables: AH_URL is your server's address and AH_KEY is the tenant's API key. The commands use curl and jq, which is also how an agent drives it.

Asking for a database

One request creates a database. The type is postgres or redis:

IDEM=$(uuidgen)   # reuse this on retries
curl -s -X POST "$AH_URL/v1/databases" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $IDEM" \
  -d '{"name":"notes-db","type":"postgres"}'

The call doesn't come back until the database actually works. ah pulls the image (postgres:16-alpine or redis:7-alpine), starts a container, and then checks readiness by speaking the database's own protocol, not just by seeing an open port. Once the image is on the box this takes about 30 seconds. On a fresh server the pull can take longer, so the route allows up to six minutes.

That's why the Idempotency-Key header matters. Agents retry. If the connection drops halfway and the agent sends the same request with the same key, ah waits for the first one to finish and hands back its result, instead of making a second database. It remembers a successful result for 10 minutes.

You get back a 201 with something like this (trimmed):

{
  "id": "3f9c0a…",
  "name": "notes-db",
  "type": "postgres",
  "status": "ready",
  "host": "ah-db-3f9c0a…",
  "port": 5432,
  "db_name": "ah",
  "username": "ah",
  "connection_string": "postgres://ah:…"
}

Names start with a letter, can use letters, numbers, hyphens, and underscores, and can be up to 63 characters. For Postgres, the database and user are both called ah. The password is 32 random bytes written as 64 hex characters. Nobody picks it.

Where the password goes

This is the part I care about most. Before anything is saved, ah encrypts both the password and the full connection string with AES-256-GCM, using the server's master key. Only the encrypted versions go into ah's own database.

The plain connection string shows up in exactly two places:

the response to the create call
a dedicated endpoint for fetching it

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/databases/$DB_ID/connection-string"
# {"connection_string":"postgres://ah:…"}

Every call to that endpoint writes an audit line to the server log with the tenant, the database, and the ID of the API key that asked. Listing or reading the database (GET /v1/databases and GET /v1/databases/{id}) never includes it.

Two honest notes. First, there's one master key for the whole server, and right now it encrypts everything directly: env vars, database passwords, connection strings. A design for deriving a separate key for each of those uses is in the repo but not built yet. Tenants are kept apart by the API, which scopes every lookup to the tenant's own records, not by separate keys. Second, "encrypted at rest" here means the credentials ah stores. The rows inside your Postgres sit in a normal Docker volume, and traffic between your app and the database is plain TCP (sslmode=disable) on a private network that only your services can join.

Wiring it into an app

ah doesn't add DATABASE_URL to your app on its own. You set it, then restart. Those are two calls, and the connection string goes straight from one to the other without being printed:

CONN=$(curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/databases/$DB_ID/connection-string" \
  | jq -r .connection_string)

jq -n --arg u "$CONN" '{DATABASE_URL: $u}' \
  | curl -s -X POST "$AH_URL/v1/services/$SVC_ID/env" \
    -H "Authorization: Bearer $AH_KEY" \
    -H "Content-Type: application/json" -d @-

curl -s -X POST \
  "$AH_URL/v1/services/$SVC_ID/restart" \
  -H "Authorization: Bearer $AH_KEY"

Setting env merges new keys into what's there. The response is only {"status":"updated", ...}, with no values in it. Environment variables are encrypted with the same master key. If you read them back, every value comes back as ******** unless you add ?reveal=true, and a reveal is also written to the audit log.

The restart matters more than it looks. It recreates the container, which is the only way new environment variables take effect, and it's also when the app gets connected to its database. More on that next.

For Redis it's the same flow. Use REDIS_URL as the name by convention, and the string looks like redis://:<password>@ah-db-<id>:6379/0.

How the app finds the database

Look at the host in the connection string: ah-db-<id>, not an IP address. That's on purpose, and it's something I got wrong at first.

Early versions handed out 127.0.0.1:<port>. That looks fine until you remember the app runs in its own container, where 127.0.0.1 is the container itself. The app was knocking on its own door. It was reported as issue #164 and fixed in October.

Now each database gets its own private Docker network, named ah-dbnet-<tenant>-<db>, with no route to the internet. On that network the database answers to the name ah-db-<id> on its normal port, 5432 or 6379. When a service is deployed, started, or restarted, ah looks at its environment variables. If one of them mentions one of that tenant's databases, ah connects the service to that database's network.

Two details follow from this. Only the tenant's own databases are checked, so another tenant can't get in by copying your connection string into its app. And the name only works from inside a service container. Running psql against it from the server itself won't resolve, and that's expected.

If you're upgrading from an older version, ah rewrites the old 127.0.0.1 strings on startup, both on the database and in any service env that copied it. Running apps still need one restart to pick up the new value. The fix is covered by tests in the repo, and the design note still lists a check on a live gVisor host as a to-do. If something doesn't connect for you, I'd like to hear about it.

Or let your agent do it

All of the above is one command with ahc, the project's command-line client:

ahc db provision notes-api postgres

It creates a database named notes-api-postgres (pick another with --name), waits for it, sets DATABASE_URL (or REDIS_URL for Redis) on the service, and restarts it. It prints only the host, not the password. If you use Claude Code, the repo also ships an /ah-db slash command that does the same steps and is told never to print the full connection string.

In practice I mostly say "this app needs Postgres" and let the agent pick one of those.

The limits

This is deliberately one simple path, not a database service with every option:

Limit	Value
Engines	Postgres 16, Redis 7
Databases per tenant	3 by default
Memory per database	512 MB
Sandbox	gVisor, all Linux capabilities dropped except 5
Disk	blocked at 90% full

Going past the quota returns a 409. If the disk is 90% full or more, creates fail with a 503 and a Retry-After header, so the agent knows to wait instead of retrying in a loop. There's no MySQL, no custom images, and no replicas or failover.

Backups are a job for your agent

ah keeps your data in a Docker volume named ah-db-<id>, but it doesn't back that volume up. Its own backup command covers its control-plane state, not your app's rows. This is the part I hand to my agent, because it's a well-defined chore:

Every night, dump each Postgres database
with pg_dump inside its container, gzip it,
copy it to my backup host, and keep 7 days.
Restore last night's dump into a scratch
database once a week to prove it works.
Alert me if a dump is missing or empty.

The agent writes the timer, the script, and the restore check, and I review them once. The big platforms used to sell redundancy, backups, and monitoring as features. An agent can build the same pieces on your own server, and you can read exactly what it built.

Cleaning up

Delete in the opposite order you created. Point the app away from the database first, so it isn't left with a broken URL:

curl -s -X DELETE -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SVC_ID/env/DATABASE_URL"
curl -s -X POST -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SVC_ID/restart"

curl -s -X DELETE -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/databases/$DB_ID"

The delete returns 204. ah stops and removes the container, then overwrites every file in the volume with zeros, so a later tenant on the same disk can't recover the data. Then it removes the volume, the record, and the private network. With the CLI it's ahc db delete notes-db --confirm, and the --confirm is required.

If something is left behind anyway, a background cleanup loop removes ah-db-* volumes that no database record owns, and database networks nothing owns once they're 15 minutes old.

Wrapping up

An agent on agentic-hosting gets a working Postgres or Redis database with one call. The password is random, encrypted before it's stored, and only handed out through one audited endpoint, and the app reaches the database over a private network that's set up when it restarts. Pair it with a nightly dump your agent writes, and delete it cleanly when you're done.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, or read the Postgres & Redis page on the docs site.
Open an issue if you'd want built-in database backups or separate encryption keys next. I'd like to know which one you'd use first.

Cover photo: storage tanks of the National Molasses Company on the Houston Ship Channel, with refineries behind. Blair Pittman, June 1973, for the EPA's Documerica project. U.S. National Archives, public domain.

My Hosting Platform Runs on Two SQLite Files. Here's How I Back Them Up and Bring Them Back.

Dennison Bertram — Tue, 27 Oct 2026 14:17:48 +0000

When people hear that the thing running my server keeps all its state in SQLite, they usually ask the same question. Isn't that a toy database? Shouldn't a hosting platform sit on Postgres, with a replica and a team that knows how to fail it over?

I went back and forth on this for a while. Where I ended up is that the database itself was never the scary part. The scary part is a question nobody likes to answer about their own setup. If this machine disappeared tonight, how long would it take to get everything back? With a couple of small files, the honest answer can be "a few minutes", and you can prove it by doing it.

This post walks through how agentic-hosting stores its state. It's an open-source tool I built that turns a Linux server into a place where AI agents can deploy apps and databases on their own. By the end you'll know where its data lives, how to take a safe backup while it's running, what else you need to copy, and how to restore everything on a fresh server.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

A few words first

agentic-hosting is one program, ah, that runs on your server. Agents talk to it over an HTTP API to deploy apps, add Postgres or Redis, and read logs. ah is the control plane. It doesn't run your apps itself. It keeps track of them and tells Docker what to do.

That record keeping is what this post is about. Every account, API key, app, build, environment variable, and database ah knows about is a row in SQLite, a database that lives in a single file on disk. There's no database server to install or keep running.

Where the data lives

On a standard install, everything sits in /var/lib/ah:

/var/lib/ah/
├── ah.db            # state: tenants, keys,
│                    # services, builds, env
├── ah-metering.db   # usage samples
├── master.key       # encryption key
└── backups/         # output of `ah backup`

There are two database files, not one, and I'll come back to why. You'll also see ah.db-wal and ah.db-shm next to them while ah is running. Those belong to SQLite, and they matter a lot for backups.

You can look inside with the regular sqlite3 tool. This lists the schema changes the database has been through:

sudo sqlite3 /var/lib/ah/ah.db \
  'SELECT name FROM schema_migrations;'

ah ships its schema as numbered SQL files built into the binary. On startup it applies any it hasn't recorded yet, each one in its own transaction along with the row that records it. Right now that's 26 files for the state database and 2 for metering. When you upgrade, the new binary applies its new files the first time it starts.

Why SQLite holds up here

Three settings do most of the work. ah opens both files like this (wrapped to fit):

sql.Open("sqlite3", path+
  "?_journal_mode=WAL"+
  "&_busy_timeout=5000"+
  "&_foreign_keys=on"+
  "&_txlock=immediate")

WAL mode. By default SQLite writes changes straight into the main file, and readers wait while that happens. In WAL (write-ahead log) mode, new writes go to the -wal file first and get folded into the main file later. Readers keep reading while a write is in progress. For a control plane, where an agent polling build status shouldn't stall another agent's deploy, this is the setting that matters most.

A busy timeout. SQLite still allows only one writer at a time. With _busy_timeout=5000, a second writer waits up to 5 seconds for its turn instead of failing at once.

Take the write lock up front. This one took me a while to understand. A normal SQLite transaction starts as a reader and asks for the write lock only when it first writes. If another connection committed in between, SQLite returns an error right away and the busy timeout never kicks in. _txlock=immediate makes every transaction ask for the write lock at the start, so it waits its turn like everyone else. The repo has a test for exactly this case.

ah also caps each file at 4 open connections, which is plenty for one server. And one server is the real limit of this design. Everything assumes one machine, and the docs list multi-node as a known gap. I'm fine with that. One machine with good backups is a setup I can understand at 2am.

Why two files

ah.db holds the things you'd be upset to lose: accounts, keys, apps, builds, encrypted environment variables, and database passwords. ah-metering.db holds usage. Every 60 seconds ah records a CPU and memory sample for each running app, in two tables, usage_events and usage_daily.

The way I think about it, those are different kinds of data. Metering writes on a timer, forever, and it grows with every app you run. State changes when something actually happens. Since SQLite allows one writer per file, putting the steady stream of samples in its own file means it never queues behind, or in front of, a deploy. The split also shows up in backups. If the metering backup fails, ah backup logs a warning and carries on. If the state backup fails, the whole run fails.

The code keeps the two apart on purpose. Each migration file has to start with state_ or metering_, and ah refuses to start if one doesn't, so a schema change can't end up in the wrong database.

Taking a backup while it's running

Here's the trap with WAL mode. Recent writes can sit in ah.db-wal for a while before they reach ah.db. If you cp ah.db somewhere, you can get a file that's missing recent changes, or one that's inconsistent.

SQLite has a command for this, VACUUM INTO. It reads the database through SQLite itself, WAL included, and writes a clean standalone copy to a new file. It works on a read-only connection, so the backup never takes the write lock away from the running server.

That's what ah backup does:

sudo -u ah /usr/local/bin/ah backup \
  /var/lib/ah/ah.db

Step by step, it:

creates backups/ next to the database, readable only by its owner
stops if that disk is 90% full or more, and warns at 80%
opens ah.db read-only and runs VACUUM INTO a temp file, with a 5 minute timeout
gzips the copy to ah-YYYYMMDD-HHMMSS.db.gz, writing to a .tmp file and renaming it at the end, so a half-written backup never has a real name
does the same for ah-metering.db if it exists
keeps the 10 newest state backups and the 10 newest metering backups, and deletes older ones

Afterwards you'll see something like:

/var/lib/ah/backups/
├── ah-20261027-091700.db.gz
└── ah-metering-20261027-091700.db.gz

A quick sanity check that a backup is a real SQLite file:

sudo sh -c \
  'gunzip -c /var/lib/ah/backups/ah-2*.db.gz' \
  | head -c 15
# SQLite format 3

To run it every hour, a cron entry is enough:

# /etc/cron.d/ah-backup
17 * * * * ah /usr/local/bin/ah backup /var/lib/ah/ah.db

What the backup doesn't include

The .db.gz files aren't everything you need:

Item	Why you need it
`master.key`	decrypts env vars and DB passwords
`/etc/default/ah`	bootstrap token and settings
Docker volumes	your Postgres and Redis data
local registry	images you built on the box

The master key is the big one. Secrets in ah.db are encrypted with it, and ah backup never writes it into a backup. Store it somewhere other than your database backups, because anyone holding both can read your secrets.

One more detail. If you rotate the key with ah rotate-key, older backups still need the old key. Keep each key for as long as you keep backups made with it.

And your apps' actual data, the rows in the Postgres databases ah created for you, lives in Docker volumes named ah-db-*. That needs its own backup. The SQLite file only knows those databases exist.

Getting copies off the box

A backup that lives on the machine it's protecting doesn't protect much. This is the kind of chore I hand to my agent. A prompt like this works:

Every hour, after ah backup runs, rsync
/var/lib/ah/backups/ to my backup host.
Copy master.key to my secrets manager once,
and again after any key rotation. Alert me
if the newest backup is more than 2 hours
old.

The agent writes the timer, the copy script, and the check. I review them once. The big platforms used to give you redundancy, backups, and monitoring as a feature. Now an agent can build the same pieces on your own box in an afternoon.

If an hour of possible loss is too much, the repo has an optional Litestream setup (deploy/litestream.yml and a runbook in docs/ops/) that streams both databases to S3-compatible storage as they change. ah doesn't install or manage it. You run it as its own service.

Bringing it back

There's no ah restore command. A restore is a few file operations, which I like, because there's nothing extra that has to work on the worst day. On the new server, install ah the normal way and copy over /etc/default/ah. Put the backup files in /var/lib/ah/backups/ and the key in your home folder. Then, as root:

systemctl stop ah
cd /var/lib/ah
mkdir -p pre-restore
mv ah.db* ah-metering.db* pre-restore/

TS=20261027-091700
gunzip -c backups/ah-$TS.db.gz > ah.db
gunzip -c backups/ah-metering-$TS.db.gz \
  > ah-metering.db
install -m 600 -o ah -g ah \
  ~/master.key master.key

chown ah:ah ah.db ah-metering.db
chmod 600 ah.db ah-metering.db
systemctl start ah

Moving the old -wal and -shm files out of the way is the step people skip. If a stale WAL file sits next to the restored database, SQLite can try to replay it into the restored file. If you skip the metering file, ah starts with an empty one and you lose usage history, nothing else.

Then check it's up. The API wants HTTPS, so a local request has to say it came through the proxy:

curl -s -H 'X-Forwarded-Proto: https' \
  http://127.0.0.1:8080/v1/system/health

If you restored with the wrong master.key, you'll know right away. On startup ah decrypts a key it uses to check API keys, and if that fails it refuses to start, with wrong master key? in the error in journalctl -u ah. I like that it fails loudly. A server that started and then quietly rejected every API key would be much worse.

What happens to the apps

The restored database describes apps that may not be running on the new machine. ah doesn't trust those rows. Every 30 seconds a loop called the reconciler compares the database with what Docker actually has. An app marked running with no container gets marked crashed, with the reason container not found by reconciler. Nothing restarts on its own.

To bring an app back, redeploy it with ahc, the project's command-line client:

ahc service redeploy my-api
ahc status

A redeploy starts the app again from the image it already had. If that image was built on the old server and you didn't copy the local registry, it won't be there. Start a fresh build from git instead, the same way the app was deployed the first time.

Or tell your agent "the server was restored, redeploy everything that was running." It can list the services, see which ones are marked crashed, and work through them one at a time.

Then do the test that actually matters. Open an app that uses a secret, like a database password, and make sure it works. That's the proof that the key and the database belong together.

Wrapping up

agentic-hosting keeps its whole control plane in two SQLite files: ah.db for state and ah-metering.db for usage. WAL mode keeps reads and writes out of each other's way, ah backup uses VACUUM INTO to take consistent copies while the server runs, and a restore is just putting the files and the master key back. Have your agent ship the copies off the box, and run the restore once on a scratch server before you need it.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, or read the backups page on the docs site.
Open an issue if you'd want a built-in ah restore or volume backups for managed Postgres. I'd like to know which one you'd use first.

Cover photo: seats and fittings from old Amtrak passenger cars piled in a warehouse at Mira Loma, California, waiting to be renovated or replaced. Charles O'Rear, May 1974, for the EPA's Documerica project. U.S. National Archives, public domain.

When your coding model refuses your own AppSec work

Dennison Bertram — Mon, 26 Oct 2026 17:33:10 +0000

If you do application security, you have probably watched a coding model decline something routine: writing a proof of concept for a bug in your own staging app, or explaining how a flaw in your own handler would be exploited so you can fix it. That leaves the defender with less help than an attacker would have.

I work on free-pi, a free terminal coding agent. We are adding an opt-in Defense section to the /model picker for signed-in GitHub users. The first model is Defense Flash: a reasoning model with tool use and a 1M-token context, chosen for lawful security work that general models often refuse. It is billed from normal credits like any other model. We have not published tests of it, so this post is about using it responsibly, not a benchmark.

Ground rules

Use it for:

systems and code you own,
employer or client systems where you have written permission to test,
in-scope bug bounty targets, following the program's rules,
software you own or may lawfully analyze (free-pi's /reverse-engineer-anything command covers native binaries, JS and Electron apps, APKs, .NET and websites).

Do not use it on anyone else's systems. Computer misuse laws apply whichever model you pick, and a bounty program's scope list is a boundary.

Habits that help

State the context: who owns the system and what you are authorized to do.
Aim at find-and-fix: ask for the minimal patch and a regression test.
Test in isolation: a local container or disposable staging copy, never production, no real credentials. free-pi has no OS sandbox for normal sessions.
Verify claims: reproduce a reported flaw before you file it, and review every generated patch.
Keep the scope in the session: for bounty work, paste the program's scope text.

Pairing

free-pi bundles the audit method and checklists from the security-audit skill, run in a single agent, so validate each finding yourself. /reverse-engineer-anything covers software you may lawfully analyze. The Defense section is where to look when a general model declines the lawful part.

More at freepi.ai.

A practical CI and supply-chain hardening checklist you can run with a terminal agent

Dennison Bertram — Mon, 26 Oct 2026 17:32:14 +0000

Your CI is code that runs with your secrets and publishes what your users install. Cloudflare's open-source security-audit skill includes a SUPPLY-CHAIN-AND-RELEASE.md reference whose core rules are useful questions to ask your own pipeline, even without running a full review:

A known-vulnerable or mutable dependency is not a finding by itself. Ask who can influence resolution and what the build does next.
Follow integrity across every handoff, from source to the artifact a user runs.
CI configuration is authorization code: which event triggered it, whose code runs, which secrets exist, what can it publish?
A checksum fetched from the same untrusted place as the artifact proves nothing independent.

I work on free-pi, a free terminal agent that bundles the skill's audit method and reference checklists. It runs them in a single agent, without sub-agents or an OS sandbox, so check every claim the agent makes yourself. This guide is illustrative, not a recorded run. Only review pipelines you own or have permission to review.

Ask for a read-only review first

review my CI and release setup for supply-chain risks, using the
supply-chain reference in the security-audit skill. Do not change files yet.

Seven common GitHub Actions checks

These are general good practice, not a list from the skill. You can verify each one yourself.

Unpinned actions: pin uses: to a full commit SHA.
Broad token permissions: set a top-level permissions: with the least needed.
Untrusted input in run: steps: PR titles and branch names can inject shell commands; pass them via env vars and quote.
Risky triggers: pull_request_target and workflow_run can run with secrets while touching fork code.
Secret reach: limit which jobs can read publish tokens; prefer short-lived credentials.
Provenance: know which commit built each published artifact, and let users verify it.
Lockfiles and install scripts: install from committed lockfiles and review packages with install scripts.

permissions:
  contents: read

Fix one thing per PR

Ask the agent for one change at a time and review each diff yourself. CI files guard your secrets, so do not merge what you do not understand, and run the workflow on a branch first.

What it cannot see

Branch protection, registry permissions, hosted-runner settings and signing-service configuration live outside the repo. Check them in your hosting and registry settings.

free-pi has an opt-in Defense model section in /model for when a general model declines lawful work on your own pipeline. More at freepi.ai.

A structured security review of your own repo, from the terminal

Dennison Bertram — Mon, 26 Oct 2026 17:32:13 +0000

Most "AI security review" prompts give you a pile of plausible-sounding warnings. Cloudflare's open-source security-audit skill (MIT) describes a more disciplined method: map the code, hunt by coverage, try to disprove every candidate, and write findings as structured records.

I work on free-pi, a free terminal coding agent that bundles the skill's audit method and reference checklists. This post explains the method and how to check its output. It is a guide, not a recorded run, and the commands are illustrative. Only review code you own or have permission to test.

The six phases in the skill's README

Reconnaissance: map architecture, trust boundaries and input surfaces into architecture.md and coverage-ledger.json.
Coverage-led hunting: work through units from the ledger.
Candidate validation: try to disprove each candidate.
Structured output: findings.json with confirmed, needs_validation and rejected records, checked against a JSON schema.
Record verification: re-check source claims.
Reporting: REPORT.md, FINDINGS-DETAIL.md and NEEDS-VALIDATION.md.

The skill also has reference files of attack classes for web and auth protocols, client-side code, supply chain, cloud deployment, memory safety and more.

What free-pi does differently from the skill's design

The skill's README expects an agent that can run parallel sub-agents, so the agent that finds a problem is never the agent that checks it, plus an OS-enforced sandbox for running target code. free-pi has neither. It runs the skill in a single agent that follows the method itself.

So the independent checking in the skill's design does not happen. The same agent raises and judges each candidate, and you should validate every finding yourself. Do not ask it to build or run code from a repo you do not trust.

Starting it

From your repo root:

security audit this codebase

A direct request asks for the full method; narrower questions get lighter guidance. The skill's default output directory is ~/security-audit-skill/<repo-name>/run-<N>, outside your repo.

Checking the results

confirmed: follow the source trace in the code yourself.
needs_validation: each should name one unknown fact, and you often know the answer.
rejected: skim to see what was set aside.

The skill's authors say a single run found roughly half of what repeated runs found, so run it again after your first round of fixes.

Limits

It reads code. It cannot see your cloud settings, registry permissions or branch protection. Treat every finding as a lead to verify, not a verdict.

To try it: npx free-pi-cli, sign in with GitHub, and ask for a security audit. More at freepi.ai.

I Taught My Coding Agent to Run My Server With One Text File. Here's How to Write One for Yours.

Dennison Bertram — Sun, 25 Oct 2026 14:14:09 +0000

For a while I had a ritual. Every time I opened a new chat with my coding agent, I pasted in the same paragraph: here's my server's address, here's how you deploy, the build field is called this and not that, don't do the other thing. If I forgot, the agent did what any smart newcomer does. It guessed. It guessed field names that sounded right and weren't. It called endpoints that should exist and don't.

The agent wasn't the problem. It had never seen my server. Nobody had given it the manual.

That paragraph is now a file. It sits in a folder on my laptop, the agent reads it when the conversation turns to my server, and I haven't pasted anything in months. I think this is one of the most underrated tricks in working with agents right now, and it takes about an hour to do for your own setup.

This post explains how those files work, using agentic-hosting as the example. It's an open-source tool I built that turns a Linux server into a place where AI agents can deploy apps and databases on their own. By the end you'll know how to install its agent instructions, use its six shortcut commands, and write the same kind of file for your own infrastructure.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

A few words first

I use Claude Code, Anthropic's coding agent that runs in your terminal, so the examples here are for it. Two terms:

A skill is a folder with a file called SKILL.md in it. The file has a short header saying what the skill is for, then plain instructions. Claude reads the instructions when your request matches the header.
A slash command is a shortcut you type, like /ah-deploy. It's also just a markdown file. When you type the command, Claude Code drops that file's text into the conversation as instructions.

Skills follow an open format called Agent Skills, so other agent tools can read the same files. Slash commands are a Claude Code feature.

agentic-hosting itself is one program, ah, running on your server. Agents talk to it over an HTTP API. $AH_URL below is your server's address and $AH_KEY is the agent's API key.

What a skill file looks like

Here's the top of the skill I ship, trimmed and wrapped:

---
name: agentic-hosting
description: This skill should be used when
  the user asks to install, set up, or operate
  agentic-hosting... Trigger on "deploy a
  service", "provision a database", "register
  a tenant", "view logs", ...
---

# agentic-hosting

Fetch this file from a raw GitHub URL and
follow it end to end. You do not need a GUI.
Every action is curl against `/v1/`.

The part between the --- lines is the header. The part I didn't expect to matter so much is description. Claude Code keeps every installed skill's description in view all the time, but it only loads the full body when your request looks like a match. So the description isn't a summary for people. It's a list of the things you'd actually say when you want this skill. "Deploy a service." "View logs." If I'd written "a self-hosted PaaS control plane", Claude would rarely connect that to "put my app online."

That loading rule also means a long skill is cheap until it's used. You can put a lot of detail in the body without paying for it in every conversation.

Two copies, two jobs

agentic-hosting ships its instructions in two shapes, because people use agents in two ways.

One file you can hand to any agent. The standalone skill lives at skills/agentic-hosting/SKILL.md. It's about 300 lines and covers everything: installing the server, creating an account, deploying from git, adding Postgres or Redis, reading logs, and the full API map. Any agent that can read a URL can follow it. llms.txt (the link in the callout above) is the index that points to it and to the rest of the docs.

A Claude Code bundle. The repo's .claude/ folder has a fuller skill, four reference files it can open when it needs detail, and six slash commands. One line installs all of it:

curl -fsSL https://agentic.hosting/install-skill.sh | bash

That puts the skill and its reference files in ~/.claude/skills/agentic-hosting/ and the commands in ~/.claude/commands/. Files in your home folder work in every project on that machine. Then tell it where your server is, in your shell profile:

export AH_URL=https://your-server
export AH_KEY=keyid.secret

If you only want the single file:

R=https://raw.githubusercontent.com
P=dennisonbertram/agentic-hosting/main
D=~/.claude/skills/agentic-hosting
mkdir -p "$D"
curl -fsSL -o "$D/SKILL.md" \
  "$R/$P/skills/agentic-hosting/SKILL.md"

Using it

The easiest way is to just talk. Once the skill is installed, these all work without any special syntax:

deploy https://github.com/me/blog as "blog-web"
on port 3000, then show me the build output

add a postgres database to blog-web

what's the status of my services?

Claude matches the request to the skill, reads the instructions, and runs the curl calls. You can also call the skill by name with /agentic-hosting, since the folder name doubles as a command.

The six slash commands are shortcuts for the jobs I do most:

Command	What it does
`/ah-deploy`	Deploy from a git URL or Docker image
`/ah-status`	Disk, services, databases, builds
`/ah-db`	Add Postgres or Redis to an app
`/ah-logs`	Stream app logs, or a build's logs
`/ah-register`	Create an account, get an API key
`/ah-snapshot`	Snapshot an app before a risky change

/ah-status is the one I use daily. It reads disk use, lists every app with its status and crash count, flags anything not running, and checks for builds in progress. It's my morning "is anything on fire" check, and when something is, the same skill tells the agent how to handle it: what a tripped crash breaker looks like, how to reset it and redeploy, what to do when the disk is nearly full. The agent works the incident instead of handing me an error.

One note on /ah-register: it reads the server's setup secret over SSH, so it's for whoever runs the server, not for an agent that's just been handed a key.

What's inside a slash command

Here's the top of /ah-deploy, trimmed and wrapped:

---
description: Deploy a service to
  agentic-hosting from a git URL or Docker
  image.
argument-hint: <git-url-or-image>
  <service-name> [port]
allowed-tools: Bash
---

You are an agentic-hosting operator. Use
`$AH_URL` and `$AH_KEY` from the environment
(ask the user if not set).

Below that is a numbered list: check the server is up, stop if the disk is over 90% full, create the app, start the build, stream the log, wait up to 10 minutes for it to be running, report the URL.

Two lines in the header deserve attention.

argument-hint is what you see while typing the command. It's documentation for you, nothing more.

allowed-tools: Bash lets Claude run shell commands without asking you first, for the turn where you invoked the command. That's why /ah-deploy runs without a stack of permission prompts. It's also something to decide on purpose. For a deploy command, I want it. For a command that deletes things, I'd leave it off and approve each step. Claude Code also has a disable-model-invocation: true setting for commands Claude shouldn't start on its own, which is worth using for anything with side effects.

The bug I found while writing this

To write this post I checked every command file against the current Claude Code docs, and found a real problem in mine.

Slash commands can pull in what you typed after the command. My command files were written when $1 meant the first argument. In current Claude Code, numbering starts at zero: $0 is the first argument and $1 is the second. So when you type this:

/ah-deploy https://github.com/me/blog blog-web 3000

the instructions Claude gets say to deploy 3000 using blog-web, and the git URL never appears in the instructions at all. Nothing errors. The agent just starts from a scrambled brief.

Until the files are fixed, plain English (the examples above) is the reliable way to deploy. If you write your own commands, two habits avoid this. Use $ARGUMENTS, which is everything you typed, and let Claude sort it out. Or name your arguments in the header (arguments: [source, service, port]) and write $source and $service in the body, so the numbering can't shift under you.

The bigger lesson is that these files are code that nothing compiles. They drift from your API, and from the agent tool, and nobody gets an error when they do.

How to write one for your own infrastructure

This is the part I'd steal if I were you. You don't need a platform like mine. Any internal API, deploy script, or runbook works. Here's what I've learned makes these files good.

1. Write the description in your own words. List the phrases you'd actually type. Claude truncates long descriptions in its listing (about 1,500 characters), so lead with the common ones.

2. Show the exact request, and name the wrong one. The most useful line in my skill is a negative: "There is no git_url / branch field." Agents kept inventing those names because they sound right. Writing down the plausible mistake fixed it in a way that just showing the right shape didn't.

3. Say what done looks like. My skill doesn't say "wait for the deploy." It gives a loop that checks every 5 seconds for up to 10 minutes and stops on one of three things: running, failed, or the crash breaker open. Agents are great at following a loop and bad at deciding when to give up.

4. Keep the main file short and link out. Anthropic's docs suggest keeping SKILL.md under 500 lines. Mine is about 400, and the full API listing, operations notes, domain setup, and server install live in four separate files the skill points to. Claude opens them only when it needs them.

5. Put the habits in writing. My database command says never print the full connection string, only host and port. That's an instruction, not a lock. The string still passes through the commands Claude runs. Write the habit down anyway. It works most of the time, and the real protection belongs on the server.

6. Test it like code, against the real thing. Open a fresh session, ask for the task in plain words, and compare what the agent does with what the server accepts. Every time I've done this I've found something. Earlier checks caught my skill reading the build's ID from a field called id when the server returns build_id, and waiting for a status string the server never sends. Both are fixed now. This round turned up the argument numbering above, plus a line in both skill files that says "redeploy" rebuilds from git. It doesn't. It restarts the app with the image it already has and the current settings.

Here's a skeleton to start from. Swap in your own endpoints:

---
name: my-deploys
description: Use when the user asks to deploy,
  roll back, check deploy status, or read
  logs for our apps on deploy.internal.
---

# Deploying our apps

Base URL: $DEPLOY_URL. Auth header:
`Authorization: Bearer $DEPLOY_TOKEN`.

## Deploy
POST /deploys {"app":"<name>","ref":"<sha>"}
- `ref` must be a full commit SHA. There is
  no `branch` field.
- Poll GET /deploys/<id> every 5s, up to
  10 min. Stop on "live" or "failed".

## Never
- Print tokens or connection strings.
- Deploy to prod without saying so first.

## More detail
- references/api.md for every endpoint.

Save it as ~/.claude/skills/my-deploys/SKILL.md, start a new session, and ask it to deploy something. Then read what it did.

The skill isn't the permission

One last thing I'd tell anyone doing this. The skill file teaches the agent how. It shouldn't decide what the agent is allowed to do. That belongs in the API key.

In agentic-hosting, the key you get when you create an account is an owner key. Extra keys you create for agents are member keys by default. A member key can deploy, add databases, and read logs, but it can't revoke keys or suspend the account. So my agents run with member keys, and the skill can be as capable as I like without any one agent being able to lock me out.

Wrapping up

A skill is the paragraph you keep pasting, saved as a file with a header that tells the agent when to read it. agentic-hosting ships one file any agent can follow, plus a Claude Code bundle with six shortcut commands, and the same recipe works for your own infrastructure: real phrases in the description, exact requests with the wrong ones named, a clear stopping point, and regular testing against the real API.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, or start at the docs site.
Open an issue if you've written a skill for your own infra and found a pattern that works. I'd like to collect them.

Cover photo: members of an outdoor-orientation workshop learning to read maps and use compasses in Warrensburg, New York. Anne LaBastille, October 1973, for the EPA's Documerica project. U.S. National Archives, public domain.

My AI Agents Share a Server. Here's How I Keep Them Out of Each Other's Way.

Dennison Bertram — Fri, 23 Oct 2026 14:13:48 +0000

The first time I had two coding agents deploying to the same server, I gave them the same password. It was the obvious thing to do. Then one agent's deploys started failing with an error about a build already running, and the build it was talking about belonged to the other agent. A few days later I wanted to stop one of them for the night and realized I couldn't do it without stopping both.

That's when I started thinking of agents less like scripts and more like roommates. They can share a house. They each need their own key, their own room, and some rules about how loud they're allowed to be.

This post shows how to give each AI agent its own account on a server running agentic-hosting, an open-source tool that turns a Linux server into a place agents can deploy apps and databases on their own. By the end you'll know how to create an account per agent, hand out keys that expire, swap keys without downtime, and shut off one misbehaving agent while the rest keep working.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

A few words first

agentic-hosting is one program, ah, that runs on your server. Agents talk to it over an HTTP API, the same way they'd call any web service.

Three terms come up a lot below:

A tenant is an account on the server. Everything an agent creates (apps, databases, builds) belongs to one tenant.
An API key is the password an agent sends with every request. A tenant can have several.
The bootstrap token is a long secret you, the person running the server, set when you install it. It's what lets someone create a new tenant. Agents don't need it after that.

In the examples, $AH_URL is your server's address.

Step 1: one tenant per agent

Creating a tenant is one request with the bootstrap token in a header:

curl -s -X POST "$AH_URL/v1/tenants/register" \
  -H "X-Bootstrap-Token: $AH_BOOTSTRAP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"blog-agent",
       "email":"me+blog@example.com"}'
# {"tenant_id":"3f9a...","api_key":"8c41....d07e..."}

The server answers 201 with the new tenant's ID and its first API key. That key is shown once. The server only keeps a fingerprint of it, so if you lose it, it can't be read back.

Some rules worth knowing before you script this for a fleet of agents:

Each tenant needs its own email. Two tenants can share a name but not an email. I use plus addresses (me+blog@, me+shop@), which the server accepts. A duplicate email gets 422.
Registration is slow on purpose. The server allows 5 registrations per hour from one IP address and 20 per hour in total. This keeps anyone from guessing the bootstrap token by brute force. If you set up ten agents in a loop, the sixth one gets 429 with a Retry-After header telling you how long to wait.
The bootstrap token must be at least 32 characters. The server won't start with a shorter one.

If you're just trying this on a laptop, ./bin/ah --dev --open-registration skips the bootstrap token entirely. Anyone who can reach the port can then make an account, so keep that to your own machine.

Step 2: read the key

A key looks like two long strings of letters and numbers joined by a dot: keyID.secret. The part before the dot is the key's ID. It isn't secret, and it's how you refer to the key later. The part after the dot is the actual password.

Agents send the whole thing on every request:

export AH_KEY="8c41....d07e..."
curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/tenant"

# the key's ID is everything before the dot:
echo "${AH_KEY%%.*}"

Step 3: keep the first key, give the agent a second

This is the habit that made everything else easier for me. The key that comes back from registration stays with me (I'll call it $MY_KEY). The agent gets a separate key that I create for it, with a name and an expiry:

curl -s -X POST "$AH_URL/v1/auth/keys" \
  -H "Authorization: Bearer $MY_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"claude-code","expires_in":2592000}'
# {"id":"51be...","name":"claude-code",
#  "api_key":"51be....9a2f...","prefix":"51be20c7",
#  "expires_at":1795359600}

expires_in is in seconds, so that's 30 days. Leave it out and the key never expires. The longest you can ask for is 10 years.

Now there are two keys on the tenant and I can tell them apart. (jq is a small tool for picking fields out of JSON.)

curl -s -H "Authorization: Bearer $MY_KEY" \
  "$AH_URL/v1/auth/keys" \
  | jq '.[] | {id, name, last_used_at, expires_at}'

The list never shows secrets. last_used_at is a Unix timestamp that updates at most every five minutes, which is enough to see whether a key is still in use before you remove it.

A tenant can hold 20 keys at once. One catch I hit: an expired key still counts toward the 20 until someone revokes it. If your agents rotate keys often, have them clean up the expired ones.

Step 4: swap keys without downtime

Rotating a key is the same three moves every time:

Create a new key for the agent.
Give it to the agent and let it make a request with it.
Revoke the old one, using its ID (the part before the dot).

curl -s -o /dev/null -w '%{http_code}\n' \
  -X DELETE -H "Authorization: Bearer $MY_KEY" \
  "$AH_URL/v1/auth/keys/$OLD_KEY_ID"
# 204

Revoking takes effect right away, even though the server caches logins for speed. The very next request with the old key gets 401 and {"error":"invalid api key"}. An expired key gets the same answer.

Because both keys work until you revoke the old one, the agent never has a moment where it's locked out. It's simple enough that an agent can do it on its own, a few days before its key expires.

Step 5: cut off one agent

Say an agent goes sideways at 2am. It's redeploying in a loop, or it's doing something you didn't ask for. You have two levels of off switch.

Revoke its key. Use your own key on that tenant to revoke the agent's key, as in step 4. The agent is locked out immediately. Its apps and databases keep running, so whatever it already shipped stays up while you figure out what happened. Every other agent on the server is untouched, because they're on other tenants with other keys.

Suspend the whole tenant. If you want everything that agent built stopped too:

curl -s -X DELETE -H "Authorization: Bearer $MY_KEY" \
  "$AH_URL/v1/tenant"

This marks the tenant suspended, revokes every one of its keys, cancels its builds, and stops its apps and databases. Nothing is deleted. To bring it back, use the admin token (a second operator secret, set as AH_ADMIN_TOKEN when you install):

curl -s -X POST \
  -H "X-Admin-Token: $AH_ADMIN_TOKEN" \
  "$AH_URL/v1/tenants/$TENANT_ID/reactivate"
# {"tenant_id":"3f9a...","api_key":"...",
#  "status":"active"}

$TENANT_ID is the tenant_id from step 1. You get a fresh key. The databases come back on their own. The apps need a redeploy.

One honest limit: keys on the same tenant are equals. There are no read-only keys or per-key permissions yet, so the agent's key could revoke yours. If that ever happens, the admin token can issue a new key for the tenant from its email with POST /v1/auth/recover. It's one more reason I never give the admin token to an agent.

What "its own space" actually means

Everything a tenant creates is scoped to it. Apps, databases, builds, and build images all carry the tenant's ID, and every lookup checks it. If one agent asks for another tenant's service by ID, it gets 404 and {"error":"service not found"}, as if the service doesn't exist.

It goes below the API too. Each app runs in its own Docker container, and each tenant's containers sit on their own private network, so one agent's app can't open a connection to another agent's app or database. An agent can deploy public images from Docker Hub, or images it built or snapshotted itself, but never another tenant's.

Each tenant also has its own budget. New tenants get 5 apps and 3 databases by default, and one build at a time. That last one is what bit me in the opening: two agents on one tenant were taking turns at a single build slot without knowing it. An agent can check where it stands:

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/tenant/usage" \
  | jq '{services, databases, api_keys, rate_limit}'
# {"services":{"used":2,"max":5},
#  "databases":{"used":1,"max":3},
#  "api_keys":{"used":2,"max":20},
#  "rate_limit":100}

As the operator, you can raise or lower a tenant's limits with PATCH /v1/tenants/{id}/quotas and the admin token. Hitting a limit returns 409 with a message like quota exceeded: maximum 5 services reached.

The one thing that isn't per tenant: web addresses

If you start ah with a domain (--base-domain apps.example.com), each app gets a web address from its name: a service called web lives at https://web.apps.example.com. Those names are shared across the whole server, first come, first served. If one agent already has web, the next agent that tries gets:

409 {"error":"subdomain already taken: web —
choose a different service name"}

A handful of names like api, admin, www, and dashboard are reserved for everyone. The fix is simple: have each agent put its project in the name, like blog-web or shop-api. Without a domain, apps get an address made from their random ID, so this never comes up.

Speed limits for each agent

Each tenant gets 100 requests per second, with bursts up to 200. All the keys on a tenant share that one budget. On top of that, the whole server has a limit of 500 per second (bursts to 1,000), so many agents together can't swamp it. I went through how these work in an earlier post, so here's just the part that matters when several agents share a server.

There are two different 429s, and they mean different things:

429 {"error":"rate limit exceeded"}
    -> this agent is going too fast

429 {"error":"global rate limit exceeded"}
    -> the whole server is busy

Both come with a Retry-After header in seconds. The first one is the agent's own doing, and it should slow down. The second means some other agent is busy, and backing off for a few seconds is all it can do. Every logged-in response also carries X-RateLimit-Limit and X-RateLimit-Remaining, so an agent can see the first kind coming.

Retries stay inside the tenant too

Agents retry a lot, so the server supports an Idempotency-Key header: a random string the agent sends with a POST so that if it sends the same request again, the server replays the first answer instead of doing the work twice. Those keys are remembered for 10 minutes and are scoped to the tenant.

That scoping is one more reason to give each agent its own tenant. Two agents sharing a tenant could, in theory, pick the same key for the same URL. The second would get the first one's answer back, or a 409 if their requests were different. Separate tenants can never collide.

What I tell my agents

If you run more than one agent, here's the short version I give each of them:

- You have your own tenant and your own key.
  Never use another agent's key.
- Put your project in every service name
  (blog-web, not web). Names are shared.
- Rotate your key before it expires: create a
  new one, switch, then revoke the old one.
- Revoke expired keys; they still use a slot.
- 429 "rate limit exceeded": you're too fast.
  429 "global rate limit exceeded": server is
  busy. Either way, wait Retry-After seconds.
- 409 is a limit, not a speed problem. Read the
  error before retrying.
- Send an Idempotency-Key on any POST you
  might retry.

Wrapping up

When agents share a server, the most useful thing I did was give each one its own tenant: its own key, its own apps and databases, its own budget, and its own place in line for builds. Keep the first key for yourself, give the agent a second one that expires, and you can rotate it, revoke it, or suspend the whole tenant without anyone else noticing.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, or start at the docs site.
Open an issue if you're running a few agents on one box and want per-key permissions. That's the next thing I'd like to build, and I want to hear how you'd use it.

Cover photo: a community garden on East 92nd Street in Manhattan, where volunteers were each assigned their own plot. Suzanne Szasz, August 1973, for the EPA's Documerica project. U.S. National Archives, public domain.

When Your AI Agent's Host Goes Down, What Should It Do? Here's What I Tell Mine.

Dennison Bertram — Thu, 22 Oct 2026 13:41:52 +0000

Railway had a rough Wednesday. Builds were paused for about a day, and when they came back the status page asked people not to trigger the same deployment more than once. That's good advice for humans. An AI agent will never think of it on its own.

This post covers how an agent can tell "the platform is down" from "my deploy is broken," what it should do in each case, and the exact rules I paste into my agents' instructions file.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

What happened at Railway

I'm only repeating what Railway has published. On October 21, Railway disclosed that someone may have accessed encrypted environment variables (the settings where apps keep API keys and database passwords) and, for some of them, gotten the decrypted contents. Railway told every customer to rotate those secrets as a precaution, and paused all deployments while it investigated.

As of this morning, the status page says builds are back for Pro and Enterprise, the deploy queue is nearly cleared, and Railway is still working on Hobby, then Free and Trial.

I'm not writing this to pile on. Every platform has a bad day, including mine. But it's a clean example of a situation most agents have no plan for.

The question I got

On my last post, a reader named alexcodebytes asked something I've been chewing on since. If an agent has a backup place to deploy, how does it know when to use it? Can it tell "the platform is down" from "my deploy failed for some other reason"?

Left alone, mostly no. An agent sees an error and assumes it caused it. That's a reasonable guess most of the time, which is exactly why it's dangerous on the days it's wrong.

Check the platform before touching code

The fix is boring: make the agent look outside before it looks inside. Before it edits a single line to "fix" a failed deploy, it should answer three questions.

Does the platform say it's down? Check the status page. If there's an open incident about builds or the API, stop there.
Is it failing everywhere? If a deploy of the last version that worked also fails, the problem isn't the new code.
Does the error point at my code? A build log with a compile error or a failing test is yours. A timeout, a 5xx error, or "service unavailable" usually isn't.

If all three point at the platform, it's an outage. If the error points at your code and the platform looks healthy, it's a broken deploy, and the agent should fix it like normal.

Then stop retrying

This is the part agents get worst. Each retry feels free to them. During an outage it just adds to the pile, which is why Railway asked people not to redeploy the same thing over and over.

My rule is two tries, then stop and tell me. No loops, no "let me try one more approach."

Rotate secrets where they're issued

If the incident involves leaked secrets, changing the value in the platform isn't enough. The old key still works until the company that issued it (your database host, your AI provider, your payment processor) revokes it. So the agent should list every key the app uses and I go revoke each one at its source.

I keep that step for myself. I don't want an agent revoking production keys on its own.

Fall back to a second place to ship

Only after all of that does the agent use the backup. For me that's agentic-hosting, an open-source program, ah, that turns a Linux server I own into a place agents can deploy apps and databases over an HTTP API.

Checking that the backup is up is one call, no key needed:

curl -s "$AH_URL/v1/system/health"
# {"status":"ok"}

Setting the new secrets and kicking off a build from git looks like this ($SVC is a service the agent already created there):

curl -s -X POST "$AH_URL/v1/services/$SVC/env" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d '{"DATABASE_URL": "postgres://..."}'

BODY=$(jq -n --arg sha "$(git rev-parse HEAD)" '{
  source_type: "git",
  source_url: "https://github.com/you/app",
  source_ref: $sha }')

curl -s -X POST "$AH_URL/v1/services/$SVC/builds" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d "$BODY"

The build call answers with a build_id the agent can use to watch the build log.

The rules I paste in

Here's the block that lives in my agents' instructions file (CLAUDE.md, AGENTS.md, whatever yours uses):

When a deploy fails:
1. Read the build log. If it shows a compile
   error or failing test, fix the code.
2. Otherwise check the platform status page
   before changing any code.
3. If there is an open incident, or the last
   good version also fails to deploy, it is
   an outage. Do not edit code.
4. Retry at most twice. Then stop and tell me.
5. If the incident mentions leaked secrets,
   list every key the app uses so I can
   revoke each one where it was issued.
6. Only then, deploy to $AH_URL. Check
   $AH_URL/v1/system/health first. Tell me
   you switched and why.

It's not clever. It just writes down what a careful person already does.

What this costs

You own the backup's uptime. If your box is down at 3 AM, there's no status page. There's you.
Two places means two setups. Secrets, domains, and databases have to exist in both, and data doesn't move itself.
The rules can still be wrong. A status page can lag, and an agent can still guess badly. This makes good calls more likely. It doesn't make them certain.

Wrapping up

When a platform goes down, the risk isn't just downtime. It's an agent retrying into a wall and "fixing" code that was fine. Teach it to check the platform first, stop after two tries, leave secret rotation to you, and only then ship somewhere else. agentic-hosting is one way to have that somewhere else on a server you own.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Set up your own backup with the quickstart.

Railway Is Down Today. My Agents Taught Me to Keep a Second Place to Ship.

Dennison Bertram — Wed, 21 Oct 2026 19:14:53 +0000

Update (Oct 22, 8:00 AM ET): Railway has since said this was a security incident: an unauthorized party may have accessed customer environment variables, some decrypted. They recommend rotating every secret stored there. Builds are back for Pro and Enterprise; Hobby, Free and Trial are still waiting, per the status page.

Railway has had builds and deploys paused since about 3:24 AM Eastern today. As I write this, a little after 3 PM, the status page still says the dashboard and API are affected and no new builds are going out in any region.

I'm not writing this to dunk on Railway. I like Railway, and every platform has a day like this, including the one I run. But today is a good, concrete look at something I've been thinking about for months: what happens to your AI agents when the place they deploy to goes away for a day.

This post covers what the outage looks like from an agent's side, why I keep a deploy target on a server I own, and the honest cost of doing that.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

What happened, from the status page

Here's what Railway has posted so far. I'm only repeating what's on status.railway.com; times are converted to Eastern.

3:24 AM: Railway starts investigating an issue.
5:28 AM: Issue identified. The dashboard, API and CLI are unavailable, and new builds are paused in all regions.
7:33 AM: The API is partly back, but builds are still paused.
12:29 PM onward: Builds and deploys stay paused, the API and dashboard are still affected, and the support site (station.railway.com) is down.
2:45 PM: Latest update, with no new information. Railway says it will keep posting at least every 30 minutes.

The incident is titled "Dashboard and API unavailable, builds paused" and lists builds in US West, EU West, Southeast Asia and US East as affected. Check the status page for the current state, since it'll be out of date by the time you read this.

What an agent does with a paused platform

When I'm the one deploying, an outage is annoying. I read the status page, sigh, and go do something else.

An agent doesn't sigh. It pushes a fix, asks for a deploy, gets an error, and tries again. Maybe it reads the error and decides its own code is broken, and starts "fixing" things that weren't wrong. If it's running overnight, you wake up to a long log of retries and nothing shipped.

That's not the agent's fault. It was handed one place to deploy, and that place is closed. There's no Plan B in its instructions, because there's no Plan B in the setup.

Why I keep a box of my own

This is the reason I built agentic-hosting. It's open source, and it turns a Linux server you own into a place your agents can deploy apps and databases by themselves, with limits you set.

It's one program, ah, that takes requests over an HTTP API. So the "second place to ship" is just a URL and a key your agent already knows how to use. A deploy from a git repo looks like this ($SVC is a service the agent created first):

BODY=$(jq -n --arg sha "$(git rev-parse HEAD)" '{
  source_type: "git",
  source_url: "https://github.com/you/app",
  source_ref: $sha }')

curl -s -X POST "$AH_URL/v1/services/$SVC/builds" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d "$BODY"

I'm not saying move everything off Railway today. I'm saying it's worth having somewhere your agents can still ship when your main platform can't. You can add one line to their instructions:

If the main platform's deploys are failing and its
status page shows an incident, deploy to $AH_URL
instead and tell me you did.

What it costs you

Running your own deploy target isn't free, and I'd be lying if I said it was.

You own the uptime. If your box goes down at 3 AM, there's no status page and no team working on it. There's you.
You do the upkeep. Updates, disk space, backups and TLS are your job. agentic-hosting handles a lot of the guardrails, but it's still a server.
One box is one box. A single server is also a single point of failure. The point is having two places that fail for different reasons, not one place that never fails.

For a lot of people, a managed platform is the right main choice. I think the mistake is having exactly one place your agents know how to ship.

Wrapping up

Railway's builds have been paused for most of today, and anyone whose agents deploy only there is waiting along with them. Outages happen everywhere. What you can control is whether your agents have a second place to go. agentic-hosting gives them one on a server you own, and the tradeoff is that keeping it up is on you.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, or start at the docs site.

I Give My AI Agent a Git Link and Get Back a Live App. Here's What It Does When the Build Breaks.

Dennison Bertram — Wed, 21 Oct 2026 14:15:53 +0000

Here's how I used to deploy a side project. Push the code. Open the hosting dashboard. Watch the build scroll by. See it go red. Squint at the error, fix one line, push again. Wait. Usually it works the second time.

Every step in that loop is something a coding agent can do, except one: watching the build. On most hosting tools the build output lives on a web page made for a person to look at. My agent can write the fix in ten seconds. It just can't see what broke.

This post walks through how agentic-hosting, an open-source tool that turns a Linux server into a place where AI agents can deploy apps on their own, closes that gap. Your agent hands the server a git link, reads the build output as it happens, fixes what broke, and comes back with a live URL. Every step is one HTTP request, and I'll show each one.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

The loop

agentic-hosting is a single program called ah that runs on your server. Agents talk to it over an HTTP API. In the examples below, $AH_URL is your server's address and $AH_KEY is the agent's API key.

The loop your agent runs looks like this:

Create a service, the server's name for one app.
Start a build from a git URL.
Stream the build output.
If it fails, read the end of the log.
Fix the code, push, and build again.
When it's running, check the URL.

Step 1: make a place for the app

A service needs an image when you create it. That's the packaged app Docker runs. For a git deploy there's no image yet, so send the placeholder "pending", which is what agentic-hosting's own command-line tool sends:

curl -s -X POST "$AH_URL/v1/services" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"web","image":"pending","port":3000}' \
  | jq '{id, status, url}'

Save the id as $SVC. The response already has the address the app will live at. If your server was started with a base domain like apps.example.com, that's https://web.apps.example.com. Without one, it's http://<service-id>.localhost, which only works on the server itself.

One thing that looks scary and isn't: creating a service always kicks off a deploy, and a deploy of an image called pending fails. So the service will show failed until the first build lands. The build replaces the image, so your agent can ignore that.

port is the port your app listens on. It defaults to 8000. I'll come back to it, because it's the most common reason a "running" app doesn't answer.

Step 2: hand it the git link

Now the build. agentic-hosting uses Nixpacks, an open-source tool that looks at a repo, works out what kind of app it is (a package.json means Node, a requirements.txt means Python, and so on), and builds an image without you writing a Dockerfile. That matters for an agent, because it's one less file it has to get right.

BODY=$(jq -n --arg sha "$(git rev-parse HEAD)" '{
  source_type: "git",
  source_url: "https://github.com/you/app",
  source_ref: $sha }')

curl -s -X POST "$AH_URL/v1/services/$SVC/builds" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d "$BODY"
# {"build_id":"9f2c...",
#  "image":"127.0.0.1:5000/ah/...",
#  "status":"pending"}

The server answers 202 right away and does the work in the background. Save build_id as $BUILD.

A few rules about the URL:

HTTPS only, and no username or token in it. In practice that means public repos for now.
Known hosts only: github.com, gitlab.com, bitbucket.org, and codeberg.org. This stops someone from pointing the server at a host that quietly resolves to an internal address.
source_ref can be a branch, a tag, or a commit SHA. It defaults to main.

I have my agent send the commit SHA. Then it knows exactly which code it's looking at when it reads the log, and a push from someone else in the meantime can't change what got built. The trade-off is that a SHA means a full clone instead of a quick shallow one.

Step 3: watch the build

This is the step most hosting tools keep on a web page. Here it's a plain-text stream:

curl -sN -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SVC/builds/$BUILD/logs?follow=true"

-N tells curl to print lines as they arrive. The stream starts from the top of the log, so it's fine to connect late, and it closes when the build and the deploy after it are done. Lines from ah itself start with [ah]. Everything else is the raw output from git, Nixpacks, and your app's install and build commands.

Two things to know. If the build goes quiet for a minute, say during a long install, the connection can drop. Reconnecting is safe because the stream replays from the start. And each build log is capped at 5 MB. Past that, the server keeps the last 500 lines, which is the part with the error anyway.

Step 4: read the failure

Here's a failure I see a lot from agents. It added a package to package.json and never updated package-lock.json. On its laptop that's fine. Nixpacks runs npm ci, which refuses to install when the two files disagree. The end of the log looks something like this (trimmed):

npm error `npm ci` can only install packages when
npm error your package.json and package-lock.json
npm error are in sync. Please update your lock file
npm error with `npm install` before continuing.
...
[ah] Build failed: nixpacks build: nixpacks build failed
[ah] BUILD FAILED: build worker failed (...)

The agent doesn't need to watch the stream to find this. Once the build is done, the same endpoint without follow returns the whole log, and the build's status says how it ended:

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SVC/builds/$BUILD" | jq -r .status
# failed

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SVC/builds/$BUILD/logs" \
  | tail -n 40

The tail matters more than it looks. A Node build can print thousands of lines, and the error is almost always near the bottom. Handing the model the last 40 lines instead of the whole log keeps it focused on what broke.

A status of succeeded means the image built and was deployed. failed covers everything else, including a build your agent cancelled.

Step 5: fix it and build again

The agent does what you'd do. It runs npm install, commits the updated lockfile, and pushes. Then it starts a new build with the new SHA. Same request as step 2. Every build gets its own ID and its own image, so the agent can compare the logs of the build that failed and the one that worked.

If the app was already live from an earlier build, a failed build doesn't touch it. The new image only replaces the running one after it builds cleanly. (If the new version then fails to start, the old one is already gone, which is one more reason to check the URL at the end.)

Step 6: check the URL

When the stream ends with [ah] Deploy succeeded, look at the service:

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SVC" \
  | jq '{status, url, last_error}'
# {"status": "running",
#  "url": "https://web.apps.example.com", ...}

Then have the agent actually request that URL. running means the container started. It doesn't mean the app answers.

The usual reason it doesn't is the port. The server sends traffic to the service's port, which is 8000 unless you set it, or to the value of a PORT environment variable if the service has one. It doesn't set PORT inside the container for you. So if the app listens on 3000 and nobody said so, the container runs fine and every request fails.

The fix doesn't need a new build. Set PORT (most frameworks read it, and the server uses it for routing too), then redeploy, which restarts the same image with the new settings:

curl -s -X POST "$AH_URL/v1/services/$SVC/env" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d '{"PORT":"3000"}'

curl -s -X POST -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SVC/redeploy"

Redeploy doesn't pull new code. For a code change, start a new build.

Things that trip agents up

One build at a time per agent. If your agent starts a second build while one is running, the second one fails right away with "a build is already running for this tenant" in its log. Wait for the first to finish.
Builds have time limits. 5 minutes to clone, 10 for the Nixpacks build, 5 to store the image, and 20 for the whole thing. Nixpacks runs with its cache turned off, so plan on every build installing dependencies again.
Cancelling. DELETE /v1/services/$SVC/builds/$BUILD answers {"status":"cancelled"}, but the build itself is then marked failed, with "Build cancelled by user" at the end of its log. Once a build has moved on to deploying, cancelling returns 409.
A full disk says so. If the server's disk is over 90% full, starting a build returns 503 with a Retry-After header. I wrote about that and the other limits in my last post.

What I tell my agent

If you write your own instructions for an agent that deploys this way, here's the short version:

- Create the service with image "pending" and the
  port your app listens on.
- Build from a pushed commit SHA, not a branch.
- Stream logs with ?follow=true. If the stream
  drops, reconnect; it replays from the start.
- On failure, read the last 40 lines of the log,
  fix the code, push, and start a new build.
- When the build succeeds, request the URL.
  If it doesn't answer, check the port.
- Wrong port or env: set env, then redeploy.
  Code change: new build.

Wrapping up

The deploy loop is simple: build, read the error, fix, build again. The only thing an agent was missing was the error. agentic-hosting gives it the build output as plain text, a status it can check, and a URL at the end, so the whole loop runs without anyone opening a dashboard.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, or start at the docs site.
Open an issue if your agent hits a build failure it can't read its way out of. I want to see the log.

My AI Agent Never Gets Tired, and Sometimes It's Wrong. Here's How My Server Copes.

Dennison Bertram — Mon, 19 Oct 2026 14:23:02 +0000

My coding agent doesn't get tired, and it doesn't get embarrassed. If a request fails, it sends it again. If its app crashes on startup, it redeploys and watches it crash again. A person would stop after the third try and go read the logs. An agent with a loop and an API key can keep going all night.

So when I built a server for agents to deploy to, I assumed the user would be tireless and sometimes wrong. I put the limits in the server itself, because I can't count on every agent to behave.

This post walks through four of those limits in agentic-hosting, an open-source tool that turns a Linux server into a place where AI agents can deploy apps and databases on their own. For each one, I'll show what your agent sees when it kicks in and the requests that get things moving again.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

Why an agent needs different limits

Most hosting tools assume a person is on the other end. A person clicks deploy once, sees the error, and goes to fix it. An agent has different habits. It retries anything that looks like it failed, and it can fire off a lot of requests in a few seconds. Those are good habits most of the time. They go wrong in four places: requests that get done twice, apps stuck in a crash loop, a disk that fills up, and too many requests at once.

Retries that don't do the work twice

Say the agent asks for a Postgres database. The server creates it, but the response never makes it back. Maybe the connection dropped, maybe a proxy in between gave up. From the agent's side the request failed, so it asks again, and now there are two databases. Database names don't have to be unique, and each agent can have three databases by default, so a couple of lost responses can use up its whole quota.

The fix is an idempotency key. It's a unique string the agent makes up and sends in a header (uuidgen below just prints a random ID). The server remembers each key it has seen along with the answer it gave. If the same key shows up again, the server sends back the saved answer instead of doing the work a second time.

IDEM=$(uuidgen)
BODY='{"name":"appdb","type":"postgres"}'

curl -s -X POST "$AH_URL/v1/databases" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $IDEM" \
  -d "$BODY"

Send the same request again within ten minutes, with the same key and body, and you get the first response back, with the same database ID, plus a header that says it was a replay:

curl -si -X POST "$AH_URL/v1/databases" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $IDEM" \
  -d "$BODY" | grep -i '^idempotency-replayed'
# Idempotency-Replayed: true

A few rules are worth knowing, because they decide whether a retry is safe:

Keys last 10 minutes. After that the server forgets them. It also keeps them only in memory, so restarting ah clears them.
The key, path, and body have to match. A key only counts for the same agent and the same URL. The server also stores a fingerprint of the request body with the key. Same key with a different body gets 409 and {"error":"idempotency key reused with different request body"}. Build the body once and reuse it, as above, instead of rebuilding the JSON on each try.
Only successes are saved. If the first request returned an error, a retry with the same key runs again. That way one temporary failure doesn't get stuck as the permanent answer.
A retry that arrives early waits. If the first request is still running, the second one waits for it and gets the same answer.
It covers POST requests. That's every create and action route. Deletes and edits aren't covered, and they don't need to be, because doing them twice leaves things the same as doing them once. Creating an API key is left out on purpose, since the secret should be shown only once.

Keys can be up to 128 characters. A UUID per intended action is the simplest choice. Make a new key when you mean to do something new, and reuse it only when you're retrying.

Crash loops that stop on their own

When an app crashes, Docker (the tool that runs each app in its own container) starts it again. That's the right call for a crash every few days. It's the wrong call for an app that crashes the moment it starts, because Docker will keep restarting it all night, and the agent watching it may keep redeploying it too.

ah checks running services every 30 seconds and counts restarts. A failed health check counts as a crash too. If a service crashes 5 times within 10 minutes, ah trips a circuit breaker. The name comes from the switch in your fuse box that cuts power when something's wrong. Here, ah stops the container, removes it, and refuses to start it again until someone deals with it.

Your agent sees it on the service itself (this uses jq to pick out the fields):

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SERVICE_ID" \
  | jq '{status, crash_count, circuit_open, last_error}'
# {
#   "status": "crashed",
#   "crash_count": 5,
#   "circuit_open": true,
#   "last_error": "container restarted 1 time(s) by ..."
# }

While the breaker is open, start, restart, and redeploy all return 409 with this message:

There's a catch. Because the container is gone, the logs are gone with it, and GET /v1/services/{id}/logs returns 409 with "service has no container". So the best time to read logs is before the breaker trips, while the status says crashed. After it trips, the clues left are last_error and the deployment history, which records every crash with its exit code:

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SERVICE_ID/deployments" \
  | jq -r '.[] | "\(.status)  \(.error_message)"'

Once the agent has a fix, it resets the breaker and deploys again:

curl -s -X POST -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SERVICE_ID/reset"
# {"status":"circuit breaker reset"}

curl -s -X POST -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SERVICE_ID/redeploy"

Reset leaves the service stopped with no container, so use redeploy, not start. Redeploy runs the same image (the packaged app that Docker runs) with the current environment variables, which is right when the fix was a missing variable. If the fix was in the code, reset first and then start a new build (turning the updated source code into a new image) with POST /v1/services/{id}/builds, because a build can't deploy while the breaker is open.

If nobody resets it, ah closes the breaker by itself after 30 minutes and leaves the service stopped. Nothing restarts the app automatically. If the same service trips again, the wait becomes 1 hour, and then 4 hours for every trip after that. That count doesn't go back down after a manual reset, so a service that keeps breaking gets treated with more suspicion over time.

A disk that says no before it's full

Agents build a lot. Every build leaves an image behind, databases need space, and a full disk breaks everything on the server at once, including the tools you'd use to clean it up.

So before every deploy, build, and new database, ah checks how full two folders are: /var/lib/ah, where it keeps its own data, and /var/lib/docker, where images and containers live. These thresholds are often called watermarks. At 80% used, ah writes a warning to its log and carries on. At 90%, it refuses the work.

What your agent sees depends on the request. Creating a service is accepted right away and deployed in the background, so the deploy fails later and the reason shows up on the service:

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SERVICE_ID" | jq -r .last_error
# /var/lib/docker: insufficient disk space at
# /var/lib/docker (91.4% used, threshold 90%)

Builds, new databases, restarts, and redeploys check the disk while the request is still open. Those come back as 503 with {"error":"insufficient disk space; try again later"} and a Retry-After: 10 header, so the agent knows to wait instead of guessing. (When this post first went up, they were a plain 500. That's fixed now.)

Until then, the health endpoint gives the agent a direct answer. It reports both folders, and its overall status turns to degraded when either one is over 90%:

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/system/health/detailed?fresh=true" \
  | jq '{status, disk, docker_disk}'
# {
#   "status": "degraded",
#   "disk": {"total_gb": 75, "free_gb": 41.2, ...},
#   "docker_disk": {..., "used_percent": 91.4}
# }

The 80% warning only reaches the server log, so an agent that wants an early heads-up should check used_percent itself before a big batch of builds and clean up old services first. The health result is cached for 30 seconds, and ?fresh=true cuts that to 10.

A speed limit for each agent

Each agent gets its own account on the server, which ah calls a tenant, with its own API key. Every tenant has a rate limit of 100 requests per second, with a burst of 200. That means it can send 200 requests in a quick burst, and after that it gets about 100 more each second. The whole server also has a shared limit of 500 per second, with a burst of 1,000, so many agents together can't swamp it either.

Every authenticated response tells the agent where it stands:

curl -si -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services" | grep -i '^x-ratelimit'
# X-Ratelimit-Limit: 100
# X-Ratelimit-Remaining: 187

Go over and the server answers 429 with {"error":"rate limit exceeded"} and a Retry-After header saying how many seconds to wait, between 1 and 60.

There's a second limit for slow requests, like following logs or creating a database. Each tenant can have 4 of those open at once. A fifth gets 429 with Retry-After: 5.

It helps to teach your agent the difference between 429 and 409. A 429 means "slow down and try the same thing again." A 409 means the request itself ran into something, like a full quota ("quota exceeded: maximum 3 databases reached") or an open circuit breaker. Waiting won't fix a 409, so the agent should read the error before it tries again.

What I tell my agent

If you write your own instructions for an agent that uses agentic-hosting, this is the short version I'd paste in:

- Send an Idempotency-Key on any POST you might retry.
  On retry, reuse the same key and the exact same body.
- On 429 or 503, wait Retry-After seconds, then retry.
- On 409, read the error before trying again.
- If circuit_open is true: read last_error and
  /deployments, fix the cause, POST /reset once,
  then POST /redeploy (or start a new build).
- Before a big batch of builds, check
  /v1/system/health/detailed for disk used_percent.

These limits don't make the agent any smarter. They keep one bad loop from taking down the server, and they leave a clear error behind for the agent to read.

Wrapping up

An agent that never stops is a great user until it's wrong. agentic-hosting answers with four limits: idempotency keys so retries don't double up, a circuit breaker for crash loops, a disk check that refuses new work at 90%, and a rate limit for each agent. Each one tells the agent what happened, so it can fix the cause instead of trying harder.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, or start at the docs site.
Open an issue if your agent finds a way to get stuck that these limits don't catch. I want to hear about it.

My AI Agent Deploys Code to My Server. Here's What Keeps It in a Box.

Dennison Bertram — Sat, 17 Oct 2026 14:21:16 +0000

My coding agent deploys apps to a server I own. A lot of the time it's shipping code it wrote ten minutes earlier, and I haven't read every line. Usually that's fine. The question I kept coming back to was what happens on the day it isn't fine: a bad dependency, a confused agent, or an app that starts poking at the machine it runs on.

My answer is a sandbox around every app the agent ships. I built it into agentic-hosting, an open-source tool that turns a Linux server into a place AI agents can deploy apps and databases on their own. This post explains in plain terms how that sandbox works, how to set it up on your server, and how to check for yourself that an app is really inside it.

🤖 Give this to your agent: point it at https://raw.githubusercontent.com/dennisonbertram/agentic-hosting/main/llms.txt and it can sign up and set things up from that one link.

Why a normal container isn't enough

Most apps today ship as containers. A container feels like its own small computer, with its own files and processes. It isn't one. Every container on a machine shares the same Linux kernel with the host and with every other container. The kernel is the core program that controls files, memory, the network, and everything else.

Programs ask the kernel for things through system calls, or syscalls. Opening a file is a syscall. So is sending network data or starting a process. In a normal container, those calls go straight to the host's real kernel. Linux has hundreds of them, and every so often someone finds a bug in one that lets a program break out of its container and reach the host. That's called a container escape.

When I write and deploy the code myself, I can live with that risk. When an agent writes and deploys code all day without me watching, I want another wall.

What gVisor does

gVisor is an open-source project from Google that adds that wall. It gives each container its own kernel, written in Go, that runs as an ordinary program on the host. gVisor calls this kernel the Sentry.

When the app makes a syscall, the Sentry handles it itself instead of passing it to the host kernel. When the app needs files, a separate helper process called the Gofer fetches them. The Sentry itself runs with tight limits on what it can ask the real kernel for. So if the app finds a bug, it's a bug in gVisor's kernel, and getting from there to the host takes a second break-in.

gVisor plugs into Docker as a runtime, which is the piece that actually starts containers. Docker's default runtime is called runc. gVisor's is called runsc. You use the same Docker commands with a different engine underneath.

There are costs, and gVisor's docs are upfront about them. Each syscall takes a longer path, so apps that make a lot of them, like heavy disk or network work, run slower. gVisor also doesn't implement every Linux syscall, so once in a while an app won't run unchanged (see the compatibility notes). For the web apps and APIs I have agents deploy, I'll take that trade.

Setting up gVisor for agentic-hosting

agentic-hosting is a single Go program called ah that runs on your server and takes deploy requests from agents over an HTTP API. The quickstart covers the full install. Here's the gVisor part, on Ubuntu.

Install runsc from gVisor's package repository:

KEYRING=/usr/share/keyrings/gvisor-archive-keyring.gpg
ARCH=$(dpkg --print-architecture)
REPO=https://storage.googleapis.com/gvisor/releases

curl -fsSL https://gvisor.dev/archive.key \
  | sudo gpg --dearmor -o "$KEYRING"
echo "deb [arch=$ARCH signed-by=$KEYRING] $REPO release main" \
  | sudo tee /etc/apt/sources.list.d/gvisor.list
sudo apt-get update && sudo apt-get install -y runsc

Then register it with Docker under the name runsc:

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

The runtimes block is the part that matters. ah asks Docker for a runtime named exactly runsc. The address pool line gives Docker room for a lot of small networks, which ah needs because it creates a private network for each agent and another one for each app.

Check that it worked:

docker info 2>/dev/null | grep runsc
docker run --rm --runtime=runsc hello-world

The first command should show runsc among Docker's runtimes. The second runs a test container inside gVisor.

That's all the gVisor setup there is. ah checks for it every time it starts. In production, if Docker doesn't list runsc, ah exits with this error:

In dev mode (--dev, for trying it on a laptop) it logs a warning instead, but app containers still won't start, because ah always asks for runsc. There's no setting that turns the sandbox off.

What happens when an agent deploys

From the agent's side, the sandbox doesn't show up at all. The agent registers, gets an API key, and asks for a service:

curl -s -X POST "$AH_URL/v1/services" \
  -H "Authorization: Bearer $AH_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "web",
    "image": "your-dockerhub-user/your-app:1.0",
    "port": 3000
  }'

That request takes a name, an image, a port, and optional environment variables. Nothing else. There's no field for the runtime, extra privileges, or more memory, so the agent can't ask for a looser box even if it wanted one.

Behind that call, ah starts the container with these settings. They're hardcoded in internal/docker/client.go, so you can read them yourself.

Runtime runsc. The app runs on gVisor.
All capabilities dropped (CapDrop: ALL). Linux splits root's powers into pieces called capabilities, like changing file ownership or reconfiguring the network. The app gets none of them.
No new privileges (no-new-privileges). A program inside can't gain more power later, for example through sudo or another setuid program.
Read-only root filesystem (ReadonlyRootfs). The app can't change its own files. It gets small in-memory scratch folders instead: /tmp (64 MB) and /run, /var/run, and /var/tmp (16 MB each). They're all mounted noexec, so nothing written there can run as a program.
256 processes max (PidsLimit). A program that keeps spawning copies of itself hits a wall.
Memory and CPU caps from the agent's quota, 2048 MB and 2 CPUs by default. The memory-plus-swap limit equals the memory limit, so the app gets no swap.
A private network. Each agent's apps sit on their own Docker network, marked internal, with app-to-app traffic turned off. Web traffic comes in through Traefik, the proxy that routes requests, over a separate small network for each app. None of these networks has a route to the internet.

ah also sets the label traefik.enable=false on every app, so an image can't use its own labels to grab another app's traffic. The Postgres and Redis containers it creates for agents run under runsc too.

One practical effect: images that write outside those scratch folders, or that expect to start as root and switch users, will crash here. If an agent's app dies with "Read-only file system" in its logs, that's the reason. The agent can read those logs itself at GET /v1/services/{id}/logs and fix the app.

How to check an app is really sandboxed

I don't like trusting a list of settings in a blog post, including mine. Here's how to check on your own server.

First, ask ah. The detailed health endpoint reports whether gVisor is installed and which version:

curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/system/health/detailed"
# {
#   "status": "ok",
#   "docker": {"available": true, ...},
#   "gvisor": {"available": true, "version": "..."},
#   ...
# }

Then look at the container. Get the service's container_id from the API and ask Docker how it was started (this uses jq to pull out the field):

CID=$(curl -s -H "Authorization: Bearer $AH_KEY" \
  "$AH_URL/v1/services/$SERVICE_ID" | jq -r .container_id)

docker inspect --format '{{json .HostConfig}}' "$CID" \
  | jq '{Runtime, ReadonlyRootfs, CapDrop, PidsLimit}'
# {
#   "Runtime": "runsc",
#   "ReadonlyRootfs": true,
#   "CapDrop": [
#     "ALL"
#   ],
#   "PidsLimit": 256
# }

On the host, every gVisor sandbox shows up as its own process:

ps -eo pid,args | grep '[r]unsc-sandbox'

You can also look from inside. If the image has dmesg and touch:

docker exec "$CID" dmesg
# [    0.000000] Starting gVisor...

docker exec "$CID" touch /test
# ... Read-only file system

Under gVisor, dmesg prints gVisor's own made-up boot log instead of the host's kernel log. Some of the lines are jokes, like "Preparing for the zombie uprising...". gVisor's docs point out that this output is easy to fake, so use it as a quick sanity check and trust docker inspect for the real answer.

What the sandbox doesn't cover

gVisor protects the server from the apps. It doesn't solve everything.

Builds are a separate step. When an agent deploys from git, Nixpacks (the tool that turns source code into a container image) builds it with Docker's regular builder, not inside gVisor. The app that comes out of the build runs sandboxed. ah limits where the source can come from: HTTPS URLs on github.com, gitlab.com, bitbucket.org, sr.ht, or codeberg.org.

The API key is the other gap. Anyone holding an agent's key can do anything that agent can, including deploying, deleting, and reading its secrets. They can't reach other agents' apps or register new agents. I give each agent its own key with POST /v1/auth/keys and revoke it when I'm done.

And gVisor is one more wall, not a guarantee. Keep the host patched.

Wrapping up

Every app an agent deploys through agentic-hosting runs inside gVisor, with no extra privileges, a read-only filesystem, capped resources, and a network that only lets web traffic in. The agent can't turn any of that off, and you can check the main settings yourself with one docker inspect command.

Star agentic-hosting on GitHub so more people find it.
Give it to your agent: llms.txt to sign up and set up, or the agent skill for daily use.
Try the quickstart, read the security model, or start at the docs site.
Open an issue if you find a way out of the box. I want to hear about it.