Vector Docs

Features

Vector Cloud

Vector Cloud connects the repositories you work on to your own Vercel and Supabase accounts. Resources remain in those accounts, with their own billing, quotas and terms. Free model inference does not make hosting or database operations free.

This page describes desktop 1.99.109. Vercel and Supabase as the only providers, preview-first publishing, promotion gated on checks, Protection Bypass, Supabase organization creation and storage limits, and the each-time prompts below arrived in 1.99.108; desktop 1.99.106 offers Netlify and publishes to production by default. Windows WSL servers run the 1.99.99 engine that desktop 1.99.109 requires, so there the shell does not yet ask before vercel and supabase commands; that waits for a later desktop release that requires the next CLI. Connections offers sign-in with Vercel and Supabase when Vector's sign-in service is available for your desktop version (from 1.99.99), and an access token in every version that supports Vector Cloud.

Connect an account and link a Vercel or Supabase project

Open Vector Cloud from Home, pick the repository, then open Connections. Desktop 1.99.108 and earlier also open it from the Cloud button in a session; from 1.99.109 a task's view has no Cloud controls. Choose Connect to sign in with the provider in your browser and return to Vector, or Use access token to paste a token you create on the provider's token page. Either way the credential is validated and encrypted on this device. A Vercel sign-in is installed on one personal account or team, the one you choose on Vercel's screen; a token reaches every team it can. Supabase setup from Database leads to the same connection flow. Vector verifies the account before showing it as connected.

For Vercel, pick the personal account or team the Vercel project lives in, then link one of its Vercel projects or create a new one with a framework and root directory. A repository already deployed with the Vercel CLI is linked from its .vercel/project.json when you open Vector Cloud; an agent asks before linking it. Choose the Supabase project in Database. From 1.99.99, the desktop uses an encrypted temporary callback relay for Vercel, and PKCE for Supabase. Provider client secrets stay on the server. Management tokens are not returned to the renderer after saving.

Manage repository variables

Environment variable names keep the case you enter. Values are encrypted on your device and hidden by default, and drafts and revealed values clear when you change repository or task. Each variable is public or server-only, and a server-only value can never use a browser-visible name such as VITE_ or NEXT_PUBLIC_. Add or remove values in Vector, then choose Write to .env to update its managed block. Applying an empty list clears that block after the final removal; your lines above the marker remain. The file is replaced atomically, symbolic links are rejected, and POSIX systems use private file permissions. Every write, including the ones Supabase setup and the agent make, first adds .env to .gitignore when git does not already ignore it. Vector never writes a server-only value into a .env that git tracks: it stops, names the variables and leaves the file as it was until you stop tracking it with git rm --cached .env.

For a detected or configured Vite app, Vector preserves literal dollar signs and backslashes through Vite's environment parser. Enter literal values rather than expansion expressions. Multiline values and unsupported quote combinations are rejected before the file changes; add those in the On Vercel panel below instead, which sends them to the linked Vercel project without writing .env. Other frameworks retain their existing serialization.

The linked Vercel project's variables are listed by name, environment (production, preview, development) and type; their values are never shown. Add, change or remove a variable per environment, optionally for one preview branch. A value can span several lines, such as a PEM key: Shift+Enter adds a line, and Enter saves. Compare with local compares values by hash. A sync first shows its plan: it creates what is missing and updates or deletes only variables an earlier Vector sync wrote, and nothing is written until you apply that plan. Pull development values copies readable development values into this repository's .env after you review them. Publishing uploads .env with the source, so a site without a build step, which Vercel serves from its root, must leave it out with .vercelignore; until then its publish stops at the secret scan. Supabase setup adds the Supabase project's public URL and key under the names your framework exposes to the browser: NEXT_PUBLIC_ for Next.js, VITE_ for Vite, and plain SUPABASE_URL and SUPABASE_ANON_KEY otherwise. It writes a TypeScript client when the repository has a tsconfig.json, and adds .env to .gitignore when git does not already ignore it. Secret, service-role, management and user-session keys are rejected for that browser configuration.

Deploy to Vercel

