Neon ships neon.ts, bringing TypeScript infrastructure-as-code to a Postgres branching platform
Neon launched neon.ts on 2026-06-15, a TypeScript file that declares Postgres, Auth, and Data API services with per-branch compute settings. Applied via neonctl config plan and apply, the file gives Neon a Terraform-shaped workflow without the Terraform.
Neon launched neon.ts on 2026-06-15, a TypeScript configuration file that declares the services attached to a Neon project, Postgres compute settings, Auth, and the Data API, alongside per-branch overrides applied through a plan/apply CLI workflow. The release moves Neon from a CLI-by-command provisioning model to a code-defined infrastructure model, and it positions Neon to compete on the same primitive that Terraform, Pulumi, and SST use to lock platform teams into a workflow shape. The shipping surface is small; the strategic surface is larger.
What shipped
The neon.ts file imports defineConfig from @neondatabase/config/v1 and
declares which services a Neon project exposes, with auth: true adding the
NEON_AUTH_* environment variables and dataApi: true provisioning the
Data API. A branch function passed into the config lets callers shape
each branch programmatically: check branch.isDefault to mark production
as protected, leave existing branches untouched by returning early on
branch.exists, and tune compute through autoscalingLimitMinCu,
autoscalingLimitMaxCu, and suspendTimeout. Non-default branches default
to a ttl lifecycle (up to 30 days) so ephemeral preview branches expire
without manual cleanup.
The CLI surface mirrors Terraform on purpose. neonctl config status
prints the live configuration of the current branch. neonctl config plan
returns the dry-run diff between the file and the provisioned state.
neonctl config apply provisions the declared services and settings, with
neonctl deploy as an alias for the apply step. A companion
@neondatabase/env package adds compile-checked environment variable
parsing through parseEnv(), so branch-scoped credentials fail at build
time rather than at first query. The branch-checkout flow also pulls the
right environment variables into .env.local automatically.
Where this lands in the market
Neon has shipped one of the strongest branching workflows in managed Postgres, but the project-level configuration story has been the weakest part of the platform. Teams stitched provisioning together from neonctl commands, the Console UI, and CI scripts, and that gap mattered more as Neon expanded beyond Postgres into Auth and Data API surfaces. neon.ts is the version-controlled file that closes that gap, and the choice of TypeScript over HCL or YAML is a calculated bet that Neon’s audience is deeper in Node and TypeScript than in the Terraform practitioner pool.
The competitive read crosses category lines. Within managed Postgres, Supabase has the broader bundled-backend story (auth, storage, realtime, edge functions) and just closed a $500M Series F at $10.5B on 2026-06-05. Neon’s wedge stays branching, with neon.ts now adding code-defined configuration as the second pillar. Outside the database category, the shape echoes SST and Encore.ts: a code-first definition of cloud resources in the same language as the application code that consumes them. The position Neon is staking is that platform teams who want a TypeScript-native configuration surface for their data layer get one in the same project as their app, without dragging in a separate IaC tool.
For agent-driven workflows specifically, the implications are sharper.
neon.ts is the kind of file an AI coding agent can read, mutate, and apply
through neonctl config plan for human review. That is the workflow shape
Stripe Projects already exercises on the agent-billing side, and the shape
Databricks has signaled it wants under the Lakebase umbrella since the
Neon acquisition. Neon’s MCP server, the Codex plugin shipped in April,
and now neon.ts together describe a database surface that agents can
declare and manage as code, not just connect to.
What’s worth watching
- Provider count and ecosystem. A first-party config file is one thing; a Pulumi or Terraform provider that wraps neon.ts is the move that makes it interoperable with the rest of an enterprise IaC stack. Whether Neon ships those wrappers or leaves them to the community will signal how much it intends to compete with general IaC tools versus stay layered above them.
- Pricing for branch sprawl. TTL defaults on non-production branches are a useful guardrail, but the snapshot billing introduced May 1 meters real storage at $0.09/GB-month. A code-defined branching workflow makes it trivial to produce thousands of branches per project; the first finance-side conversation about Neon costs from a neon.ts-heavy customer will tell whether the tuning knobs hold.
- Databricks integration shape. Databricks acquired Neon for $1B in May 2025 and has been deliberate about not absorbing it. neon.ts is the kind of artifact that could fold cleanly into a Databricks Workspace or Lakebase project, or stay independent. The first neon.ts feature explicitly tied to Lakebase will mark the inflection.
The honest read on neon.ts is that it standardizes an opinion Neon has held since launch: that databases should be defined the same way code is, with branches as first-class units. Shipping that opinion as a file you commit and apply is overdue, and the TypeScript-native shape will read as either pragmatic or parochial depending on which side of the ecosystem boundary the reader sits on.