Add a database

Wire MongoDB, Postgres, Redis, or MySQL to your server once. Every sandbox you build will inherit the connection.

Before you begin

You'll need either:

• A managed database you've already provisioned (MongoDB Atlas, Neon, Supabase, RDS, Redis Cloud, etc.), or
• A self-hosted database running on your server or somewhere your server can reach.

agentry doesn't run databases for you. We just wire your sandboxes to whichever one you have.

Don't have one yet? Get a free database walks through Supabase, Neon, MongoDB Atlas, and Upstash step by step.

MongoDB

From the CLI

agentry service bind mongodb

agentry prompts for the connection URL:

MongoDB connection URL (mongodb://...): mongodb://user:pass@cluster.mongodb.net/

Done. Verify with agentry service list:

SERVICE   BOUND     ENV VARS
mongodb   yes       MONGODB_URL

From the dashboard

app.agentry.run/clusters → your server → Services → Add binding → MongoDB → paste connection URL.

What sandboxes see

Every new sandbox in this cluster starts with the URL you provided, stamped as MONGODB_URL:

MONGODB_URL=mongodb://<your-creds>@<host>/<path-you-supplied>

That's the literal URL — agentry doesn't rewrite it. Whatever database the URL points at is what every sandbox sees. There is no automatic per-sandbox isolation.

Telling the agent

Mention the binding when you prompt so the agent reads the env var instead of reaching for an in-memory fake:

Use agentry to build me a CRM. The MongoDB at MONGODB_URL is bound to this server — use it for the data layer.

If you want each app you build to land in its own database (so prototypes don't trample each other), say so explicitly:

Use database crm_v1 inside the bound MongoDB cluster. Override the path in MONGODB_URL or pass the name to client.db().

The agent will do the right thing once told. The bind itself just hands over the connection — anything beyond is the AI's call.

Your code

The AI's generated code reads MONGODB_URL directly:

import { MongoClient } from "mongodb";
const client = new MongoClient(process.env.MONGODB_URL);
await client.connect();

No config files, no glue.

Postgres

agentry service bind postgres

Prompts for postgres://user:pass@host:5432/dbname. Stamps both DATABASE_URL and POSTGRES_URL (the two conventional names) into every sandbox's env. Use whichever your code expects — they're identical.

Keeping prototypes from colliding

The bind hands over one URL — every sandbox sees the same connection and, by default, the same public schema. If you don't want two prototypes writing to the same tables, ask the agent to namespace its work:

Create all tables inside a schema named quill and set search_path accordingly.

Most ORMs (Drizzle, Prisma, Kysely) accept a schema either via env or as a ?schema= query param on the URL.

Migrations

Migrations run inside the sandbox just like they do locally — the agent calls drizzle-kit push, prisma migrate dev, or whatever your tool uses against the bound URL. There's no agentry-managed migration step.

If you've namespaced into a schema, your migration tool needs the same hint — set search_path in the URL or in your tool's config so the migration writes there and not into public.

Redis

agentry service bind redis

Prompts for redis://.... Stamps REDIS_URL. As with the others, every sandbox sees the same Redis. If you care about keys not colliding between prototypes, tell the agent to prefix them — e.g. quill: — explicitly.

MySQL

agentry service bind mysql

Prompts for mysql://user:pass@host:3306/dbname. Stamps DATABASE_URL and MYSQL_URL. Same one-URL-for-all model as the others.

Bound but the agent isn't using it

Three failure modes:

1. You bound after the sandbox was created. New env vars only flow into new sandboxes. Either create a fresh one or set the var on the existing sandbox: agentry env set MONGODB_URL --sandbox <id> (omit the value to be prompted with hidden input).
2. The agent wrote stub code before reading bindings. Tell it to refactor: "There's a real MongoDB bound to this server at MONGODB_URL. Replace the in-memory store with that."
3. The agent picked a different env var name. Some libraries default to DB_URL or MONGO_URI. Tell the agent the exact var name: "Read the URL from MONGODB_URL."

Switching databases between dev and prod

By default the deployed container reads the same MONGODB_URL as the sandbox — same connection, same database. If you want production to point at a different cluster:

• Override the var at deploy time: dashboard → deployment → Env → Override MONGODB_URL.
• Or use a different bound provider for prod and rebind before deploy.

See Environment variables.

Unbinding

agentry service unbind mongodb

The binding goes away. Existing sandboxes keep the env var they were created with; new sandboxes won't have it.

Next

• Add an AI provider — wire Anthropic / OpenAI / OpenRouter for server-side AI in deployed apps.
• Bindings overview — the model behind all bindings.
• Ship an app — push it to production.