What you can export from Vercel, and what you cannot
If a renewal, a billing change or a residency rule is forcing you off Vercel, most of your configuration and your Blob files can be pulled out, but Secret environment variables cannot be read back, and database data lives with Marketplace providers such as Neon, Upstash and Supabase, so you export it from them directly. The export is not one archive. It is a set of separate paths, each with its own tool and its own owner, and you should plan the inventory around that split before anyone starts copying data.
Start with environment variables. Running vercel env pull writes the project's variables to a local file, but variables of the Secret type, which is the default for Production and Preview, cannot be read from Vercel. The CLI writes a placeholder in their place when no local value exists, so the reader must treat those keys as values to recover from a password manager, a secrets store or the original source. For Blob, the SDK's list() call returns up to 1,000 objects by default and pages through larger stores with cursor and hasMore values, and the CLI offers vercel blob list for an inventory. Confirm the exact paging behavior against the current Vercel Blob SDK reference before you script the copy.
Database exports belong to each provider's console and tooling, and your team should confirm which account owns each resource. Build settings, custom domains and DNS records, preview deployments, rollback history, cron and team roles are not in any export file, so each needs a written rebuild list with an owner. Check the Marketplace resource and store settings for transfers between accounts or teams as well, since Vercel documents moving Blob and Global Config stores that way, and confirm what your contract and plan still allow during the notice period.
Which Vercel data has a documented export path
This table maps each category of Vercel data to the documented method for getting it out, the format or limit to plan for, and what still needs manual work. Read it as a checklist: anything marked as a placeholder or handled by a Marketplace provider needs its own export step before you cancel the project.
| Data type | Documented method | Format and limits | What still needs manual work |
|---|---|---|---|
| Environment variables (non-Secret) | vercel env pull writes project variables to a local .env file | Plain key-value text in a .env file | Check each variable's scope (Production, Preview, Development) before reusing it |
| Environment variables (Secret) | vercel env pull, which cannot read Secret values | The CLI writes a placeholder when no local value exists | Re-enter every Secret value from your own source of truth, such as a password manager |
| Blob objects | Blob JavaScript SDK list() call and the vercel blob list command | list() returns up to 1,000 objects per call by default, paged with cursor and hasMore | Loop until hasMore is false, then download each object and check the count against your inventory |
| Blob and Global Config stores (account move) | Transfer from the store's settings page in Vercel | Transfers between accounts and teams, not an export file | Confirm the target account can receive the store and update any tokens that point to the old owner |
| Marketplace databases (Neon, Upstash, Supabase) | Export through the provider's own tools, since the data lives with that provider | Format depends on the provider, not on Vercel | Confirm backup and dump options with the provider, and check whether the Vercel integration can be moved between teams |
| Marketplace resources (team transfer) | Transfer from the resource's settings page between teams | Transfers between teams, not a data export | Verify that connected projects and environment variables still resolve after the move |
| Deployments, domains and build settings | Not part of the data export paths described above | Configuration held in the Vercel dashboard and project settings | Record project settings, domains and rollback targets by hand and rebuild them on your target platform |
What does not come out of Vercel and the workaround for each
Vercel's CLI and storage tooling move some data out, but several items stay behind or need rebuilding. Each card below names one gap, the reason it matters for your export, and the step that closes it. Treat the list as a checklist to run before any cutover, because a missed item often surfaces only after DNS has moved.
Secret environment variables
Variables set as Secret, the default type for Production and Preview, cannot be read back, so vercel env pull writes a placeholder when no local value exists. Retrieve each value from the system that issued it, such as the database, payment or API provider, and re-enter it in your own secrets store. Before cutover, list every placeholder the pull produced and confirm each one has a verified value.
Deployment history and rollback targets
Past deployments and their build outputs are tied to Vercel's infrastructure and do not transfer as runnable artifacts. Your rollback path on the new platform starts from the images or commits you build there, so the first deploy on the new host is your baseline. Record the Git commit and environment set for the last known good production release before you leave.
Domains and DNS configuration
Domain assignments, redirects and DNS records that point at Vercel are managed in Vercel's dashboard and do not move automatically. Export the zone you control and note every record Vercel asked you to create, including any for certificates. Plan the cutover with lowered TTLs and confirm the new proxy issues certificates for each hostname before switching traffic.
Build and function settings
Build commands, output directories, Node.js runtime versions, function memory and timeout limits, and cron or routing rules live in project settings or vercel.json. Vercel does not provide a configuration export that replaces them, so read each setting from the dashboard and the repository. Write the values into your Dockerfile or Coolify build configuration and test each function path.
Preview deployment state
Preview deployments, their URLs, branch aliases and comments exist only inside Vercel and are not part of a data export. Nothing needs to move, but open pull requests will lose their preview links at cutover. List the branches that need previews, then rebuild that flow on the new host and tell reviewers where the new URLs will live.
Sequence for a complete export, with verification at each step
This sequence moves a Vercel project's configuration, files and databases out in an order that makes each stage checkable before the next begins. The output is a written inventory and a set of exported artifacts, each with a verification record, that a new platform can be rebuilt from.
Inventory every project, store and integration
The account owner or a project admin lists each Vercel project, each team, every Blob and Global Config store, every Marketplace resource, and the domains, build settings, cron jobs and preview configurations attached to each project. Record which resources belong to which team, because store transfers and Marketplace moves happen per team. The step is done when the inventory is a single document that every later step checks against, with each row marked as a source of data, configuration or a manual rebuild item. Confirm the account and team list in the dashboard rather than relying on memory.
Pull environment variables per environment
Run vercel env pull once for each environment (Development, Preview and Production) in each project directory, writing the values to a local .env file that is kept out of version control. Secret variables, which are the default type for Production and Preview, cannot be read back from Vercel, so the CLI writes a placeholder where no local value exists. Open each file and compare its key count with the dashboard, then add a column to the inventory that marks every variable as readable or Secret. Values that are Secret must be retrieved from the team that set them, from the source system that issued them (such as a payment or email provider), or re-generated, and the inventory should name the owner for each one.
Paginate and download every Blob object
Use the Blob SDK's list() call in a loop, passing the cursor from each response back into the next request, until hasMore is false. The default page returns up to 1,000 objects, so a store with more objects needs several pages. Download each object by its URL and write it to storage you control, keeping the pathname as the file path. Compare the total object count from the listing with the number of files written, and where the SDK or the stored metadata provides a checksum or size, compare those as well. The step is complete only when the counts match and a sample of files opens correctly. The vercel blob list command can serve as a cross-check on the count.
Export Marketplace databases through each provider
Vercel does not run the database behind Postgres, Redis or similar Marketplace resources, so the export happens in the provider's console or tooling for Neon, Upstash, Supabase or whichever provider the project uses. Take a logical dump or provider snapshot, and store it with the same care as other production data. Verify the restore on a separate instance before relying on it: compare row counts for the largest tables, confirm the schema and indexes match the source, and check that sequences or key ranges continue correctly. Ask each provider which export formats and retention settings apply to your plan, because these vary by provider and tier.
Rebuild domains, build settings and previews by hand
Vercel's exports do not recreate domains, DNS records, build commands, output directories, Node.js versions, cron schedules, rewrites and headers, or preview deployment rules in another platform, so these are recorded from the dashboard and project settings and rebuilt on the target. For each domain, note the DNS provider and the records needed, and plan the cutover with lowered TTLs in advance. Confirm each rebuilt setting by running a build on the target and comparing the response headers, redirects and rendered routes with the Vercel production site. The step is complete when a checklist shows every item as rebuilt and tested, with preview behavior checked against a sample pull request.
Reconcile the export against the inventory
Before any cutover or account closure, the team goes back through the inventory and confirms that every row has an outcome: a verified export file, a rebuilt configuration tested on the target, a named owner for each Secret value, or a documented decision to drop the resource. Keep the verification records, including counts, checksums and restore results, in a location that survives the Vercel account. Ask the reader's own security or compliance team which records they need to retain. The output is a signed-off reconciliation that shows what moved, what was rebuilt and what remains with a third party.
What has to be rebuilt by hand in the new platform
Exporting data covers only part of the move. Build commands, framework settings, custom domains, redirects, headers, cron-style jobs and preview URL conventions do not come out of Vercel as files you can import, so your team has to recreate each one in the target platform. Start with an inventory: for every Vercel project, record the install and build commands, the output directory, the Node version, the domain and DNS records, the vercel.json rules for redirects and headers, any scheduled invocations, and the URL pattern your previews use. Compare that list with what your target platform needs before you change any DNS record.
Coolify's migration guide for teams leaving managed platforms is the official reference for mapping Vercel concepts such as functions, previews, domains and rollbacks to Coolify equivalents. Treat it as the checklist for the mapping, then test each item in a staging copy. Preview URLs deserve particular attention: Coolify's default pattern depends on wildcard DNS, so a preview that worked on Vercel will not appear until that DNS record exists.
Rollback needs a separate check. In Coolify, a rollback can redeploy a retained application image, but it does not restore databases or persistent files. A rollback therefore returns code to a previous state while your data stays where it is. Before cutover, restore a recent database backup into a scratch instance, confirm that uploaded files exist on the new server, and write down who owns the restore procedure. These checks are your responsibility once the platform is self-hosted, and they should be repeated on a schedule, not only once.
What to plan before the Vercel contract ends
The export itself is the easy part. The risk sits in the timing: when notice is due, how long the old and new stacks run side by side, and which stores keep billing or holding data after the last deploy. Confirm each item against your own contract and account before you set a date.
Confirm the notice and billing timeline
Read your own Vercel agreement for the notice period, the renewal date, and how usage overage is invoiced in the final cycle. No public dates are supplied for this page, so ask Vercel in writing for the end-of-term date and whether any credits or committed spend carry over. Also check whether Marketplace charges are billed by Vercel or directly by each provider, since that changes who you must notify.
Freeze environment variable changes
Decide a point after which no one edits Production or Preview variables in the Vercel dashboard, because a change made after your export will be missing from the copy. Remember that Secret variables cannot be read back, so the values for those must come from the team that originally set them or from a secrets manager. Record which variables are Secret before the freeze so you know which ones need a sourced value.
Provision the target server and databases
Build the new server, the database instances and the object storage in parallel with the existing app, rather than waiting for the notice date. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on each server, so size from your measured Vercel usage and expected traffic. Run a restore test of the database backup before you rely on it for cutover.
Plan the DNS cutover and rollback window
Lower the TTL on the production records well ahead of the switch, and keep the Vercel project live until the new stack has served real traffic. Confirm the window in which you can point DNS back to Vercel if the new deployment fails. Once Vercel is removed, that fallback is gone, so set the removal date only after the rollback window has closed. Check that wildcard DNS and TLS certificates are in place for the new proxy.
Retain Blob and Marketplace data
Blob stores and Marketplace databases do not move with the Vercel project automatically. Blob data can be listed through the SDK or the CLI and copied to storage you run, and Marketplace databases live with the provider, such as Neon or Upstash, so their data stays there until you export it. Agree on how long each old store is kept and who signs off on deletion, and confirm the retention and export terms with each provider.
Remove Marketplace integrations
Uninstall each Marketplace integration only after its data is copied and verified, because removing the integration may delete the resource on the provider side. List every integration on the team, note which ones bill separately, and cancel them one at a time. Check that no webhook, cron or environment variable still points at a provider endpoint you have removed, so that nothing fails silently after cancellation.
Questions teams ask before exporting from Vercel
How much effort does exporting from Vercel usually take?
The effort depends mostly on what is stored and how many places it lives, not on the export tools themselves. The main drivers are the number of projects and environments, how many environment variables are Secret type, the number of Blob objects, and how many databases sit with Marketplace providers such as Neon or Upstash. Each Marketplace database has its own export path with its provider, so each one adds a separate task. Ask for an inventory of projects, environments, variable counts by type, Blob object counts and Marketplace resources before estimating anything. That inventory turns an open-ended question into a bounded list of work items.
Can our team export from Vercel without outside help?
Often yes, for a small estate with a few projects and modest storage, provided the team has owner access and someone who can run the CLI and SDK scripts. Environment values that are Secret cannot be read back through vercel env pull, so those values must come from the people or systems that originally set them, such as a password manager, a cloud secrets store or the original developer. Databases need provider-side export tooling, and the work includes rebuilding build settings, domains, cron jobs and rollback procedures by hand. Teams with many projects, compliance evidence needs or tight cutover windows usually find the verification work is what takes the most time.
What do we need to provide before an export starts?
Start with access and decisions, because most delays come from waiting on them. You need Vercel team owners who can read settings and approve transfers, administrative accounts at each Marketplace provider such as Neon or Upstash, and access to the DNS zones for every domain. You also need a staging target on servers or a cloud account you control, with a named owner for secrets and a decision on whether Secret values will be re-entered or sourced from a vault. Agree on a rollback path and a freeze window for writes to the source databases before the work begins.
How long does an export take?
The duration is set by data volume and verification, not by the number of commands. Small configuration exports can be finished in a short working session, while large Blob stores and databases take longer because copies, checksums and restore tests run at the speed of storage and network links. Verification usually takes more time than the copy: confirming object counts against the listing, comparing row counts and checksums, and checking that the staged application reads every secret and file correctly. Ask for a schedule that separates the copy, the verification and the cutover so each stage has its own exit criteria.
Will the export move our Blob files and Marketplace databases too?
The Vercel Blob SDK lists objects and pages through larger stores with cursor and hasMore values, and the CLI offers vercel blob list, so you can enumerate every object before copying. Vercel's storage documentation also describes transferring Blob and Global Config stores between accounts and teams, which matters if the destination is another Vercel team. Databases are different: they live with the Marketplace provider, not inside Vercel, so the export runs through that provider's own tools. Confirm with each provider which dump formats and access rights apply to your plan before you plan the copy.
Can DeployOpen run the Vercel export under a fixed-scope agreement?
Yes. DeployOpen plans, implements and documents self-hosted platform migrations inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope. The written scope would list the projects, Blob stores and Marketplace databases in use, the target platform, the verification steps and the handover documents. DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and testing after cutover can be added as a retainer. Your own owners remain responsible for vendor accounts, DNS decisions and any compliance attestations, which independent auditors issue.
What should a quote for the export include?
A useful quote separates one-time work from recurring costs and states what it assumes. Ask for the inventory counts it is based on, the list of Marketplace databases and their export method, how Secret variables will be sourced, how Blob objects will be verified, and what the cutover and rollback steps include. Recurring costs to request explicitly are server or cloud hosting, backup storage, and any support retainer. Ask which items are excluded, such as provider plan changes, data cleanup or application code changes, so the comparison with the current Vercel bill stays fair.
Which costs recur after you leave Vercel and which are one-time
The one-time costs of leaving Vercel are the work to inventory and move data, and they end once cutover is complete. Start with an inventory of every project, environment variable, Blob store, Marketplace resource, domain and preview setup. Scripting the Blob export is a real line item: list() returns up to 1,000 objects by default and pages through the rest with cursor and hasMore values, so the script must loop until hasMore is false and verify object counts and sizes against the source. Database migration is the other large one-time item. Postgres, Redis and similar data sits with a Marketplace provider such as Neon or Upstash, so the effort depends on that provider's export tooling, your schema and downtime tolerance. Rebuilding domains, previews and rollback paths, plus cutover testing with DNS staged ahead of the switch, round out the one-time work. Ask any implementation partner to price these as a fixed scope with written deliverables, and ask which items they count as one-time versus ongoing support.
The recurring costs move to your side of the line and fall into several groups: servers, backups, patching, monitoring and on-call. Server costs depend on how many applications, databases and preview environments you run, how many nodes you need for redundancy, and whether you use a managed control plane such as Coolify Cloud or self-host it. Backup costs depend on retention policy, storage location and how often you test restores, since a rollback to a retained application image does not restore databases or persistent files. Patching and monitoring recur with every OS, Docker and proxy update, and on-call cost grows with how many services page your team. Ask each vendor or partner to state which of these they bill, which they leave to you, and what support level is included. Check current Vercel billing on its pricing page so your comparison uses today's metered usage rather than memory, and keep that comparison line by line.
How DeployOpen scopes and delivers a Vercel data exit
DeployOpen plans and implements the export of configuration, storage and database data out of Vercel into self-hosted systems inside your own infrastructure. Engagements are fixed-scope, so the inventory, deliverables and handover are agreed in writing before any data moves.
How we scope
- Inventory every Vercel project, team and environment that holds variables, Blob stores or Marketplace resources
- Record which Secret variables must be re-entered from source systems, since Vercel will not return their values
- Agree in writing which databases come from Marketplace providers such as Neon or Upstash and where they will land
How we build
- Script environment variable capture with vercel env pull and document every placeholder that needs a real value
- Copy Blob objects with the SDK's paginated list, verifying counts and checksums against the source store
- Restore databases to your chosen target and rebuild domains, cron jobs and build settings by hand where no export exists
How we hand over
- Deliver a written runbook covering each export step, its owner, and the rollback path if a copy fails
- Document the rebuilt configuration so your team can confirm parity with the original Vercel projects
- Provide evidence of each transfer step so your auditors and security reviewers can trace data movement
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the export is complete
- Keep backups and restore tests in scope for the self-hosted systems that now hold the data
- Confirm with your team which support boundary, response expectations and retainer terms apply before work starts
