Agent-First HTTP v0.5.0: One Command to a Browser Host, in Any Runtime

June 03, 2026 by Agent-First Kit Contributors

v0.5.0 adds `afhttp container`: bring up the browser host in one command — Docker, Podman, or Apple Container — from a recipe embedded in the binary, no source tree required.

afhttp has two halves. The driver (afhttp fetch/cdp/upload/…) is a thin client that runs wherever the agent is. The host is the heavy half: a real browser with a CDP endpoint, which must run in a container — the container is the isolation boundary. Until now, bringing that host up meant cloning the repo and running docker build against the full source tree. A user who installed afhttp from Homebrew had no source tree, and therefore no easy path to a host.

v0.5.0 closes that gap with a new top-level command: afhttp container.

One command, with the recipe baked into the binary

afhttp container install stands up a host in a single step. The image recipe is embedded in the binary, written to a local cache dir, and built there — no repo to clone, no registry image to pull or trust. The image installs the afhttp release that exactly matches your binary’s version, downloaded for the image’s architecture. status, logs, and uninstall round out the lifecycle.

status is the part that matters for adoption: it reports whether the host is running and prints the ready-to-run driver command, bearer token included, so the hop from “host is up” to “agent is fetching” is copy-paste.

Whatever container runtime you already have

The same command runs under Docker, Podman, or Apple container, auto-detected (override with --runtime). Podman users get a rootless, daemonless host with no extra steps. macOS users get Apple’s native container runtime — which has no compose — so afhttp container is simply the way to run a host there.

Bundle the browser you need

Chromium is always present; the optional backends come in by flag. --with camoufox adds the stealth Firefox fork, --with kasmvnc adds the display a human uses to take over for a login or captcha, and --with lightpanda / fingerprint-chromium / chrome-headless-shell round out the set — each opt-in, so the default image stays lean. Host flags like --browser and --takeover pass straight through to the running host.

One Dockerfile, two ways in

Under the hood there is a single Dockerfile with two source stages, chosen by a build-arg. By default it selects the downloader stage, which fetches the prebuilt release binary — BuildKit skips the unused compile stage, so the image stays a slim Debian base with no Rust toolchain and the first install is near instant. Pass --from-source and it selects the builder stage instead, compiling from a checkout for development or an unreleased version. Same file, same runtime-agnostic recipe, both paths.

Native arm64, so Apple Silicon runs natively

Supporting all of this, the release now ships an aarch64-unknown-linux-gnu binary. Apple container (which runs linux/arm64) and arm64 Docker no longer fall back to emulation — the host image gets a native binary for its architecture.

Where this fits: the host stopped being a chore

An agent-first tool should be trivial to stand up. The driver was always a thin client; now the host is a one-liner too. Clone-build-run became afhttp container install, and status hands you the exact command to point a driver at it.