> ## Documentation Index > Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt > Use this file to discover all available pages before exploring further. # Vercel to Ankra > Move a Vercel project, usually Next.js, onto your own Kubernetes cluster - start from the Vercel project page with the Ankra Chrome extension, review one Launch Plan that says per service what stays at Vercel and what Ankra runs open source, approve once, and keep API routes, middleware, cron jobs and environment variables working. Vercel builds and serves your project from its own platform. Ankra builds the same GitHub repository and runs it on your own cluster, behind HTTPS, with every change built and scanned first. You keep pushing to the same repository. Ankra builds every commit. *** ## What moves, and what it becomes | On Vercel | On Ankra | | - | - | | Next.js build | One container image. When `next.config` sets `output: 'standalone'`, the image carries only the standalone server, its static assets and `public/`. Otherwise it runs `next start` | | API routes, route handlers, middleware, edge routes | Served by the Next.js server in that container. Nothing to split out | | `vercel.json` crons | One Kubernetes CronJob per cron entry. It calls the same route on the same UTC schedule, with the `vercel-cron/1.0` user agent and `Authorization: Bearer ` when the app has a `CRON_SECRET` secret, so a route that checks it keeps working | | `vercel.json` rewrites, redirects and headers | Listed in the setup pull request. Vercel applied them at its edge; on Ankra your own server serves every request, so move them into `next.config` (`rewrites()`, `redirects()`, `headers()`) before you move traffic | | Project environment variables | The application's environment secrets. Bring them over with the extension (below) or enter them in Ankra | | Preview deployments | [Preview demos](/concepts/applications#preview-demos) on a preview address | | Your domain | Your own domain with its certificate on the cluster ([Applications](/concepts/applications)) | The setup pull request contains the Dockerfile, the Kubernetes manifests, the CronJobs, the deploy options (`.ankra/ankra.yaml`) and the build pipeline (`.ankra/pipeline.yaml`). Ankra's AI writes it when you add the repository. You review and merge it. *** ## Vercel storage in the Launch Plan Ankra reads which Vercel storage the code uses and puts one card per service in the project's Launch Plan. Each card shows how locked in the service is and which choice applies by default. You can change the choice. | Vercel service | Default | What you can choose instead | | - | - | - | | Vercel Postgres (`@vercel/postgres`) | Keep it: `POSTGRES_URL` stays an environment secret | A portability pull request switches to a plain Postgres driver on one connection string, then Ankra runs CloudNativePG in your cluster | | Vercel KV (`@vercel/kv`) | Keep it | A portability pull request moves to a Redis client on `REDIS_URL`, backed by Valkey in your cluster | | Vercel Blob (`@vercel/blob`) | Keep it | A portability pull request moves uploads to the S3 API, backed by object storage in your cluster | | Edge Config (`@vercel/edge-config`) | Keep it | A portability pull request reads the same keys from environment variables, delivered as a ConfigMap | A portability pull request is opt-in. It adds the open-protocol path beside Vercel's, and the app keeps using Vercel until you set the new variables. Data is not copied for you. *** ## Start from the Vercel project page The **Ankra — Chat & Deploy** extension for Chrome puts an **Ask Ankra** button on your Vercel project page, and also on Lovable, Claude Design and GitHub repository pages. See [install the extension](/use-cases/lovable-to-ankra#install-the-extension-without-the-chrome-web-store). **1. See where the project stands** The button carries a status pill for the project's repository: **Not connected**, **Analysing**, **N decisions**, **Ready to approve**, **Proving**, **Proof failed** or **Live**. The same pill appears on the repository's GitHub pages. **2. Review the Launch Plan** Open **Deploy project**. The extension fills in the GitHub repository the Vercel project builds and its branch. The **Launch Plan** panel lists: * the decisions only you can make, with their defaults * per external service, what stays at Vercel and what Ankra runs open source * the result of the proof run of the setup pull request To change a decision, use **Change decisions in Ankra**. All configuration stays in Ankra. **3. Bring your variables** Under **Bring variables from Vercel**, paste a Vercel access token for the project's team and choose **Read variables**. The token is used from your browser only and is not stored or sent to Ankra. By default you get the names of the project's production variables, marked by whether Ankra already has each one. Tick the box to copy the values into the application's encrypted secrets. Values Ankra already holds are never overwritten. Variables marked sensitive on Vercel cannot be read back, so enter those in Ankra. Values can be copied once Ankra has registered the application, which happens on the first deploy. **4. Approve** Click **Approve and deploy**. Ankra registers the application, opens the setup pull request, builds and scans the image, and deploys it with the plan's choices. If the setup pull request or the first build is still pending, the request waits and is sent when Ankra is ready. > [!NOTE] > > Test on the Ankra address before you move your domain. Check the cron routes, the rewrites you moved into `next.config`, and every variable your app reads. *** ## From the CLI ```bash theme={null} ankra application add . --branch main ankra chat "show me the Launch Plan of " --mode ask ``` Run the first command in a local checkout of the repository. See [Applications](/concepts/applications) and [Lovable to Ankra](/use-cases/lovable-to-ankra) for the rest of the flow, from the setup pull request to automatic deploys. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.