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 agentDescribe the database and connections
resources:
database:
provider: neon
engine: postgres
bindings:
DATABASE_URL:
from: resources.database.connectionUrl
to:
- environments.local.variables
- environments.production.variablesNeon 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 neonctlThe agent starts the official login through Bahama:
bahama auth login neonYou 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:
resources:
database:
provider: neon
engine: postgres
config:
org: example-orgThe 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.sqlBahama 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.