DEV Community: Dennison Bertram

Why FreePi runs on the Pi harness (and what the new Harness Leaderboard shows)

Dennison Bertram — Fri, 06 Nov 2026 07:21:42 +0000

The model gets all the attention. The harness around it — prompts, tools, context management, when to stop — usually decides whether a coding agent actually ships work.

A new Harness Leaderboard from Joel Niklaus makes that measurable: same open models, same provider, same reasoning effort, same tasks. Only the coding-agent harness changes.

What FreePi is

FreePi is a free AI coding agent in your terminal. Ads pay for inference. Under the hood it runs Mario Zechner's Pi harness — the same open agent loop the leaderboard just put under a microscope.

What the board measured

Joel ran 28,849 trials across nine harnesses on GLM-5.3-Flash, DeepSeek-V4.1-Flash, and Flint, on Terminal-Bench 2.1 and DeepSWE (~$4,746 of inference). Headline score is resolve rate; cost is measured outside the harness.

Where Pi landed

Averaged over the three models:

Pi — 49.4% resolve at $0.29 per solved task
mini-swe-agent — 51.4% at $0.53 (Pi is statistically tied, ~45% cheaper)
OpenCode — $3.35 per solved task (11.7× Pi)

Pi sits in the top cluster and is the cheap strong option. The best harness still depends on the model, but the cost gap is hard to ignore.

Source announcement: Joel's post.

Why FreePi ships on Pi

We didn't invent a new agent loop. We ship Pi with free models, a GitHub sign-in, and no card required:

npx free-pi-cli@latest

When an independent board says the harness is near the top and thrifty, that's the product story: best harness we know how to ship, batteries included.

Wrapping up

Harness choice moves quality and cost as much as model choice. Pi cleared that bar. FreePi puts that harness in your terminal for free.

Leaderboard: huggingface.co/spaces/joelniklaus/harness-leaderboard
FreePi: www.freepi.ai
Credit: @pidotdev / Mario Zechner for Pi; @joelniklaus for the board

How Fusion works: DeepSeek V4 Pro plans, V4 Flash writes the code

Dennison Bertram — Thu, 05 Nov 2026 16:23:16 +0000

Big models write better plans. Small models are cheaper and fast enough to type the code. I wanted both in one session without switching models by hand.

That's Fusion. It's one entry in FreePi, a free AI coding agent for the terminal. This post explains how it splits a task between DeepSeek V4 Pro and DeepSeek V4 Flash, how the switch happens, and when it's worth turning on. Everything here comes from the code that ships in the CLI today.

Try it: run npx free-pi-cli@latest in a terminal, then pick Fusion in /model.

Give this to your agent: freepi.ai/llms.txt

The short version

Every message you send goes through three phases:

Explore. DeepSeek V4 Flash reads your code with read-only tools. It makes no edits.
Plan. DeepSeek V4 Pro gets one request. It writes a step-by-step plan into the agent's todo list. It can't edit files.
Build. Flash takes over again. It works through the todo list, edits files and runs tests.

So Pro answers one request per message. Flash handles every other request, including all the follow-ups after tool calls.

How you turn it on

FreePi runs the pi coding agent. Type /model and Fusion is the first entry in the list. Pick it, and the footer shows Fusion plus the model that answered the last request.

Fusion isn't the default. A new session starts on the default model the server lists first, so you pick Fusion yourself.

Fusion is a router, not a model

pi has a feature called virtual models. A virtual model shows up in /model like any other model. Before every request, it runs a route function that picks a real model to send that request to.

Fusion is a virtual model. When you pick it, nothing new runs on the server. Each request still goes out as a normal request to deepseek-v4-pro or deepseek-v4-flash.

The router keeps one piece of state per session branch, the current phase. Here's the core of it, trimmed, with one helper renamed:

switch (request.reason) {
  case "user":
    // a new message from you: start over
    return route(executor, "explore");
  case "continuation":
    // after the planner's one reply, it's all build
    if (phase !== "explore")
      return route(executor, "build");
    if (editedThisTurn(messages))
      return route(executor, "build");
    // the executor asked for a plan
    return planRequested(messages)
      ? route(planner, "plan")
      : route(executor, "explore");
}

In pi, a "continuation" is any request in the agent loop that isn't a fresh message from you, like the request after a tool result.

Asking for a plan is a tool call

How does Flash say "I've read enough, give me a plan"? It calls a tool named fusion_plan.

The tool takes one argument, a summary of what Flash found and what the task needs. It only exists while Fusion is selected. Its result is the planner's brief:

