How bindings work

A binding wires a service to your server once. Every sandbox you create on that server gets the connection details in its env. Skip the section entirely if you don't need any services.

The flow

You: agentry service bind mongodb  (paste your connection URL)
        ↓
agentry: stores the URL on this server
        ↓
Next sandbox you create automatically gets:
        ↓
  MONGODB_URL=mongodb://<the-exact-url-you-pasted>
  in its env
        ↓
Your AI agent's code reads MONGODB_URL — done

Three things matter:

1. Server-scoped. The bind lives on a specific server. Bindings don't auto-replicate across servers; you bind separately on each one.
2. Inherited automatically. Sandboxes created after the bind get the env. Sandboxes created before don't — see retrofit below.
3. The URL is used verbatim — no automatic isolation. agentry stamps the exact connection string you supplied into every sandbox. Every sandbox (and the deployment built from it) points at the same database. If you want prototypes not to collide, ask the agent to namespace — a Postgres schema, a Mongo database name, a Redis key prefix. See Add a database.

What gets bound

Three categories:

Category	Examples	What you get
Databases	mongodb, postgres, redis, mysql	Your connection URL in env
AI providers	anthropic, openai, openrouter, groq	API key in env (e.g. ANTHROPIC_API_KEY)
Object storage	s3	Bucket + access creds in env
Vector stores	pinecone, weaviate	Endpoint + key in env
Email	sendgrid, smtp	API key + sender details
Custom	anything you define	You pick the env var names

In every case agentry stores the values you supply and stamps them, unchanged, into each new sandbox's env. Don't have a database yet? See Get a free database. See the services list for everything available.

Binding from the CLI

The fastest way:

agentry service bind <service-name>

agentry prompts for whatever credentials it needs (API key, connection string, etc.), then confirms the binding.

Examples:

agentry service bind mongodb       # prompts for connection URL
agentry service bind anthropic     # prompts for API key
agentry service bind openrouter    # prompts for API key

Binding from the dashboard

app.agentry.run/clusters → click your server → Services tab → Add binding.

Same options as the CLI. The dashboard is friendlier for first-time setup; the CLI is friendlier for scripting / automation.

What the AI sees

The bound env appears in every new sandbox under the standard variable names code libraries already expect:

Bound service	Env var(s) in sandbox
mongodb	MONGODB_URL
postgres	DATABASE_URL, POSTGRES_URL
redis	REDIS_URL
anthropic	ANTHROPIC_API_KEY
openai	OPENAI_API_KEY
openrouter	OPENROUTER_API_KEY
s3	AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, S3_BUCKET
pinecone	PINECONE_API_KEY, PINECONE_INDEX

This means: your AI's generated code reads process.env.MONGODB_URL and finds it already there. No config file to copy. No glue code to write.

sandbox_create response shows bindings

When the AI calls sandbox_create, the response includes a bindings array listing what's wired into that sandbox. A well-prompted agent reads this first and skips redundant setup (no mongodb-memory-server, no fake stubs).

If you see your agent creating a local fake for something that should be bound, the binding wasn't there at sandbox-create time. See retrofit.

Retrofit

If you bound a service after creating a sandbox, the env var won't be there. Two options:

Option A — easier — create a fresh sandbox:

In your harness chat:

Create a new sandbox and re-scaffold the project. The old sandbox is missing the MongoDB binding.

Option B — keep the sandbox, set the env manually:

agentry env set --sandbox <sandbox-id> MONGODB_URL <connection-url>

The variable becomes available immediately to new processes started in the sandbox. Existing processes need a restart.

Removing a binding

agentry service unbind <service-name>

Or in the dashboard, click the binding → Remove. New sandboxes won't inherit it; existing sandboxes keep their already-stamped env.

Bindings + deployments

When you deploy, the bound env carries through to the production container — your deployed app reads the same MONGODB_URL it used in dev. The connection points at the same database the sandbox was using.

Same connection in dev and prod

The deployment inherits the exact bound URL the sandbox used, so production points at the same database as your prototype. Sometimes that's what you want. If not, override the var at deploy time — see Environment variables.

Next

• Add a database — Mongo or Postgres in three minutes.
• Get a free database — Supabase, Neon, Atlas, Upstash — step by step.
• Add an AI provider — OpenRouter / Anthropic / OpenAI for apps that need server-side AI.
• Add a custom service — anything that fits the env-var-as-config model.