Blog
Agent-native backend

Published Updated

Arag and Shouryamaan

How AI Coding Agents Provision Databases, Auth, Storage, and Hosting

Read as Markdown

An AI coding agent can provision a Cohesivity backend by creating one project tenant, reading the live contract for each required service, provisioning resources one at a time, and verifying the returned endpoints. The agent should reuse an existing .cohesivity file and keep both Cohesivity credentials out of browser code.

This walkthrough covers the sequence rather than freezing every resource body into an article. The offering page is the source of truth when an agent runs the task.

Start with the application's requirements

List the state and external effects the application needs:

  • relational data may require postgres;
  • Google sign-in may require social-login;
  • uploads may require object-storage;
  • a public server may require railway-hosting or cloudflare-workers;
  • asynchronous email may require inbox;
  • live fan-out may require realtime.

Do not provision a vector database because the application contains an AI feature. The Postgres and vector database guide explains when semantic retrieval needs a separate store.

Bootstrap or reuse the project

First check for a valid .cohesivity file. If it exists, reuse that tenant. Creating another one would split related resources and make cleanup harder.

When no project exists, preview the bootstrap:

npx @cohesivity/init --dry-run

Then create the ephemeral project:

npx @cohesivity/init

The command writes project context with a management key, application key, tenant ID, lifecycle, runtime profile, and expiry. The initial tenant lasts 72 hours and needs no signup. Claiming it later is a separate human consent step.

Read each live offering contract

Before provisioning, fetch the current page for the resource, such as the live Postgres offering contract. Cohesivity requires a non-default User-Agent on direct HTTP requests:

curl -sS -A "MyCodingAgent/1.0" \
  https://cohesivity.ai/offerings/postgres

Read the required body, the fixed region, current limits, auth method, destructive operations, and verification fields. Repeat this for every resource. The agent-operable backend guide explains why status and cleanup are part of the contract.

Provision the database first

The live Postgres contract currently uses a management-plane request like this:

curl -sS -A "MyCodingAgent/1.0" -X POST \
  https://cohesivity.ai/api/resources/postgres \
  -H "Authorization: Bearer <coh_management_key>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: provision-postgres-v1" \
  -d '{}'

Postgres runs in one region (Singapore); a region field in the request is accepted and ignored. A resource is ready when its response says so and returns the documented endpoint. Do not infer readiness merely because the request returned 200.

From server-side application code, Postgres accepts one SQL statement or an atomic batch. PostgreSQL uses $1 placeholders:

curl -sS -A "MyAppServer/1.0" -X POST \
  "https://cohesivity.ai/edge/postgres?key=<coh_application_key>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: create-signups-schema-v1" \
  -d '{"query":"CREATE TABLE IF NOT EXISTS signups (id BIGSERIAL PRIMARY KEY, email TEXT UNIQUE NOT NULL)"}'

The query-string credential is the documented fallback. A server can exchange the application key for a short-lived edge session token and use bearer auth instead. Neither credential belongs in client-side JavaScript.

Add authentication with all callback URLs

Social login provisioning replaces the complete callback URL list. Include development and production URLs in the same request:

curl -sS -A "MyCodingAgent/1.0" -X POST \
  https://cohesivity.ai/api/resources/social-login \
  -H "Authorization: Bearer <coh_management_key>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: provision-social-login-v1" \
  -d '{"callback_urls":["http://localhost:3000/auth/done","https://example.cohesivity.app/auth/done"]}'

Use the actual deployment hostname returned by the hosting flow. Replacing the list later with only one URL removes the omitted callback.

Provision storage and hosting from their own contracts

Object storage profiles, upload behavior, hosting file formats, environment variables, domains, and readiness checks have separate offering pages. Fetch them immediately before use. Cohesivity's current primary hosting path uploads files through its Railway hosting API, without requiring a Railway CLI, GitHub connection, or tenant-held Railway credential.

Provision one service, verify it, then continue. A bulk request saves little time and makes it harder to identify which contract failed.

Verify the full lifecycle

After setup:

  1. Query resource status through the management plane.
  2. Exercise one server-side application call.
  3. Repeat one write with the same idempotency key and confirm one effect.
  4. Confirm no coh_* value appears in browser assets, logs, or version control.
  5. Record the tenant expiry and claim boundary.
  6. Document how each disposable resource is removed.

The prompt below asks the coding agent for the smallest resource set and stops before it creates anything.