Migrate from Vercel to Temps
To move a Next.js app from Vercel to Temps: install Temps on your server, import the project's environment variables (with bunx @temps-sdk/cli migrate run -s vercel or vercel env pull --environment=production), replace any Vercel storage, deploy from the same Git repository, test on the preview URL, then point DNS at your server. Most apps need no code changes; the exceptions are listed below.
This page is the Temps-specific procedure. For the decision of whether to leave Vercel at all, and the other self-hosting options, see Migrate from Vercel to self-hosted. For what you pay today, see the Vercel pricing guide; for a feature-by-feature comparison, see Temps vs Vercel.
What transfers without changes
Temps builds your app and runs it with next start, so these work as they do on Vercel:
- Static pages (SSG) and server-side rendering (SSR)
- API routes and Route Handlers
- App Router and Pages Router
- Middleware (redirect/rewrite logic), running in the Node.js server
- Image optimization (
next/image), handled by the Next.js server in your container - Environment variables
What works with caveats
| Vercel feature | On Temps |
|---|---|
| Incremental Static Regeneration (ISR) | Works, but the cache lives inside the container: it starts empty after each deploy and isn't shared between replicas. Use a custom Next.js cache handler if you need a shared cache. See ISR and caching. |
vercel.json crons | Move them to cron: entries (path + schedule) in .temps.yaml. Temps calls the path over HTTP with a CRON_SECRET bearer token, like Vercel does. See Cron jobs. |
vercel.json redirects, rewrites, headers | Move them to redirects(), rewrites() and headers() in next.config.ts. Temps doesn't read vercel.json. |
vercel.json function settings (maxDuration, memory, regions) | Not applicable: your app runs as a long-lived Node.js process. Set CPU, memory and replicas per environment in Scaling. |
What needs an alternative
Vercel-specific services need a replacement before you migrate:
| On Vercel | Temps replacement |
|---|---|
| Upstash Redis (formerly Vercel KV) | Temps managed Redis, or keep Upstash |
| Neon Postgres (formerly Vercel Postgres) | Temps managed PostgreSQL — move the data with pg_dump / pg_restore — or keep Neon |
| Vercel Blob | Temps managed S3 storage, or another S3-compatible store |
@vercel/analytics | Temps web analytics, built in |
| Speed Insights | Core Web Vitals in Temps analytics, built in |
| Edge Runtime and Edge Functions | Node.js runtime. Temps has no edge functions. |
Vercel KV and Vercel Postgres are no longer Vercel products: Vercel moved existing KV stores to Upstash Redis and Postgres databases to Neon in December 2024, and new stores come from the Vercel Marketplace. If your project still uses them, it's talking to those providers.
If your app uses none of these, you can migrate with no code changes.
Pre-migration checklist
Before starting, confirm:
- You have SSH access to a server (Ubuntu 22.04+ recommended) or Temps is already installed
- You control the DNS for your domain
- You have a Vercel access token (for the CLI import) or your environment variables exported (see Step 1)
- Any Vercel-specific packages are swapped or removed
Step 1: Import environment variables and domains
Fastest path: the CLI import. The Temps CLI can read a Vercel project directly. It asks for a Vercel access token (and your team, if the project belongs to one), then lists your projects, shows a plan and creates the Temps project with its environment variables and domains:
bunx @temps-sdk/cli migrate run -s vercel
The Vercel import is interactive: you can edit the plan before it runs, and nothing is created until you confirm (decline at the final prompt to only see the plan). It creates matching managed services for databases it detects from your variables, but it does not copy their data, and the Projects → Import wizard in the dashboard doesn't list Vercel yet (the CLI talks to Vercel's API directly).
Manual path: pull the variables with the Vercel CLI and import the file into Temps.
- 1
Open your project in the Vercel Dashboard.
- 2
Go to Settings then Environment Variables.
- 3
Download the variables so you can import them into Temps.
# Via Vercel CLI: name the environment, the default is Development
vercel env pull .env.production --environment=production
Without --environment, vercel env pull downloads the Development variables, which are usually not the values your production app runs with. Repeat with --environment=preview (and a different file name) for your preview environment.
Check the file before you import it. Vercel stores Production and Preview variables as Secret by default, and the CLI cannot read Secret values back: it writes a placeholder for each one. Copy those values from your password manager or secret store instead, and set them in Temps one by one:
bunx @temps-sdk/cli environments vars set STRIPE_SECRET_KEY "sk_live_..." -p my-app -e production
Import the rest of the file with bunx @temps-sdk/cli environments vars import .env.production -p my-app -e production, or paste the variables into Project → Settings → Environment Variables. You can also read the non-secret values in Vercel Dashboard → Project → Settings → Environment Variables.
Step 2: Check your Next.js config
You don't need to change next.config.ts. Temps builds your app and runs it with next start on Node.js 22, so output: 'standalone' isn't required. See Deploy Next.js for how Temps runs Next.js.
Step 3: Deploy to Temps
- 1
Go to Projects then click New Project.
- 2
Select your repository and the main branch.
- 3
Click Deploy — Temps auto-detects Next.js and sets the build and start commands.
# Install Temps on your server if not already installed
curl -fsSL https://temps.sh/deploy.sh -o deploy.sh
less deploy.sh
bash deploy.sh
Then connect your repository:
- Open the Temps console and go to Projects → New Project
- Select your repository and the
mainbranch - Click Deploy — Temps auto-detects Next.js and sets the correct build and start commands
Add your environment variables under Project → Settings → Environment Variables before the first deploy, or the build may fail. If you created a managed database, link it to the project; Temps injects POSTGRES_URL for PostgreSQL and REDIS_URL for Redis, so point your code (or your existing variable) at those.
Step 4: Verify before cutting over
Once the first deploy succeeds, your app is reachable on its Temps URL — a subdomain of your server's sslip.io address (for example my-app.203-0-113-1.sslip.io) or of the wildcard domain you configured (see Networking). Verify:
- Pages load correctly
- API routes respond
- Auth flows work end-to-end (add the Temps URL to your OAuth callback allow-lists while testing)
- Environment-dependent features function as expected
Only proceed to DNS cutover after this verification passes.
Step 5: Cut over DNS
- 1
Open Project then Settings then Domains and click Add Domain.
- 2
Temps shows the DNS records to add (an A record or CNAME).
- 3
Update your DNS registrar — propagation takes 1–5 minutes at a TTL of 60 seconds or less.
From the CLI, attach the domain to the project with custom-domains create (find the numeric ID with bunx @temps-sdk/cli projects show -p my-app --json):
bunx @temps-sdk/cli custom-domains create --project-id <id> -d app.example.com -y
bunx @temps-sdk/cli custom-domains list --project-id <id>
Don't use domains add for this step: it registers a global SSL domain and does not attach that domain to a project.
- Go to Project → Settings → Domains → Add Domain in the Temps console
- Temps shows the DNS records to add (A record or CNAME)
- Update your DNS registrar — propagation takes 1–5 minutes when your TTL is 60 seconds or less
- Temps automatically provisions a TLS certificate via Let's Encrypt
Set your DNS TTL to 60 seconds a few hours before cutting over. This limits how long any cached records point to Vercel during the transition.
Rollback plan
If something goes wrong after cutting DNS:
- Point your DNS back to Vercel's IP/CNAME — your Vercel deployment is still live until you delete it
- Investigate the issue on Temps using Project → Logs
- Re-deploy after fixing the issue, then cut DNS again
Keep your Vercel project active for at least 48 hours after a successful migration before removing it. Once you're on Temps, error tracking and uptime monitoring replace the Vercel dashboards you used to watch.