You are now the planning model. Write a concrete
step-by-step plan (files, exact changes, tests to add
and run) and record it with the todo tool, one item
per step. Do not edit files or run commands. Another
model will carry out the plan.

The router sees that fusion_plan result in the transcript and sends the next request to Pro. Pro sees the whole conversation, including the files Flash already read. Then it writes the plan with the todo tool. You can see that list any time with /todos.

Guardrails, because prompts alone didn't work

Fusion's instructions tell Flash to explore first and call fusion_plan before any edit. A comment in the code explains why that wasn't enough. In a live run, DeepSeek ignored the instruction and edited files directly.

So Fusion now blocks edits in code. While Fusion is selected, the CLI checks every edit and write call:

Before a successful fusion_plan call since your last message, the edit is blocked. The model gets back "call fusion_plan first".
If the planner tries to edit, it's blocked too. The planner records the plan, and the executor makes the changes.

A few more cases are handled:

The planner stops early. If Pro replies with text and no tool calls, the turn would end with nothing built. Fusion adds one hidden message, "The plan is recorded. Carry out the unfinished todo items now", so Flash picks up the work. This happens at most once per plan.
The planner request fails. The retry goes to Flash in build mode instead of trying Pro again.
A model is missing. If either model can't be found, every request goes to the default model instead of failing.

What stays with Flash

Plain questions skip the planner. Fusion's instructions tell Flash to answer a message that needs no file changes directly, with no fusion_plan call.

Background work also goes to Flash. A compaction summary, for example, is a request outside the agent loop, and the router always sends those to the executor.

The server picks the pair

The model ids aren't hardcoded forever. On startup the CLI calls /client-version, and the server can send a fusion field with a planner and an executor. Today it says:

{
  "planner": "deepseek-v4-pro",
  "executor": "deepseek-v4-flash"
}

The CLI uses that pair only if both models are in the catalog it just loaded. Otherwise it falls back to its built-in pair. So I can swap the planner on the server without shipping a new CLI.

When to use it

Fusion fits tasks where a bad plan costs you more than a slow start:

Changes that touch several files.
A feature plus the tests for it.
Refactors where the order of steps matters.

For a one-line fix, plain DeepSeek V4 Flash is usually the better pick. Under Fusion, even a tiny edit waits for exploration and a planning request.

Trade-offs

The plan request costs more. Pro is the more expensive model, so its request uses more of your daily allowance than a Flash request. The /model picker shows how fast each model uses it.
Prompt caches don't carry over. pi's docs say switching models loses the prompt cache. Each switch between Flash and Pro sends the context without it.
Shell commands aren't blocked. Exploration needs bash, so Fusion leaves it alone. A shell command can still change files before the plan exists. Keep your work in git.
One plan per message. Pro writes the plan once. If the build goes sideways, send a new message and Fusion starts over from explore.

Wrapping up

Fusion is a small router on top of pi. Flash explores, Pro writes one plan into the todo list, and Flash builds it. Edits stay blocked until the plan exists, and failures fall back to Flash instead of stalling. Use it for multi-file work, and stay on Flash for quick fixes.

Try it free with npx free-pi-cli@latest, pick Fusion in /model, and read more at www.freepi.ai.

Doing authorized security work in the terminal with free abliterated models

Dennison Bertram — Tue, 03 Nov 2026 15:01:37 +0000

You paste a stack trace from your own app and ask how the bug could be exploited, so you can fix it properly. The model says no.

I hit this a lot. Most coding models get nervous around anything that looks like an attack, even when the system is yours.

This post shows how I do that kind of work in the terminal with FreePi, a free AI coding agent. It covers what abliterated models are, how to pick one, and two real workflows: auditing your own repo and analyzing software you're allowed to take apart. Everything here is for authorized work only.

Try it: run npx free-pi-cli@latest in a terminal. No card, no API key.

Give this to your agent: freepi.ai/llms.txt

The ground rules first

This only covers work you're allowed to do:

Systems and code you own.
Employer or client systems where you have written permission to test.
Bug bounty targets, inside the program's stated scope.
CTFs and lab boxes built to be attacked.
Software you own or may lawfully analyze.

A different model doesn't change what you're allowed to do. Laws like the US Computer Fraud and Abuse Act still apply to you. If you're not sure you're authorized, find out before you start.

What "abliterated" means

An abliterated model is an open-weight model with its refusal behavior removed. It will help with the lawful parts of security work that general models often decline, like writing a proof of concept for a bug in your own handler.