Publish makes a preview unless you choose production and confirm it. A production build is made without moving your domains, checked, and promoted only when the required checks pass. Deployments lists everything Vercel has for the Vercel project, including git pushes, with Vector's checks attached to the releases it made. From there you can read build or runtime logs, cancel a build, redeploy, promote a staged production build, or roll production back to the last deployment that served it and passed Vector's checks. A production redeploy is built without moving your domains; promote it when you want it live. After you read a deployment's logs in Logs, Diagnose with the agent starts the agent on that deployment and log source; it reads the same redacted lines itself. An agent working in a parallel workspace can publish a preview of its worktree; it gets a stable address for its branch, shown on the workspace and reported in the task.

If Deployment Protection asks visitors to sign in, Vector's checks cannot open a preview. Hosting settings (the last entry under Setup in Vector Cloud) can create a Protection Bypass for Automation secret, kept in Vector's vault, so they can. Without it, a production build the checks cannot open is not promoted, and production stays where it is. Hosting settings also edit Vercel's framework, root directory, build, output and install commands and Node.js version. Domains attaches a domain you own and shows the exact records Vercel asks for, an A record for an apex domain or a CNAME for a subdomain, plus any verification record, then verifies them and reports the certificate.

Publish a preview, then go to production

Publish in Vector Cloud → Deployments makes a preview release by default. Before it runs, Vector names the Vercel project and the environment, and warns when the folder has uncommitted changes. Production changes only when you ask for it and the release checks pass. When a release fails, Fix this deploy starts the agent on it, with the failed checks and the end of the log as its first message. The agent can also publish from chat with its cloud tool, and asks first. Desktop 1.99.108 and earlier also offer Publish in a session's preview and a Cloud button in each session that shows the repository's hosting, database and latest release.

Run Supabase from Vector

The Database, Authentication, Storage, Edge functions, Database logs and Security screens act on the Supabase project linked to the repository. The agent can do the same through its cloud tool.

  • Supabase projectsLink an existing Supabase project or create one in the organization you choose, with progress shown while Supabase brings it up. An account with no organization names one and Vector creates it. An interrupted creation is finished rather than duplicated. Pause, restore or unlink the linked Supabase project.
  • Server credentialsWrite a server-only DATABASE_URL through the transaction pooler after you confirm. For a Supabase project Vector did not create, enter its current database password once instead of resetting it. Rotating the password can update DATABASE_URL and push the environment to Vercel. The password is encrypted on this device and never shown. Vector does not write DATABASE_URL into a .env that git already tracks.
  • Migrations and SQLSee which migrations are applied, pending or changed (including those the Supabase CLI applied), write a new one with its down SQL from Database, apply them after reviewing their SQL, and roll back the latest one with its down migration in supabase/migrations/down/<name>.down.sql. Without a down migration Vector refuses. The Supabase CLI reads neither a "-- down" section nor a .down.sql file next to the migrations: supabase db push runs both as forward SQL. Migration status warns when it finds them. The SQL console runs queries read-only and asks before a query that changes data.
  • AuthenticationEdit the site URL and redirect URLs, including your linked Vercel production and preview addresses. Turn email, Google, GitHub and Apple sign-in on or off; client secrets go to Supabase and are not shown again. List, invite and delete users.
  • Storage and Edge FunctionsCreate, update and delete buckets. Deploy functions from supabase/functions, delete them, and manage their secrets by name.
  • Logs and securityRead recent API, Postgres, Auth, Storage and Edge Function logs. The security check runs Supabase's security advisors and scans public environment variables and the built app for server keys. While Secret scan is a required release check (the default, under Build & runtime), promoting a release to production requires it to pass. If your Supabase connection is not allowed to read the advisors, they are skipped with a warning to reconnect. Diagnose with the agent starts the agent on the logs you read, and Fix with the agent on what the security check found; each change it then makes asks first.

Run cloud work from a task

