Jeff See

Add experimental container runtime (#16648) ## Summary Adds an experimental **container service runtime** to the Vercel CLI monorepo. Services configured with `runtime: "container"` can either: - **Build from a Dockerfile** — build the image, push it to the Vercel Container Registry (VCR), wait for readiness, and emit a digest-pinned image reference as build output, or - **Use a prebuilt image** — pass through an existing registry reference via `image` / entrypoint without building locally. This wires the new `@vercel/container` builder into service detection, `vercel build` output collection, and the Build Output API. ## TLDR This is a small tweak to add a new runtime for the existing services api, the container package is isolated and only enabled when the runtime is `container`, so should be safe to merge with minimal impact to production codepaths. ## How it works 1. **Detection** (`@vercel/fs-detectors`) — resolves container services from `vercel.json` / service config; Dockerfile entrypoints (`Dockerfile`, `Containerfile`, `*.dockerfile`) trigger a build, otherwise the entrypoint is treated as a prebuilt image ref. 2. **Build** (`@vercel/container`) — authenticates to VCR with `VERCEL_OIDC_TOKEN`, ensures the target repository exists, then build → login → push. 3. **Output** — writes a container function to `.vercel/output` with `runtime: "container"` and a digest-pinned VCR image reference as the handler. 4. **Readiness** — polls until the pushed digest is usable (remote manifest inspection locally via docker; skopeo with buildah on Vercel). ## Toolchain | Environment | Engine | Notes | |---|---|---| | Local `vercel build` | **docker** | Uses the local Docker daemon (OrbStack, Docker Desktop, etc.) | | Vercel build container | **buildah** | Daemonless; includes storage-driver selection for nested build cells and a permissive `registries.conf` for unqualified `FROM` lines | Override with `VERCEL_CONTAINER_ENGINE=docker|buildah`. ## Packages touched - **`@vercel/container`** (new) — builder implementation, VCR push/readiness, pluggable `ContainerEngine` interface - **`@vercel/build-utils`** — `ContainerImage` output type for BOA collection - **`@vercel/fs-detectors`** — container service runtime resolution - **`vercel` CLI** — container output wiring in `write-build-result`, config validation, builder dependency ## Test plan - [x] `@vercel/container` unit tests (`pnpm test-unit` in `packages/container`) - [x] `@vercel/fs-detectors` container service detection tests - [ ] Local `vercel build --cwd <project-with-container-service>` with linked project + fresh OIDC token - [ ] Deploy to Vercel with a container service Dockerfile and confirm image lands in VCR - [ ] Verify buildah path in the Vercel build container (not just local docker) --------- Co-authored-by: Cursor <cursoragent@cursor.com>

[cli][container] Fix `vercel dev` for top-level container builds (#16833) ## Summary `vercel dev` did not work for the `container` framework when a container is used as a **top-level build** (outside of `services`). The services flow works because the orchestrator drives `startDevServer` directly, but the legacy (non-services) dev pipeline runs `build()` → zip → `fun` first, and the container builder was never wired up for that path. Fixing it surfaced a chain of issues, all addressed here. Reproduced with a project containing only a `Containerfile.vercel` and a near-empty `vercel.json` (`framework: container` via zero-config). ## What was broken (in the order you'd hit it) 1. **"did not match any source files"** — the dev server didn't map the container preset's `<detect>` sentinel to a real Dockerfile, so no `BuildMatch` was created. 2. **`` Error: `vercel dev` cannot build container images from a Dockerfile ``** — `@vercel/container`'s `build()` threw in dev and treated a *prebuilt image* as the expected input. Containers have no prebuilt-image input; the local build belongs in `startDevServer`. 3. **`output.createZip is not a function`** — the dev pipeline (`builder-worker.cjs` + `executeBuild`) treated the container's OCI-image output (`runtime: "container"`) as a zip-based Lambda and tried to zip it / run it under `fun`. 4. **`Container "undefined" exited (code 125)`** — the dev path only looked for a bare `Dockerfile`, so a project using a `Dockerfile.vercel` / `Containerfile.vercel` marker failed even though deploys worked; and Docker-not-running was surfaced as a cryptic exit code with `"undefined"` as the name. 5. **Rebuild + restart on every request** — the container `startDevServer` result was missing `persistent: true` and had no reuse cache, so each HTTP request rebuilt the image and started a fresh container. ## Changes **`packages/cli`** - `getBuildMatches`: map the `container` framework `<detect>` sentinel to a discovered Dockerfile so a build match is created (mirrors the existing `python`/`node`/`go` handlers). - `executeBuild` + `builder-worker.cjs`: skip the zip-size check, `createZip`, and `fun` `createFunction` for `runtime: "container"` outputs — they're served by `startDevServer`. **`packages/container`** - `build()` no longer throws in dev; returns a stable local tag without pushing to a registry. - `startDevServer` / `resolveDevImage` now discovers the `Dockerfile.vercel` / `Containerfile.vercel` markers via a `findDockerfile` helper now **shared** with the build path. - Fail fast with a clear message when the Docker daemon is unreachable; container start errors now name the real container and include Docker's stderr. - Reuse a live container across requests (module-level cache keyed by service/work dir) and return `persistent: true`, matching `@vercel/backends`. ## Testing - `@vercel/container` unit tests: **37 pass**, including new tests for dev `build()` not pushing, `<detect>` → `Containerfile.vercel` discovery, daemon-down messaging, the fixed container name, and container reuse across requests (one `docker build` + one `docker run` for two requests). - `vercel` `test-unit`, `type-check`, and Biome lint pass for the touched files. (Pre-existing unrelated `undici` type errors in `fetch.ts` / `fetch-proxy.ts` are not part of this change.) - Manually verified `vercel dev` against a top-level container project (`Containerfile.vercel`): builds/runs once, then proxies subsequent requests without rebuilding. ## Follow-up (not in this PR) The non-services pipeline still runs an eager `build()` on the container at startup before `startDevServer` takes over (because the builder has no `shouldServe`). A cleaner future change would let builders that expose `startDevServer` with a non-zippable output skip the eager `build()` entirely, unifying further with the services flow.

Fix scope resolution for Northstar accounts with username/team-slug collision (#16779) ## Problem A Northstar account's username can equal the slug of its default team (e.g. user `my-user` whose default team `team_…` also has slug `my-user`). This collision produced two bugs: 1. **`vc projects ls` reports "No projects found" despite the team having projects.** `get-scope` resolved the default team for *display* (`vc whoami` showing "Active team: my-user") but never wrote it to `client.config.currentTeam` — which is the only thing `client._fetch` uses to attach a `teamId`. The default is only persisted at login (`updateCurrentTeamAfterLogin`), so on any invocation without it, requests went out with **no `teamId`** and were silently scoped to the resource-less personal account while the UI claimed the team. 2. **`--scope my-user` is rejected as "You cannot set your Personal Account as the scope."** In `index.ts`, the personal-account identity check ran *before* the team lookup, so a team whose slug matches the username could never be selected by name. ## Fix - `packages/cli/src/util/get-scope.ts`: apply the Northstar `defaultTeamId` to `client.config.currentTeam` when it isn't already set, so the effective request scope matches what the CLI displays. - `packages/cli/src/index.ts`: resolve `--scope <name>` against the user's teams *before* falling back to personal-account handling. Team-load failures are tolerated when the scope already matches the user's own identity, preserving existing personal-account behavior. ## Testing - Added unit tests in `get-scope.test.ts`: the default team is applied to `currentTeam`, and an explicitly selected team is not overridden. - `get-scope` (7), `project/list` (12), `switch` (3), `teams/switch` (12) suites pass. - `northstar.test.ts` fails identically with and without this change in the local sandbox (pre-existing interactive-login harness timeout); not a regression. ## Changeset `vercel` patch — included.

[backends] Detect entrypoint after install and build commands (#17284) ### Description Stacked on #17283. The wrapper builders (`@vercel/express` et al.) resolve the entrypoint in `entrypointCallback`, which `@vercel/node` invokes **after** the install and build steps — so entrypoints generated by the build are found. The backends builder detected the entrypoint **before** running the Build Command, failing with "no entrypoint found" for the canonical tsc-style setup: ```json { "main": "dist/index.js", "scripts": { "build": "tsc" } } ``` This PR moves `maybeDoBuildCommand` ahead of entrypoint detection. Detection logic itself is unchanged; only the timing moves. ### Tests - New `test/unit.post-build-entrypoint.test.ts`: full `build()` against a fixture whose entrypoint only exists after the Build Command runs. Verified red/green — fails on the base commit, passes with this change. - `pnpm vitest-run --run test/unit.build.test.ts test/unit.find-entrypoint.test.ts` — 15 passed - `outputDirectory "."` symlink regression test in `unit.test.ts` — passed - `pnpm type-check` — clean

[CLI] Add opt-in config for native binary trampoline (#17209) ## Summary PR 1 of 2 for building native CLI binaries into the release flow. This PR adds the **opt-in gate** so the native `@vercel/vc-native-*` binary is never spawned unless the user explicitly opts in — a prerequisite before PR 2 wires `optionalDependencies` (which would otherwise make every install run the binary). ## Changes - **Config:** add flat `useNativeBinary` key to the global config (`@vercel/cli-config`). Adds a zod-free `@vercel/cli-config/paths` subpath so `vc.js` can read the flag on the startup hot path without loading zod/schemas (~40ms saved). - **Trampoline gate (`vc.js`):** only spawn the native binary when opted in — via the config flag or the `VERCEL_CLI_USE_NATIVE_BINARY` env override. Any failure to read config is treated as "not opted in", so we never spawn a binary the user didn't ask for. The `resolveNative()` check runs first and short-circuits, so there is no added cost when no native package is present. - **`vercel upgrade --binary [true|false]`:** toggles the opt-in, with telemetry. - **Auto-opt-in:** members of the `vercel` team are auto-opted-in, matched by the globally-unique team slug (no hardcoded team id), and only when the user has no explicit preference (an opt-out via `--binary false` is always respected). - **Tests:** trampoline gating (opt-in / opt-out) and the upgrade flag. ## Hot path note The opt-in read only runs when a native binary is actually resolvable. Today (no `optionalDependencies`) that's never, so the gate costs ~0ms. Once PR 2 lands, the zod-free `paths` read is ~7ms (dominated by `xdg-app-paths`); can be inlined further in PR 2 if a startup benchmark shows it matters. ## Follow-up PR 2: build binaries in the release flow, populate `optionalDependencies` before publishing `vercel`, and fail the publish if a binary build fails.

[cli] fix self-upgrade for pnpm 11 global installs and post-upgrade prompt (#16903) ### What Fixes three bugs in the CLI self-upgrade flow (`vc upgrade` and the post-command upgrade prompt): 1. **pnpm 11 global installs are misdetected as local npm installs.** The upgrade runs `npm i vercel@latest` in the user's **current working directory** — polluting whatever project (or home directory) they're standing in with a stray `node_modules`/`package.json` — and then reports success while the real installation is untouched. Reproduced on a **fully clean machine** (fresh fnm-installed Node, fresh standalone pnpm 11, single vercel install, latest CLI): ``` > [debug] Executing: npm i vercel@latest (cwd: /Users/jeffsee) > Success! Vercel CLI has been upgraded to v54.18.7 successfully! $ vc -v 54.17.3 # unchanged ``` 2. **Unrecognized install layouts default to executing a local install in the cwd.** This is the dangerous fallback underlying bug 1: any future layout change reintroduces the same failure. Running inside a pnpm/yarn workspace also fails loudly with `EUNSUPPORTEDPROTOCOL: Unsupported URL Type "workspace:"` because npm tries to resolve the surrounding workspace's dependency tree. 3. **The update prompt re-fires immediately after a successful `vc upgrade`.** The process still holds the pre-upgrade version in memory, so it asks "Would you like to upgrade now?" right after printing the upgrade success message. ### Why detection fails on pnpm 11 pnpm 11 moved global installs to isolated directories (`{PNPM_HOME}/global/v11/{hash}/`) backed by the global virtual store, so the install's realpath lives under `{storeDir}/links/...` ([pnpm 11 release notes](https://github.com/pnpm/pnpm/releases/tag/v11.0.0)). All three detection strategies in `get-update-command.ts` miss: - `pnpm root -g` answers with the *parent* of the isolated install dirs (not a `node_modules`), or — on machines upgraded from pnpm ≤10 — a stale `global/5` directory that pnpm does not migrate ([pnpm/pnpm#11528](https://github.com/pnpm/pnpm/issues/11528)), so `detectGlobalCliType` never matches - no lockfile exists above the install dir inside the store, so the lockfile scan falls through to `npm` - the store path does not contain `/pnpm/global/`, so the path heuristic misses, and the npm prefix check misses too → `global: false` Result: `{ cliType: 'npm', global: false }` → `npm i vercel@latest` in `process.cwd()`. ### How - **`isPnpmHomeInstall()`**: classify as pnpm + global when the unresolved entrypoint (`process.argv[1]`) or the realpath'd install dir is inside `PNPM_HOME`. This is layout-version independent — pnpm ≤10, 11, and future layouts all live under `PNPM_HOME` — and requires no shelling out. Checked before the existing query-based detection. - **Store-links path heuristic**: `isGlobalByPath` now also recognizes the pnpm 11 global virtual store pattern (`…/pnpm/store/…/links/…`) as a safety net when `PNPM_HOME` is not in the environment. - **Never classify as local without positive evidence**: a local (project-dependency) install always has a lockfile above the CLI's install location. Without that evidence, the upgrade now degrades to `npm i -g vercel@latest` executed from a temp dir — a potentially suboptimal suggestion, but one that cannot mutate the user's cwd. - **Crash-proof entrypoint resolution**: `realpath(process.argv[1])` failures (e.g. virtual filesystem snapshot paths in the native binary — the class of crash fixed for natives in #16581) no longer throw out of detection; they degrade to the safe global fallback. - **Prompt guard**: the post-command update notifier is skipped when the command was `upgrade`, mirroring the existing `canAutoUpdate` guard. ### Impact Every pnpm 11 global install of the CLI is affected, on all released versions including current latest — and the population grows as pnpm 11 adoption spreads (each `pnpm add -g vercel` under pnpm 11 creates the broken-detection layout). #16534 fixed the pnpm ≤10 workspace case but predates pnpm 11's layout. ### Test Plan - Unit tests covering: pnpm 11 isolated layout, legacy `global/5` layout, `PNPM_HOME` prefix anchoring (no substring false-positives), entrypoints outside `PNPM_HOME`, and the unrecognized-layout degradation (34 tests passing in `get-update-command`, `updates`, and `upgrade` suites) - `tsc --noEmit`, biome lint, prettier: clean - Empirical: bug reproduced pre-fix on both a long-lived dev machine and a fully reset clean machine; failure mechanism verified step-by-step against pnpm 11.7/11.9 layouts ### Follow-ups (not in this PR) - Post-install version verification: the success message currently reports the pre-resolved target version, not what was actually installed (observed divergence when pnpm's `min-release-age` gated the newest version: "upgraded to v54.18.7" while 54.18.6 was installed) - bun/vlt global installs are not detected (`scanParentDirs` can return them but `GlobalCliType` doesn't model them) - Longer term: distribution-channel awareness baked in at build time (native binary self-replacing; PM-distributed builds printing rather than executing), eliminating install-method forensics entirely

[frameworks] Source the framework list from the frameworks manifest (#16975) ### What Replaces the hand-written framework array in `@vercel/frameworks` with `frameworks.json`, sourced from the frameworks manifest (`https://api-frameworks-two.vercel.sh/v1/frameworks.json`, see vercel/api#78614). - `frameworks.json` is a **build artifact**: fetched by `build.mjs`, shipped in `dist/`, not checked into git. The fetch is fatal only when no previously fetched copy exists (`FRAMEWORKS_SKIP_MANIFEST_REFRESH=1` reuses the existing copy). Unit tests assert the manifest exists and is fully interpretable. - `src/manifest.ts` interprets declarative descriptors (`outputDirName`, `defaultRoutes`) into the runtime functions the `Framework` type requires. Unknown descriptor types throw `UnsupportedFrameworkEntryError` — the forward-compat hook for later PRs. ### Compat All existing exports are unchanged in shape (`frameworks` is now typed `readonly Framework[]` instead of a literal tuple; no in-repo consumer relied on the literals). The manifest currently adds one entry over the previous list: `tanstack-start-lovable` (intentional — a platform-import variant carrying the new `platform` field, now typed on `Framework` and validated by the schema test). ### Part of a stack Extracted from #16939 (kept open as the reference artifact for the full design). Follow-ups: 1. **This PR** — manifest as build artifact + interpreter 2. Runtime resolver API (`resolveFrameworks()`, remote fetch + cache, `minCliVersion`/`failOnStale` gating) 3. CLI wiring (`vc build` consumes the resolved list, upgrade warnings, build-container detection) ### Testing - 7 new unit tests (`manifest.unit.test.ts`): pinned manifest exists + interpretable, descriptor interpretation, override precedence, manifest-only field stripping - Existing schema/logo/unique/example suites pass unchanged against the interpreted list (strict `additionalProperties` validation retained) - Also fixes the pre-existing Node 24 failure in `frameworks.unit.test.ts` (`util.isString` was removed; replaced with a type guard) --------- Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com> Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>

[services] Refine container entrypoint detection (#16823) ## What Reworks container detection for `services` / `experimentalServicesV2` in `@vercel/fs-detectors`. ### Behavior - **Entrypoint infers `runtime: container` (broad match):** a supplied `entrypoint` whose basename is `Dockerfile` / `Containerfile`, or is prefixed `Dockerfile.` / `Containerfile.` (e.g. `Dockerfile.prod`, `Containerfile.vercel`). - **`runtime: container` + no entrypoint auto-detects (narrow match):** probes only the four blessed names, **`.vercel` markers first**: `Dockerfile.vercel` → `Containerfile.vercel` → `Dockerfile` → `Containerfile`. A `.vercel` marker takes precedence over a plain `Dockerfile`, matching the `container` framework preset. - **Removed the prebuilt OCI image reference entrypoint.** An `entrypoint` must now name a Dockerfile/Containerfile: - `runtime: container` + a non-Dockerfile entrypoint → `INVALID_SERVICE_CONFIG` - `runtime: container` + no entrypoint and no blessed Dockerfile present → `MISSING_SERVICE_CONFIG` `resolveContainerServiceV2` is now async and receives the root-scoped filesystem so it can probe for auto-detection. ### Tests Adds `packages/fs-detectors/test/unit.detect-services-v2-container.test.ts`, driven by shareable fixtures under `test/fixtures/services-container/`. Each scenario is its own directory named `pass-*` / `fail-*`. The old inline container `describe` block was removed (coverage moved to fixtures). ## Validation - `pnpm type-check`: clean - New container suite: 12/12; both v2 service test files: 39/39 - Full `@vercel/fs-detectors` unit suite passes except a pre-existing, unrelated `should skip entry if socket` failure (sandbox Unix-socket `listen EINVAL`) ## Notes - The `@vercel/container` builder still contains its prebuilt-image (`handler`) passthrough; it's now unreachable from services but still serves root `<detect>` deploys. Left untouched to keep this scoped to services detection. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Breaking change for services that used prebuilt OCI image entrypoints or suffixed Dockerfiles; detection and framework selection behavior changes for multi-framework repos with container markers. > > **Overview** > **Container services** (`experimentalServicesV2` / `services`) now only treat four **blessed** Dockerfile basenames as container entrypoints: `Dockerfile`, `Containerfile`, `Dockerfile.vercel`, and `Containerfile.vercel`. Suffixed names like `Dockerfile.prod` are **rejected** (no longer matched via `*.dockerfile`). > > With **`runtime: "container"`** and no `entrypoint`, the resolver **auto-detects** those files in the service root, probing **`.vercel` markers first** (`Dockerfile.vercel` → `Containerfile.vercel` → `Dockerfile` → `Containerfile`). **Prebuilt OCI image references** as `entrypoint` are **removed** for services; non-Dockerfile entrypoints error with `INVALID_SERVICE_CONFIG`, and missing blessed files yield `MISSING_SERVICE_CONFIG`. `resolveContainerServiceV2` is **async** and uses the scoped service filesystem for probing. > > **`@vercel/container`** shares the same blessed-set logic via exported **`isDockerfileRef`** in `util.ts` (dropped local duplicates in `dev.ts` / `index.ts`) so the builder honors service-resolved Dockerfile paths instead of defaulting or misclassifying entrypoints. > > The **`container` framework preset** is **no longer experimental**—`Dockerfile.vercel` / `Containerfile.vercel` projects detect as container without `VERCEL_USE_EXPERIMENTAL_FRAMEWORKS`. Coverage moves to **`unit.detect-services-v2-container.test.ts`** and **`test/fixtures/services-container/`** (`pass-*` / `fail-*`). > > ^{Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 5ed0b771133a8aff9b455a2ffe97cb0949eec1b7. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).} <!-- /CURSOR_SUMMARY -->

[cli] Send gitMetadata.rootDirectory on deploy (#17344) ## Summary - Add `gitMetadata.rootDirectory`: path of the deployed project directory relative to the detected git repository root (`""` at repo root) - Resolve `.git/config` from the git toplevel so subdirectory deploys still attach `remoteUrl` - Keep this separate from the project `rootDirectory` setting and from user `--meta` ## Test plan - [x] `npx vitest run test/unit/util/deploy/create-git-meta.test.ts` (32 passed) - [ ] Deploy from a monorepo subdirectory and confirm the deployment has `meta.gitRootDirectory` matching that path (after API PR is deployed) Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>

fix(ci): install Go toolchain for packages depending on ipc-proxy and harden Go download (#17088) Fixes flaky CI failure unrelated to PR #17079. **Failing job:** https://github.com/vercel/vercel/actions/runs/29277311707/job/86909622217 – `Unit / CLI (mac/node20) [7/7]` **Root cause:** - `turbo run ... --filter=vercel` builds the CLI which depends on `@vercel/go` → `@vercel-internals/ipc-proxy`. - `ipc-proxy` compiles Go cross-arch binaries during its build. - Workflow only installed Go when `matrix.packageName == '@vercel-internals/ipc-proxy'`, not for `vercel` CLI. - On macOS runners without system Go, `internals/ipc-proxy/build.mjs` fell back to downloading Go via `fetch()`, which flaked: ``` Downloading Go 1.23.12: https://dl.google.com/go/... TypeError: terminated at Fetch.onAborted ``` leaving a corrupted `/tmp/vercel-ipc-proxy-go-1.23.12`. Retry checked only `bin/go` existence, so it reused the corrupt GOROOT: ``` proxy.go:17:2: package context is not in std (.../src/context) ``` → build failed → turbo failed → job failed after 2 attempts. This is reproducible on `main` for any PR that triggers CLI unit chunks on mac. **Fix:** 1. **`utils/chunk-tests.js`** – add `needsGo` detection mirroring `needsRust`: - `GO_BUILD_ROOTS = { '@vercel-internals/ipc-proxy', '@vercel/go' }` - Packages depending on those roots (notably `vercel` CLI) now get `needsGo:true` in the chunk matrix. 2. **`.github/workflows/test.yml`** – install Go when `matrix.needsGo == true` for both `unit-test` and `e2e-test` jobs, preventing the network fallback on CI. 3. **`internals/ipc-proxy/build.mjs`** – harden the fallback for local/dev: - Validate cached GOROOT by reading `src/context/context.go`; if missing, re-download. - Retry download 3× with exponential backoff and `AbortSignal.timeout(120s)`. - Clean dest dir on failure to avoid poisoning retries. - Add timeout to `hasSystemGo()`. **Test plan:** - [ ] Verify `TEST_TYPE=unit node utils/chunk-tests.js | jq '.[] | select(.packageName=="vercel" and .runner=="macos-14") | .needsGo' | uniq` → `true` - [ ] CI: mac unit jobs for CLI now install Go, no longer Downloading Go log line - [ ] Existing `.github/workflows/test.yml` still passes on linux/mac/win Resolves flake seen in https://github.com/vercel/vercel/actions/runs/29277311707/job/86909622217