Skip to content

Welcome

agentry is a way to build, ship, and run real apps with an AI agent — on hardware you control.

You bring three things:

  1. Your harness — the agentic tool that drives the work. Claude Code, Cursor, Roo Code, Continue.dev, Hermes, OpenClaw, or anything that speaks MCP. The harness is the thing on your screen reading + writing code.
  2. Your AI — the model that powers the harness. Claude, GPT, an open-weights model, whatever you have an API key for.
  3. Your server — a Linux machine you own. A laptop, a Hetzner box, an EC2 instance, a bare-metal server in a closet. Anything that runs Docker.

agentry sits between them and runs the apps your AI builds on your server. Real apps, with real URLs, that real users can hit. Code and data stay on your machine the whole time.

What you can build

The sandbox is opinionated for shipping web apps end-to-end — scaffold, dev server, deploy — without you having to wire each piece. But it's also a generic Linux sandbox: a clean room your AI can work in, isolated from your laptop.

Three ways people use it:

  • As an app builder. Prompt the agent and a real app shows up — landing pages, internal tools, AI assistants over your data, dashboards. The sandbox handles deps, ports, and the deploy path so the AI doesn't have to negotiate any of it.
  • As an automation runtime. Ask for a scheduled job or a webhook handler and you get a long-running app that does work while you sleep — cron schedules, Stripe/GitHub/Slack webhooks, a built-in run history with payloads, Run-now, and Replay. See Automations.
  • As a generic AI sandbox. Point any MCP harness — Claude Code, Cursor, Hermes, OpenClaw, … — at a sandbox and use it for anything you'd want a clean machine for: exploring a dataset, running a tool you don't want on your laptop, wiring up another MCP server inside it, prototyping anything ephemeral.

What you cannot do (yet): GPU workloads in the sandbox itself, native mobile builds, anything that needs a multi-node cluster. Most server-side work is fair game.

How the docs are organized

Use the right page for the job

The docs split four ways. Each one solves a different problem.

  • Get started — tutorials. Read these in order if it's your first time. End state: a live app on your server in under 10 minutes.
  • Guides — how-to recipes. Pick the one matching the thing you're trying to do (wire up Claude Code, bind MongoDB, deploy a new version).
  • Reference — every CLI command, every MCP tool, every config knob. The lookup surface, not a tutorial.
  • Troubleshooting — when something breaks. Real error strings, real fixes.

What's not in these docs

agentry is the consumer-facing tool. Enterprise needs — stronger tenant isolation, compliance signoffs, SLAs, dedicated infrastructure — are out of scope for the docs here.

Conventions

  • Code blocks you can copy verbatim are unannotated.
  • Code blocks with placeholders look like <sandbox-id> or <your-cluster>. Replace those parts.
  • $ prefix means a shell command. # prefix means it runs as root.
  • Boxes like the one above call out the why. They're skippable if you're in a hurry.

Ready? Quick start →

agentry — run AI-built apps on your own hardware.