# Vercel (/integrations/vercel) Vercel is optional integration metadata for repos that need project-aware preview settings. Mogplex-managed billing owns sandbox access. Use the Vercel integration when a repo needs Vercel-linked project settings for previews, root directories, and environment sync. Do not use it as an external sandbox account path. ## Where Vercel is configured [#where-vercel-is-configured] Vercel setup is primarily repo state: * [Projects](/web/spaces) owns repo-specific Vercel team, project, root directory, env mapping, install command, dev command, port, and timeout settings. * [Sandboxes](/web/sandboxes) shows live and pending runtime state after a sandbox exists. * [Observability](/web/observability) shows the call, job, sandbox, model, and cost trail after work starts. ## Billing model [#billing-model] Sandbox usage is billed through Mogplex. A linked Vercel project can provide preview metadata and environment sync, but it is not the billing source for Mogplex sandboxes. That means you can configure GitHub coverage, repo import, agents, triggers, assignments, and automations without asking users to attach their own sandbox account. ## Repo-linked project settings [#repo-linked-project-settings] Use [Projects](/web/spaces) when one repo needs Vercel-specific runtime configuration: * Vercel team and project mapping * root directory for monorepos * install command * dev command * dev port * sandbox timeout override * environment mapping mode * manual environment variables in `.env`-style `KEY=value` format This matters most for monorepos and preview apps where the default repo root is not the app Mogplex should run. ## Environment sync [#environment-sync] Repo settings control how sandbox environment variables are assembled. Use manual repo variables when Mogplex needs values that are not sourced from a Vercel project. Use Vercel-linked sync when the repo should inherit environment state from the selected Vercel project, with repo settings acting as the Mogplex-side control point. If a preview boots but behaves like the wrong app or misses expected env vars, check the repo root, env mapping mode, Vercel project mapping, and manual repo vars together. ## Preview and sandbox troubleshooting [#preview-and-sandbox-troubleshooting] Start from the surface that owns the failure: * Repo configuration problem: [Projects](/web/spaces) * Runtime already exists but looks stuck: [Sandboxes](/web/sandboxes) * Need the call or job trail behind the runtime: [Observability](/web/observability) * Account lacks managed sandbox access: [Plans & Billing](/plans-and-billing) Common failure modes: * **Sandbox launch says access is unavailable**: the account plan may not include managed sandbox access yet. * **Preview opens the wrong app**: set the repo root directory, install command, dev command, and dev port explicitly. * **Env values are missing**: inspect env mapping mode, linked Vercel project state, and manual repo variables in Projects. * **Runtime exists but workspace open lands wrong**: open the workspace from [Sandboxes](/web/sandboxes) so it binds to the exact sandbox instance. ## Read next [#read-next]