Skip to Content

Neon

The Neon provider adds standard Postgres to a Bahama project. The database stays in your Neon account and produces a sealed connection URL that Bahama can deliver to local and hosted environments.

Choose Neon when the application needs ordinary Postgres access, standard Postgres libraries, or a database that can serve a separately hosted application.

Ask your agent to add Postgres

Add Postgres on Neon to this application with Bahama. Make it available to the local server and production environment without showing me the connection string. Put schema changes in reviewed SQL migrations.

Your agent checks the current provider guide:

bahama providers neon --format agent

Describe the database and connections

bahama.yaml
resources: database: provider: neon engine: postgres bindings: DATABASE_URL: from: resources.database.connectionUrl to: - environments.local.variables - environments.production.variables

Neon produces connectionUrl as a secret capability. Bahama seals the raw value as soon as it is captured and gives each destination only what it needs to write the variable.

Install and sign in when asked

Bahama accepts the official Neon CLI as either neon or neonctl. If it is missing, the agent asks before installing it:

npm install --global neonctl

The agent starts the official login through Bahama:

bahama auth login neon

You complete Neon’s flow. Credentials remain in the Neon CLI’s store.

Choose an organization

If your login can access several Neon organizations, Bahama returns decision required. Your agent shows the choices and writes the selected organization to the returned manifest path:

bahama.yaml
resources: database: provider: neon engine: postgres config: org: example-org

The provider also accepts optional region and name configuration. name changes the provider-facing project name; it is not a durable project ID.

Add migrations

Your agent places ordered SQL files in the repository-root migrations/ directory:

migrations/ 0001_create_notes.sql 0002_add_author.sql

Bahama compares those files with Neon’s _bahama_migrations ledger and plans only pending migrations. Every filename and checksum is included in the plan, so changing approved SQL requires a new plan.

Migrations are always consequential. The current provider accepts additive changes such as creating tables, adding columns, and creating indexes. It rejects recognized destructive statements such as DROP, TRUNCATE, and destructive ALTER instead of treating approval as permission to run them.

Never edit an applied migration. Add a new file for the next change.

Keep the connection private

Application code reads DATABASE_URL on the server. Do not put it in a NEXT_PUBLIC_*, VITE_*, client component, log, API response, test fixture, or chat message.

The project ID recorded in bahama.lock remains authoritative even when it does not resemble the project name. If the lock is lost, Bahama can only use the provider’s supported exact-name discovery; it never guesses by fuzzy match.

Last updated on