Databases and secrets

Choose a database because the application needs persistence and a particular access model—not because an example happens to include one.

Bahama’s current database providers intentionally expose different interfaces. Your agent should write application code for the selected provider rather than inventing a universal connection layer.

const row = await env.DB
  .prepare("select id, email from members where id = ?")
  .bind(memberId)
  .first();

bindings:
  DATABASE_URL:
    from: resources.database.connectionUrl
    to:
      - environments.local.variables
      - environments.production.variables

Schema changes

The migration path depends on the provider.

For Neon, your agent adds ordered SQL files under migrations/. Bahama plans pending checksums, applies them before dependent deployment steps, and records them in _bahama_migrations. Migrations are always consequential, and the current provider rejects recognized destructive statements.

Bahama Cloud does not currently plan schema migrations. Keep its schema setup explicit and idempotent in server-side code, and ask before destructive or broad data changes.

Secret bindings

Provider-produced secrets move through named capabilities. Bahama keeps the value sealed until a destination writes it.

An unchanged name is not enough to make rewiring safe: changing the source of DATABASE_URL can point production at an entirely different database.

Third-party secrets

API keys, OAuth client secrets, and webhook secrets do not belong in bahama.yaml.

For Bahama Cloud, tell your agent the server-side variable name and enter the value yourself on the project’s Secrets page. For local development, the agent can place a placeholder in the protected environment file for you to replace directly.

Never paste the raw value into chat. Never expose it through VITE_*, NEXT_PUBLIC_*, client code, browser responses, logs, screenshots, or test fixtures.

Destructive database work

Bahama currently has no destroy command and does not treat approval as a blank check for destructive SQL. If a database or schema must be removed, confirm the exact provider account and resource and use the provider’s own destructive surface with explicit authorization.