How to Migrate from Vercel to PandaStack

Why teams look beyond Vercel

Vercel is excellent at what it was built for: shipping frontend frameworks, especially Next.js, with a polished DX and a global edge network. If you're building a marketing site or a frontend-heavy app, it's hard to beat.

The friction tends to show up when your app grows a backend that doesn't fit the serverless function model: long-running processes, WebSockets, background workers, a database you want to *manage* rather than glue together from a marketplace, or unpredictable function bills under traffic spikes. Vercel's own [pricing](https://vercel.com/pricing) is usage-based, which is great until it isn't.

This guide walks through moving a typical Next.js or static frontend (plus an API and database) to PandaStack, a container-based developer cloud.

What actually changes

Be clear-eyed about the model shift:

The biggest mental change: instead of deploying functions, you deploy a long-running server (or a static export). For Next.js this means running next start in a container rather than relying on Vercel's function adapter. Static sites export the same way.

Step 1: Inventory your Vercel project

Before touching anything, list:

• Framework + build command (next build, vite build, etc.)
• Environment variables — pull them all from the Vercel dashboard or vercel env pull .env.local
• Serverless / edge functions — note any /api routes or edge middleware
• Custom domains and DNS records
• Database / KV — what marketplace add-ons you depend on

# Export your Vercel env vars to a local file
vercel env pull .env.production.local

Step 2: Decide static vs container

Two clean paths:

Static frontend. If your app is a pure SPA or a static export (next export, Vite, Astro, etc.), deploy it as a PandaStack static site. Builds run in pandastack.ai microVMs and the output is served globally.

Full Next.js (SSR/ISR/API routes). Deploy as a container running next start. PandaStack auto-detects Node and the build/start commands, but you can be explicit:

// package.json
{
  "scripts": {
    "build": "next build",
    "start": "next start -p $PORT"
  }
}

Bind to $PORT — the platform injects it. Hardcoding 3000 is the most common migration mistake.

Step 3: Move your database

If you were on a Vercel marketplace Postgres, provision a managed PostgreSQL on PandaStack (14.x or 16.x). Then migrate data with standard tooling:

# Dump from your old provider
pg_dump --no-owner --no-acl "$OLD_DATABASE_URL" -Fc -f dump.pgcustom

# Restore into the new managed database
pg_restore --no-owner --no-acl -d "$NEW_DATABASE_URL" dump.pgcustom

The nice part: when you connect a database to your app on PandaStack, DATABASE_URL is auto-wired and injected into the app's environment. You don't copy connection strings around.

Step 4: Connect your Git repo

This is where the DX converges with what you're used to. Connect your repository in the dashboard; PandaStack builds on push, deploys, and gives you live build and app logs (self-hosted Elasticsearch). The tagline is literally "Push code. It runs."

git push origin main
# -> build in ephemeral K8s Job pod (rootless BuildKit)
# -> image to Google Artifact Registry
# -> Helm deploy, live logs streaming

Step 5: Port functions

Vercel serverless /api routes inside a Next.js app keep working when you run next start — they're just part of the server. Standalone Vercel Edge Functions map to PandaStack edge functions (included on every plan, free tier too). Re-create them as edge functions and point your frontend at the new endpoints.

Step 6: Env vars and secrets

Recreate your environment variables in the PandaStack dashboard. A practical tip: keep the *same variable names* so no code changes are needed. Reserved/auto-wired vars like DATABASE_URL are managed for you when a DB is attached.

Step 7: Domains and SSL

Add your custom domain in the dashboard; SSL is automatic. Then cut over DNS (PandaStack uses Cloudflare DNS under the hood). Lower your TTL a day ahead so the switch is fast, validate on the new platform, then flip the record.

Honest trade-offs

• Edge ubiquity: Vercel's edge network and Next.js integration are more mature. PandaStack is multi-region GKE with Kong ingress, but it's a newer platform with a growing ecosystem.
• Free-tier cold starts: PandaStack free-tier apps use KEDA scale-to-zero on spot nodes, so the first request after idle is slower. Paid tiers keep instances warm.
• Next.js-specific features: ISR and image optimization behave differently outside Vercel's bespoke runtime; test these explicitly.

What you gain: built-in managed databases with auto-wired connection strings, long-running containers and WebSockets without serverless gymnastics, predictable flat-rate plans (Free $0, Pro $15/mo, Premium $25/mo), and a single platform for static sites, containers, cronjobs, and edge functions.

References

• [Vercel pricing](https://vercel.com/pricing)
• [Vercel CLI — env pull](https://vercel.com/docs/cli/env)
• [Next.js — self-hosting](https://nextjs.org/docs/app/building-your-application/deploying)
• [PostgreSQL pg_dump documentation](https://www.postgresql.org/docs/current/app-pgdump.html)

---

Migration is mostly inventory plus a couple of config changes — bind to $PORT, attach a managed DB, push. Try it on PandaStack's [free tier](https://dashboard.pandastack.io): 5 web services, 5 static sites, and a managed database at $0/mo, enough to move a real project and compare.