Skip to content

Neon.Project reference

Source: src/Neon/Project.ts

A Neon serverless Postgres project.

Creating a project also provisions the project’s default branch (named “main” by default), an initial role, an initial database, and a read-write compute endpoint, exposed as connectionUri.

Basic project

const project = yield* Neon.Project("my-project");

Project with explicit region and PG version

const project = yield* Neon.Project("my-project", {
region: "aws-eu-central-1",
pgVersion: 17,
});

Project with logical replication enabled

const project = yield* Neon.Project("my-project", {
enableLogicalReplication: true,
});
const project = yield* Neon.Project("my-project", {
migrations: "./migrations",
importFiles: ["./seed/users.sql"],
});
const project = yield* Neon.Project("my-project");
const dev = yield* Neon.Branch("dev-branch", { project });

Source: src/Neon/ProjectMemberRole.ts

Own one explicit project grant for an existing organization member. Inherited/default access is not owned or removed. Adopting an existing direct grant requires explicit adoption and captures it for exact restoration. Deletion removes only a newly created direct grant, or restores the adopted one. Organization-admin overrides and self changes are refused. This resource never enables confirm_self_demotion or confirm_self_lockout and never invites anyone.

Requires user credentials with observable ADMIN project permission. A missing member, ambiguous grant source, or list failure is not evidence of no grant. The list API’s 404 can mean disabled permissions or insufficient access. Cleanup accepts a removed membership only after a complete organization listing. A missing project additionally requires an organization-admin scoped project listing with no unavailable entries; an ambiguous 404 alone never discards state.

The engine durably saves the initial read snapshot before reconciliation. Deploy the project first, then supply its resolved ID and resolved settings. Missing baselines and ambiguous interrupted writes fail closed. Do not discard state or edit this grant concurrently: Neon has no conditional role-write API.

ProjectMemberRole: Grant access to an existing member

Section titled “ProjectMemberRole: Grant access to an existing member”
const access = yield* Neon.ProjectMemberRole("ReviewerAccess", {
orgId: "org-example",
memberId: authorizedMemberId,
project: { projectId: deployedProjectId },
role: "viewer",
});
const access = yield* Neon.ProjectMemberRole("ExistingAccess", {
orgId: "org-example",
memberId: authorizedMemberId,
project: { projectId: deployedProjectId },
role: "editor",
}).pipe(Alchemy.adopt(true));

Source: src/Neon/ProjectVPCEndpoint.ts

Manage one project’s restriction to an already registered organization VPC endpoint. Requires an organization admin entitled to AWS Private Networking. The project, endpoint, and client must share an AWS region and the endpoint must belong to the project’s organization. Azure is unsupported. This does not change the AWS endpoint, its organization registration, or the project’s separate block_public_connections setting. Other restrictions are left untouched. Removing the last restriction can broaden connectivity.

Existing associations require explicit resource-scoped adoption. Their original label is durably captured before mutation and restored on destroy; an adopted restriction is never silently removed. New restrictions are removed on destroy only when their label still matches the managed value. Scope changes replace with old-scope cleanup first, avoiding stale managed grants. Preserve state and serialize writers; Neon has no conditional writes.

const restriction = yield* Neon.ProjectVPCEndpoint("PrivateAccess", {
project,
endpoint: network,
label: "Application access",
});