Migrate from Vercel to Cloudflare
Orunbase gives you a Vercel-style workflow on accounts you own: a merge to main deploys stage, checks it, and deploys prod, with your app running on your own Cloudflare account and, if it needs Postgres, your own Supabase project. Builds and deploys run in your repository's own GitHub Actions. Cloudflare and Supabase bill you directly for what the app uses.
There are two ways in: start from one of the Vercel templates the registry has already ported to Cloudflare, or bring an app you already run on Vercel, which your coding agent can port for you.
What maps to what
| On Vercel | Here |
|---|---|
| A push deploys | A merge to main deploys stage, runs its smoke check, then deploys prod |
| A preview per branch | Each pull request is built and its deploy is dry-run; its plan lists what the merge will ship. There are no per-branch URLs today |
| Next.js, Astro, Nuxt, SvelteKit | The same frameworks on Cloudflare Workers, through OpenNext or each framework's Cloudflare adapter |
| Vercel Blob, KV, Postgres, Cron | R2, Workers KV, Supabase through Hyperdrive, Cron Triggers |
| Project environment variables | Worker variables and secrets per environment; credentials minted from your workspace's connections |
| Deployments and logs | Runs and their logs in the console |
Before you start
- A workspace on any plan. The Free plan covers up to three repositories; custom domains need Pro or above (plans).
- A Cloudflare account. Server-rendered apps need the Workers Paid plan (from $5 a month): the free plan allows 10 ms of CPU per request.
- The Orunbase GitHub App installed on the GitHub organisation the repository lives in (GitHub integration).
- A Supabase organisation, only if the app uses Postgres.
Connect Cloudflare, and Supabase if you need it, in the console under Integrations, or from the CLI by token paste (connecting providers):
orun integrations cloudflare connect --workspace acme < cloudflare-token.txt
orun integrations list
Deploy jobs never see that token. Each one gets a short-lived credential minted from the connection by the credential broker.
Start from a ported Vercel template
orunbase.com/baselines/vercel-templates lists every Vercel template the registry has ported to Cloudflare Workers: Next.js, Astro, Nuxt, SvelteKit and Hono apps, AI apps, storefronts, blogs, SaaS starters and storage examples. Each one builds into a new repository you own, with the app, the Terraform for what it needs, and CI that deploys stage and prod on every merge.
Build one from the console's guided flow (build from the console) or from the CLI (build from the CLI). The template's page on orunbase.com says what it needs and how long it takes to go live.
Bring your own app
There are two ways to move an app you already run on Vercel: hand it to your coding agent, or make the changes yourself.
With your coding agent
vercel-to-orun is one of Orunbase's default skills: a playbook your coding agent follows to port a Vercel app to Cloudflare Workers, with Supabase when the app needs Postgres. Give the agent the repository's URL and it:
- surveys the app and writes a port plan: the adapter for its framework, what replaces each Vercel feature, and which credentials it will need from you;
- creates a new repository with the app's history, and a workspace for it, so the Vercel project keeps running untouched;
- makes the changes Workers need, then builds the app and checks its routes on Workers' own runtime, locally;
- adds the
intent.yaml, the components, the Terraform and the CI, and lands each step as a pull request; - deploys stage and prod, checks both live, and writes a report of what changed and what is left.
To use it:
- Connect the agent to Orunbase with the agent setup prompt. It works in Claude Code, Codex, Cursor and VS Code, and installs the default skills,
vercel-to-orunamong them. - Install the
orunCLI and sign in. The skill uses it to create the workspace and plan the deploys; the last section of the setup prompt shows how. - Connect Cloudflare, and Supabase if the app uses Postgres, as in Before you start.
- Ask the agent, for example: "Port github.com/acme/storefront from Vercel to Orunbase."
To find out what a move would take before you make it, ask "Can github.com/acme/storefront run on Cloudflare?" instead. The skill stops after the survey and the port plan, and changes nothing.
The agent asks before it writes secrets to your workspace, and never invents a credential. Where the app needs a key only you hold, such as a payment or auth provider's, it wires the setting, ships what works without it, and lists the key in its report. Parts that cannot run on Workers, such as Python functions or a WebSocket server, are named in the plan rather than dropped.
The skill is plain text: read it at orunbase.com/skills/vercel-to-orun/SKILL.md.
By hand
Moving an existing app by hand takes four steps.
1. Make the app run on Workers
Build it with a Cloudflare adapter instead of Vercel's, swap Vercel storage for R2, Workers KV or Supabase, and move environment variables into Worker variables and secrets. The Vercel to Cloudflare migration guide goes through each change, with the limits to watch for.
2. Declare the repository's intent
Add an intent.yaml at the repository's root, which names the workspace, the environments (stage and prod) and which events deploy them, and a component.yaml beside the app, which names its golden path. A Next.js app built with OpenNext uses cloudflare-workers-assets-turbo:
apiVersion: sourceplane.io/v1
kind: Component
metadata:
name: web
spec:
type: cloudflare-workers-assets-turbo
subscribe:
environments:
- name: stage
profile: verify
profileRules:
- profile: deploy
when: { triggerRef: github-push-main }
- name: prod
profile: verify
profileRules:
- profile: deploy
when: { triggerRef: github-push-main }
parameters:
nodeVersion: "22"
pnpmVersion: "10.12.1"
workspaceDir: ../..
appDir: .
turboFilter: "@app/web"
wranglerConfig: wrangler.jsonc
workerName: my-app-web
environmentAwareWorkerName: true
workerEntrypoint: .open-next/worker.js
assetsDir: .open-next/assets
The quickest start is to copy intent.yaml, the app's component.yaml and .github/workflows/ from the ported template closest to your framework, then change the names. The template's files already carry the trigger bindings, the promotion from stage to prod, and the CI that runs orun plan and orun run. The intent model and compositions explain each field.
3. Link the repository
Link the repository to the workspace so its runs and catalog are recorded there:
orun cloud link --workspace acme --project my-app
See orun cloud for what the link allows, and state plane for the two kinds of repository link.
4. Merge to deploy
Open a pull request. CI builds the app and dry-runs the deploy, and orun plan shows the jobs the merge will run. Merge it, and CI deploys stage, runs the smoke check, then deploys prod. Every run, with its logs, is in the console. Once the app is healthy on its workers.dev address, attach your domain and move DNS.