The agent's cloud tool can inspect connections, detect build settings, prepare a linked database or authentication, and run the same Vercel and Supabase controls: Vercel projects and their settings, deployments, logs, promotion and rollback, variables and domains, everything listed for Supabase above, and Vector's own release checks: it can probe live releases, re-run a release's checks, and change the build commands and which checks are required before production. It can also list the names of the variables stored in Environment variables, write them to .env and remove one, but it cannot read or set a value in Environment variables. Once values are in .env, the agent can read them: the read tool and shell commands that name the file ask first, auto-accept answers that prompt, and a program the agent runs can open the file without one. It asks before it publishes, moves production, changes a database, writes a host's environment, .env or the stored variables, or changes a Vercel project or domain, and the prompt names the provider, the Vercel or Supabase project or the repository it acts on, and the environment, and shows any SQL that would run. It asks every time: auto-accepting permissions, a permission rule that allows it and an earlier approval never skip these prompts, and none of them offers Always allow. Only the read-only migration dry run can be answered by auto-accept. Vector also looks for direct calls to the Vercel or Supabase command-line tool in the agent's shell commands, such as vercel --prod, vercel env add or supabase db push, including quoted or escaped spellings such as ve''rcel, calls behind wrappers such as timeout, xargs, script, arch or strace, package runners such as npx, pnpm dlx, corepack or deno run npm:vercel, node running the CLI's own file, and sh -c, and asks for those the same way every time. Local work such as supabase start does not ask; vercel dev does, since it downloads the Vercel project's Development variables. This is a best-effort check on the command line, not a boundary: a call it cannot see, such as one inside a package script (npm run deploy), behind a variable, an alias or a wrapper it does not know, or in a program that uses the command-line tool's stored login itself, runs without that prompt. Only the shell sandbox (VECTOR_SHELL_SANDBOX=1, off by default), which hides those stored logins from the agent's commands, closes that route. Vercel's and Supabase's own MCP servers, added from Plugins or by hand, follow the same rule: a tool that changes the account, runs SQL or returns keys asks every time and shows its input, while plain list and read tools do not. The Plugins Supabase entry starts its server read-only. One route stays outside these prompts: for a Vercel project connected to Git, a git push to its production branch releases production through Vercel's own Git integration, without Vector's release checks. Add a permission rule that asks for git push if pushes must wait for you. A new migration file asks like any other edit, showing both the migration and its down file. OAuth client secrets, function secret values and the database password are entered in Vector Cloud, never in chat, and the agent can only refer to variables already stored there. Query results reach the agent as the query returns them, except cells in columns named like passwords, tokens or secrets, values under such names inside JSON, and password hashes, which are hidden. A query that reads Supabase's own credential tables, such as auth.users, shows the agent only their known non-credential columns, named as they are, so a renamed column or a whole row comes back hidden. A credential read through a view or a function the query calls is not recognised. Publishing goes to the Vercel project linked to the repository, as a preview unless you ask for production; without a linked Vercel project, the tool returns setup guidance. A failed publish reaches the agent with its failed checks and log lines, so it can fix the cause. A failed Vercel deployment never triggers a deployment somewhere else. The agent is instructed not to ask for secret values in the chat, and to name the variable to add in Environment variables instead.

  • Deployment checks and logsPublishing can run configured build, health and browser checks. Their results and provider logs show what was verified and what failed.
  • Database setupReuse a linked Supabase project, or explicitly approve creation in a chosen organization. Provider quotas and billing still apply. Vector does not automatically upgrade plans or move creation to another organization after a limit.
  • Repository migrationsInspect a dry-run plan before applying .sql migrations to the linked database. Each file runs in one transaction with its record, which Vector keeps with a checksum in a private schema your app's API keys cannot reach. Files the Supabase CLI already applied are skipped, an applied file that was edited stops the run, and execution stops at the first failure.
  • Account controlDisconnect removes Vector's local credential. For a sign-in connection it also revokes Vector's access: it removes Vector's Vercel integration, or revokes its Supabase authorization, and says so when the provider did not confirm it. A personal access token you pasted stays valid until you delete it with the provider.

These actions run through the Vector desktop app, where provider connections live. The standalone terminal CLI reports the desktop cloud tool as unavailable.