• The user explicitly asks to migrate, move, or deploy from Vercel to CreateOS.
• The user expresses intent to leave Vercel (pricing, reliability, security, ownership concerns).
• The repository contains a

  vercel.json

  ,

  .vercel/

  directory, or

  @vercel/*

  dependencies in

  package.json

  .
• The user asks for a "Vercel alternative" or references the April 2026 Vercel security incident.

• The user is deploying a fresh project with no prior Vercel deployment — use the standard

  createos

  skill instead.
• The project is a pure Next.js application with heavy dependencies on Vercel-specific features (Edge Middleware, Vercel KV, Vercel Blob, Vercel Postgres). Surface compatibility notes before proceeding.

1. A CreateOS account — if not, direct them to

   https://createos.nodeops.network

   to sign in via Email, GitHub, Google, or Wallet.
2. CreateOS MCP connected OR a

   CREATEOS_API_KEY

   environment variable set.
3. Access to their current Vercel project's environment variables (they may need to export these from the Vercel dashboard).
4. GitHub repository access for the project (CreateOS deploys from GitHub for VCS projects).

Export your Vercel environment variables by running

vercel env pull .env.vercel.backup

in your project directory, or download them from Project Settings → Environment Variables in the Vercel dashboard. Keep this file local and do not commit it.

• vercel.json

  — build, routing, function, and header configuration

• package.json

  — detect framework, build scripts, and Node.js version

• next.config.js

  /

  next.config.mjs

  /

  next.config.ts

  — Next.js specific configuration

• .nvmrc

  — Node version pin
• Any

  .env*

  files for reference (do NOT read secrets; only note which keys exist)

Detected project:
- Framework: [Next.js 14 / Vite / Remix / etc.]
- Node version: [20.x]
- Build command: [npm run build]
- Output directory: [.next]
- Environment variables needed: [count, with names — NOT values]
- Vercel-specific features in use: [list any edge middleware, KV, blob, etc.]

source

settings

1. Call

   ListConnectedGithubAccounts

   to verify GitHub is connected. The response includes the

   installationId

   you need for the next call. If no accounts are connected, call

   InstallGithubApp

   and pause for user action.
2. Call

   ListGithubRepositories(installationId)

   and confirm the target repo with the user. Capture the repo's

   id

   — that is the

   vcsRepoId

   .
3. Call

   CheckProjectUniqueName({uniqueName})

   to validate the proposed project name.

   uniqueName

   must match

   ^[a-zA-Z0-9-]+$

   , 4–32 chars.
4. Call

   CreateProject

   with the nested

   source

   /

   settings

   shape. Two valid patterns — pick one:
   Pattern A — Build AI (recommended default). Use this when you cannot derive exact

   installCommand

   /

   buildCommand

   /

   runCommand

   from

   vercel.json

   +

   package.json

   with high confidence. CreateOS auto-detects from the repo:
   json

   CreateProject({
     "uniqueName": "<derived from project name>",
     "displayName": "<human-friendly name>",
     "type": "vcs",
     "source": {
       "vcsName": "github",
       "vcsInstallationId": "<from step 1>",
       "vcsRepoId": "<from step 2>"
     },
     "settings": {
       "useBuildAI": true,
       "runtime": "<see runtime mapping below — required>",
       "port": 80
     }
   })

   Pattern B — Explicit commands. Use this when

   vercel.json

   gives you concrete commands and a known framework. All command fields, when included, must be non-empty strings — omit fields entirely rather than passing

   ""

   (empty strings cause a 400):
   json

   CreateProject({
     "uniqueName": "<derived from project name>",
     "displayName": "<human-friendly name>",
     "type": "vcs",
     "source": {
       "vcsName": "github",
       "vcsInstallationId": "<from step 1>",
       "vcsRepoId": "<from step 2>"
     },
     "settings": {
       "framework": "<see mapping table below — omit if no slug fits>",
       "runtime": "<see runtime mapping below>",
       "port": 3000,
       "directoryPath": ".",
       "installCommand": "<from package.json or vercel.json installCommand>",
       "buildCommand": "<from vercel.json buildCommand or package.json build script>",
       "runCommand": "<framework default, e.g. 'npm start' for Next.js>",
       "buildDir": "<from vercel.json outputDirectory or framework default, e.g. '.next'>"
     }
   })

   Required-in-practice fields (the API rejects without them, even though some are marked optional in the schema):

   • port

     — always include. Use

     80

     for static-shaped sites,

     3000

     for Node app defaults, or whatever the app actually listens on.

   • runtime

     — always include unless

     framework

     is set (and even then, include it for safety).
   • Either

     useBuildAI: true

     OR a complete command set (

     installCommand

     +

     buildCommand

     +

     runCommand

     ). Mixing partial commands with

     useBuildAI: false

     causes a 400.

CreateProjectEnvironment(project_id, body)

production

description

settings

resources

resources

cpu

memory

replicas

resources

CreateProjectEnvironment(project_id, {
  "displayName": "Production",
  "uniqueName": "production",
  "description": "Production environment migrated from Vercel",
  "branch": "main",
  "isAutoPromoteEnabled": true,
  "settings": { "runEnvs": {} },
  "resources": { "cpu": 200, "memory": 500, "replicas": 1 }
})

cpu

memory

replicas

settings.framework

framework

useBuildAI: true

runtime

buildCommand

runCommand

settings.framework

nextjs

reactjs-spa

reactjs-ssr

vuejs-spa

vuejs-ssr

nuxtjs

astro

remix

useBuildAI: true

runtime: "node:20"

buildCommand: "ng build"

buildDir: "dist/<app>"

runtime: "node:20"

runtime: "node:20"

port: 80

runtime: "static"

type: "vcs"

runtime: "static"

type: "upload"

settings.runtime

.nvmrc

package.json

engines.node

settings.runtime

node:18

node:20

node:22

node:20

node:20

useBuildAI: true

static

.nvmrc

node:20

1. Ask the user to paste their Vercel env var list (names only, NOT values) OR upload the

   .env.vercel.backup

   file.
2. Show them the list and confirm which variables should be migrated. Some Vercel-injected vars do NOT need migration:

   • VERCEL_*

     vars — these are Vercel-specific runtime vars and are not needed on CreateOS.

   • VERCEL_URL

     ,

     VERCEL_ENV

     ,

     VERCEL_REGION

     — handled differently by CreateOS.
3. For each remaining variable, ask the user to provide the value (do NOT log or persist these values in the skill output).
4. Call

   UpdateProjectEnvironmentEnvironmentVariables

   to set them on the

   production

   environment.
5. Remind the user to mark sensitive values (API keys, tokens, database URLs) as sensitive in the CreateOS dashboard for encryption at rest.

1. Call

   TriggerLatestDeployment

   to kick off the first build.
2. Poll

   GetDeployment

   status until the build completes (or fails).
3. If the build fails:
   • Call

     GetBuildLogs

     to retrieve logs.
   • Summarize the failure for the user.
   • Suggest likely fixes based on common Vercel-to-CreateOS migration issues (see

     references/common-issues.md

     if bundled).
4. If the build succeeds, report:
   • The CreateOS deployment URL as returned by the API response (do NOT construct or guess the URL; use the exact

     url

     field from

     GetDeployment

     ). The default subdomain pattern is

     https://[project].createos.nodeops.network

     , but always defer to the API's returned value.
   • Build duration
   • Deployment ID for reference

1. Ask if they want to configure a custom domain now.
2. If yes, call

   CreateDomain

   with their domain.
3. Surface the DNS records they need to configure at their DNS provider (not at Vercel).
4. Advise them to:
   • Test the CreateOS deployment thoroughly at the

     createos.nodeops.network

     subdomain first.
   • Lower their DNS TTL at the current provider to 300 seconds 24 hours before cutover.
   • Keep the Vercel deployment live until the CreateOS deployment is verified.
   • Cut DNS over only when ready.
   • Keep the Vercel deployment active for at least 72 hours post-cutover as a fallback.

• First deployment succeeded on CreateOS
• All environment variables migrated and tested
• Vercel-specific dependencies flagged (and resolved if applicable)
• Custom domain configured (if requested)
• DNS cutover plan understood
• Concierge support contact shared for complex issues

• Docs:

  https://nodeops.network/createos/docs/deploy

• Migration guide:

  https://nodeops.network/createos/docs/Migrations/Vercel

• Concierge migration (for projects that need white-glove support):

  mailto:business@nodeops.xyz

1. The CreateOS project can be deleted with

   DeleteProject

   — no charges are incurred for a project that never successfully deployed.
2. The user's Vercel deployment is untouched throughout this workflow. Nothing in this skill modifies Vercel resources.
3. Offer the concierge migration path as a fallback for complex projects.

• Does not modify or delete anything on Vercel.
• Does not automatically rewrite application code that uses Vercel-specific SDKs — only flags them.
• Does not perform DNS cutover — the user must do this intentionally.
• Does not migrate data from Vercel KV, Postgres, or Blob — data migration requires separate tooling.
• Does not migrate Vercel team members or access controls.

• CreateOS MCP tools reference:

  https://nodeops.network/createos/docs/api-mcp/mcp-operations

• Skill repository:

  https://github.com/NodeOps-app/skills

• Full migration guide:

  https://nodeops.network/createos/docs/Migrations/Vercel