In FreePi I call these abliterated models for defense. They're opt-in. You only get one if you pick it.

They are not smarter. They just refuse less. You still check everything they say.

Setup

You need Node.js 22.19 or newer. Then:

npx free-pi-cli@latest

You may start as a guest. The defense models need a GitHub sign-in, though. The server refuses them for guest sessions. Type /login to sign in with GitHub. If you pick a defense model as a guest, it opens the sign-in for you.

Run it from the project directory you want to work in. The agent reads, searches and edits files there.

Pick a model for defense

Inside the agent, type:

/model

The picker is built from the server's model list when the CLI starts. The abliterated models for defense sit near the top, labeled free-pi-defense. Today that list is:

Abliterated Large Flash
Abliterated Large V2
DeepSeek V4.1 Flash Abliterated
Qwen 3.6 Plus Uncensored
Gemma 4 Uncensored
GLM 4.7 Flash Heretic
Uncensored 1.2

The list can change without a new CLI release. Whatever you see in /model is current.

My habit: start on the default model. Switch to a defense model only when the general one refuses the lawful part of the job. Then switch back.

Workflow 1: audit a repo you own

FreePi bundles a security audit skill, based on Cloudflare's open-source security-audit skill. A skill is a set of instructions the agent loads for one kind of job. You can ask for it in plain words, or force it by name:

/skill:freepi-security-audit security audit this codebase

It works in two modes.

Guidance mode is for a focused question, like "is this upload handler safe?" It uses the relevant parts of the method and writes no report files.

Full audit mode runs when you ask for a full audit, a pen test of the codebase, or a report. It works in phases: map the architecture and trust boundaries, hunt for weaknesses, try to disprove each candidate, then write the results.

A full run writes these files:

architecture.md and coverage-ledger.json
findings.json, with each record marked confirmed, needs_validation or rejected
REPORT.md, FINDINGS-DETAIL.md and NEEDS-VALIDATION.md

By default they go outside your repo, in ~/security-audit-skill/<repo-name>/run-<N>. The skill is told never to edit your source.

Two things to know:

It runs as one agent. The same agent that finds an issue also tries to disprove it. So you are the second reviewer. Follow each confirmed finding into the code yourself.
It validates by reading code. Before it runs anything from the target, it is told to ask you and show the exact command.

I find it helps to state scope at the top of the session:

This is my own repo. I own the code and the
staging server. Review src/api for auth bugs.
Read only. Ask before running any command.

Workflow 2: look inside software you may analyze

Sometimes the question is about a binary, not source. Say a CLI tool you're licensed to use, or an Electron app you shipped years ago and lost the source for.

Type:

/reverse-engineer-anything

This loads REA (Reverse Engineer Anything) for the current session only. It gives the agent reverse-engineering tools for native binaries, JS and Electron apps, APKs, .NET assemblies and websites.

A few practical notes:

The first run downloads the tools, so it can take a minute.
It needs Node 22.19+, 24.11+ or 26+. If your Node is older, it tells you.
Deep native analysis needs your own Hopper, Ghidra or IDA install.

Then ask in plain words. "List the modules this Go binary was built from, with versions." Or "show me this Electron app's fuses and IPC handlers."

Keep it safe on your machine

The agent has real tools: read, write, edit, bash, grep, find and ls. In a normal session FreePi has no OS sandbox. bash runs on your machine.

So:

Work in a container or a throwaway VM when you test anything risky.
Never point it at production. Use a local or staging copy.
Keep real credentials out of that environment.
Keep your work under version control.
Press Esc to interrupt the agent if it heads somewhere you didn't ask for.

And reproduce every finding yourself before you report it. A model can be confidently wrong, abliterated or not.

Wrapping up

Abliterated models for defense won't do your security work for you. They stop the refusals that get in the way of lawful work on your own systems. Pair one with the audit skill for code, and with /reverse-engineer-anything for binaries. Set your scope, work in a sandbox you control, and check every result.

Try it free with npx free-pi-cli@latest, and read more at www.freepi.ai.

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.

⭐ If this is useful, a star on GitHub helps other people find 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.

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.

⭐ If this is useful, a star on GitHub helps other people find 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.

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.

⭐ If this is useful, a star on GitHub helps other people find 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.

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.

⭐ If this is useful, a star on GitHub helps other people find 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.

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.

⭐ If this is useful, a star on GitHub helps other people find 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.

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.

⭐ If this is useful, a star on GitHub helps other people find 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.

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.