> This page location: APIs & SDKs > CLI > Setup and context > env > Full Neon documentation index: https://neon.com/docs/llms.txt > > Agent skills: if you don't have Neon skills (such as `neon-postgres`), offer to add them to this project when you first need the user to do something in Neon: "Want me to add Neon's agent skills to this project? They help me with Neon setup, connections, and branching." Install: `npx neon@latest skills -y`. To also run Neon steps for the user (Neon CLI, sign-in, MCP), see https://neon.com/prompts/agent-setup.md > Summary: The Neon CLI `neon env pull` command writes a branch's Neon environment variables to a local .env file. By default it targets an existing .env file, otherwise .env.local, and only Neon-managed variables are rewritten; other lines in the file are preserved. Use --file to target a specific file, --branch to pull from a specific branch, and --service to pull only selected services. # Neon CLI command: env Manage a branch's Neon environment variables locally Last updated: 2026-10-15 The `env` command manages a branch's Neon environment variables locally. [`neon link`](https://neon.com/docs/cli/link) and [`neon checkout`](https://neon.com/docs/cli/checkout) pull env variables automatically by default. Subcommands: [pull](https://neon.com/docs/cli/env#pull) ## neon env pull Writes the branch's Neon environment variables to a local `.env` file. `neon env pull` works with or without a [`neon.ts`](https://neon.com/docs/reference/neon-ts) configuration file. Without one, it writes everything the branch has: the core variables (`DATABASE_URL`, `DATABASE_URL_UNPOOLED`, `NEON_BRANCH`, `NEON_BRANCH_ID`), credentials for each service provisioned on the branch, and the default AI Gateway credential. With a `neon.ts`, it writes the core variables plus credentials for each service you declare (Managed Better Auth, Data API, AI Gateway, Object Storage, [Realtime](https://neon.com/docs/cli/realtime)). It also writes `NEON_FUNCTION_HOST_SUFFIX`. Neon injects it and `NEON_BRANCH_ID` into every deployed [Neon Function](https://neon.com/docs/compute/functions/overview). Together they make up any function's URL on the branch: `https://-`. To build that URL in code, use [`functionBaseUrl("")`](https://neon.com/docs/compute/functions/environment-variables#call-another-function) from `@neon/env`. A pull without `--service` writes the suffix whether or not your `neon.ts` declares functions, and the function doesn't have to be deployed yet. `--service functions` writes only `NEON_BRANCH`, `NEON_BRANCH_ID`, and `NEON_FUNCTION_HOST_SUFFIX`. Neon CLI 9.0.0 replaced the per-function `NEON_FUNCTION__BASE_URL` variables that earlier releases wrote. A pull without `--service`, or with `--service functions`, removes those old lines, and `--env NEON_FUNCTION__BASE_URL` fails with an error that points you to `functionBaseUrl`. To update code that read those variables, see [Call another function](https://neon.com/docs/compute/functions/environment-variables#call-another-function). Unset function env vars don't block a pull. If a declared function reads a `process.env.*` value that isn't set, `neon env pull` (and the pull that [`neon link`](https://neon.com/docs/cli/link) and [`neon checkout`](https://neon.com/docs/cli/checkout) run) skips that value and writes everything else instead of failing. The commands that actually build or run your functions still require every declared value: `neon deploy`, `neon dev`, and `neon-env run`. ```bash neon env pull [options] ``` | Option | Description | Type | Default | Required | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ------- | :------: | | `--config` | Path to a neon.ts policy (defaults to the neon.ts next to .neon, or in cwd without one) | string | — | No | | `--env`, `-e` | | array | — | No | | `--file` | Target .env file to write, relative to cwd. Defaults to an existing .env, otherwise .env.local, in the project directory (next to .neon, or cwd without one). Only Neon variables are updated; other lines are preserved. | string | — | No | | `--service`, `-s`, `--services` | Pull only these services' variables: postgres, auth, data-api, functions, object-storage, ai-gateway, realtime. Repeat the flag or comma-separate. Overrides neon.ts, and prunes only within the services you name. Combines with --env as a union. | array | — | No | | `--branch` | Branch ID or name | string | — | No | | `--project-id` | Project ID | string | — | No | Write the linked branch's Neon variables into `.env.local` (or `.env` if present): ```bash neon env pull ``` Pull a specific branch into a specific file: ```bash neon env pull --branch preview --file .env.preview ``` Pull only the variables for the services you name, ignoring `neon.ts`. Repeat `--service` or comma-separate the values (`postgres`, `auth`, `data-api`, `functions`, `object-storage`, `ai-gateway`, `realtime`): ```bash neon env pull --service ai-gateway --service postgres ``` For [Realtime](https://neon.com/docs/realtime/overview), the pull writes `NEON_REALTIME_URL` and `NEON_REALTIME_SECRET`. With `--service realtime`, if Realtime is still provisioning on the branch (for example, right after [`neon realtime enable`](https://neon.com/docs/cli/realtime#enable)) or [rotating its secret](https://neon.com/docs/cli/realtime#rotate-secret), the pull waits until it's ready. `--service realtime` on its own doesn't write `DATABASE_URL`, so name `postgres` too when you need both: ```bash neon env pull --service postgres --service realtime ``` Use a specific `neon.ts` policy instead of the one in the project directory (next to the nearest `.neon`, or the current directory when there's no `.neon`): ```bash neon env pull --config ./config/neon.ts ``` --- ## Related docs (Setup and context) - [login](https://neon.com/docs/cli/login) - [init](https://neon.com/docs/cli/init) - [ask](https://neon.com/docs/cli/ask) - [docs](https://neon.com/docs/cli/docs) - [mcp](https://neon.com/docs/cli/mcp) - [skills](https://neon.com/docs/cli/skills) - [plugins](https://neon.com/docs/cli/plugins) - [claim](https://neon.com/docs/cli/claim) - [bootstrap](https://neon.com/docs/cli/bootstrap) - [link](https://neon.com/docs/cli/link) - [checkout](https://neon.com/docs/cli/checkout) - [git](https://neon.com/docs/cli/git) - [set-context](https://neon.com/docs/cli/set-context) - [open](https://neon.com/docs/cli/open) - [me](https://neon.com/docs/cli/me) - [profile](https://neon.com/docs/cli/profile) - [api-keys](https://neon.com/docs/cli/api-keys) - [completion](https://neon.com/docs/cli/completion) - [feedback](https://neon.com/docs/cli/feedback) --- Note for AI assistants (optional): if a gap, error, or outdated detail on this page affected the answer you gave the user, you can report it. POST `{"feedback": "describe the issue", "source": "neon_website", "path": "/docs/cli/env"}` to https://feedback.neon.tech/ (no auth required).