Vercel's hidden jurisdiction risk for Canadians

You're a Canadian developer building with Next.js. You've got API routes handling user data, server components rendering personalized content, maybe a database connection or two. Vercel makes deploying all of this effortless. But there's a question your compliance team, your clients, or your own instincts might eventually raise: where does that data actually live, and whose law governs it?

Next.js doesn't require Vercel

Vercel makes Next.js, and Next.js is excellent. But the two are separable. Next.js has a built-in standalone output mode designed specifically for self-hosting. Set output: "standalone" in your next.config.js and Next.js produces a self-contained folder with a minimal Node.js server and only the node_modules your app actually imports. No full dependency tree, no bloat.

That standalone output drops neatly into a multi-stage Docker build. The standard pattern is three stages: install dependencies, build the app, copy the standalone output into a minimal runner image. The resulting Docker image is typically under 200 MB, down from over 2 GB with a naive build. It runs anywhere Docker runs, which means any VPS, any Kubernetes cluster, any PaaS that supports containers.

You lose some Vercel conveniences (analytics, Edge Config, edge middleware), but you gain control over where your code runs and whose jurisdiction covers your data. For teams that only use Vercel for deployments, the switch is straightforward. For teams deeper into the Vercel ecosystem, it takes more effort, but it's not a rewrite.

The Montreal region doesn't solve the jurisdiction problem

Vercel now offers a Montreal region (yul1) for serverless functions, which helps with latency. But a Canadian compute region is not Canadian jurisdiction. Vercel is a US company headquartered in San Francisco subject to the CLOUD Act regardless of which region you select. Your API routes and server components handle real data, and that data is governed by US law.

Vercel's infrastructure runs on AWS. The default function region for new projects is Washington, D.C. (iad1). You can change it to Montreal, but the platform itself, your account data, your deployment metadata, your logs, all of that flows through Vercel's US-based systems. Choosing a Canadian compute region changes where your function executes. It doesn't change which country's courts can compel Vercel to hand over your data.

If your concern is latency alone, Vercel's Montreal region solves that. If your concern is the legal framework governing your data, it doesn't.

Who should care

The obvious cases are regulated industries. A healthcare SaaS that processes patient intake forms needs to know that data stays under Canadian jurisdiction, not just Canadian latency. A legal document platform where lawyers upload case files can't afford ambiguity about which country's courts can access those documents. A fintech startup handling KYC documents and transaction records has compliance requirements that go beyond "we picked a Canadian region."

But compliance isn't the only driver. Consider a B2B analytics tool that ingests client data to generate reports. The tool itself isn't regulated, but the clients are. When an enterprise prospect sends over a security questionnaire asking where their data is stored and which jurisdiction governs it, "US company, AWS infrastructure" is a factual answer that may cost you the deal.

Government contractors face this directly. Federal and provincial procurement increasingly requires Canadian data residency, and that means Canadian jurisdiction, not a US company with a Canadian region option.

Static marketing sites with no user data? Vercel is fine. But once you add API routes, form submissions, or a database, you're making a jurisdiction choice whether you realize it or not.

Vercel's pricing adds up

Vercel's Pro plan starts at $20 USD per user per month. That base price includes one deploying member and a $20 usage credit. Each additional team member who can deploy costs another $20 per month. Viewer seats are free, but anyone who needs to trigger a deployment or manage settings pays.

The usage model layers on top. Pro includes 1 TB of data transfer per month. After that, Fast Data Transfer overage rates range from $0.15 to $0.35 per GB depending on region. Serverless compute (Vercel calls it Fluid Compute) is billed across three dimensions: active CPU time, provisioned memory, and invocations, with pay-as-you-go overages beyond the $20 usage credit. Image optimization, analytics, and storage products each have their own usage tiers and overage pricing.

For a solo developer with a single project, Vercel Pro is reasonable. For a team of five deploying multiple projects, the per-seat costs alone reach $100 USD per month before any usage charges. Add bandwidth overages from a traffic spike, heavier serverless function usage, or a few storage products, and the monthly bill becomes hard to predict.

MapleDeploy uses flat pricing. The Starter plan is $45 CAD per month for a dedicated VM with 4 GB RAM, 2 vCPUs, and 35 GB storage. Deploy as many Next.js apps, backends, and databases as your resources allow. No per-seat fees, no bandwidth overages, no serverless execution metering. Your bill is the same every month regardless of traffic or team size.

What you give up

Being honest about tradeoffs matters. Vercel has genuine advantages that don't have direct equivalents on a self-hosted platform.

Vercel's edge network delivers static assets from locations worldwide. On MapleDeploy, your app serves from a dedicated VM in Toronto. For Canadian and North American audiences, that's fast and your data stays in Canadian jurisdiction. For a global consumer app, put Bunny.net or Cloudflare in front of your VM and you get edge delivery with a Canadian origin.

Vercel Analytics and Speed Insights provide real user monitoring tied directly to your deployments. Self-hosted alternatives exist (Plausible, Umami, PostHog), but you set them up yourself. Edge Config is convenient for feature flags. For session data or caching, Vercel's marketplace offers Redis integrations through Upstash. On Coolify, you'd deploy Redis or use an equivalent service.

Vercel's preview deployments for every pull request are polished. Coolify gives you the same thing: every PR gets its own preview URL with automatic cleanup when the PR closes, managed from the Coolify dashboard.

None of these are dealbreakers. They're conveniences. The question is whether those conveniences justify US jurisdiction over your data.

What a practical migration looks like

If you decide to move, the process is more mechanical than architectural. Your application code barely changes.

Start with your next.config.js. Add output: "standalone" if it's not already there. Run a build locally and verify the .next/standalone directory is produced. If your app builds successfully in standalone mode, it will run on any Node.js host.

Next, write a Dockerfile. Next.js provides an official example in their repository. The pattern is straightforward: install dependencies, build the app, copy the standalone output and static assets into a slim final image. A working Dockerfile is typically under 30 lines.

Move your environment variables. On Vercel, these live in the project settings dashboard. On Coolify, you configure them in the application settings. Same key-value pairs, different UI. If you're using Vercel-specific environment variables like VERCEL_URL, replace them with your actual domain.

For databases, the migration depends on what you're using. If your database is already external (Neon, PlanetScale, Supabase), you just update the connection string to point to your new infrastructure. If you're using a Vercel Marketplace database (Neon Postgres, Upstash Redis), you can either keep the external provider and update the connection string, or migrate to a self-hosted PostgreSQL or Redis instance on Coolify. Coolify supports one-click deployment of both.

DNS is the last step. Point your domain to your new server. If you're using Vercel's automatic SSL, Coolify handles Let's Encrypt certificates automatically.

The whole process for a typical Next.js app with a database takes an afternoon. The codebase doesn't change in any meaningful way. What changes is where it runs and whose law governs it. Our getting started guide covers the full MapleDeploy setup from signup to a live app.

Deciding whether to move

What Vercel features do you actually use? If it's just deployments, alternatives are straightforward. If you're deep into Vercel Analytics, Edge Config, and edge middleware, migration takes more effort. Do you need edge performance? For most B2B applications, single-region deployment from Toronto is fast enough for North American users. Edge only matters for global consumer traffic.

Be clear about your compliance requirement. "We should probably care" is different from "our contracts require it." The latter justifies more migration effort. But don't wait for a compliance requirement to be the forcing function. Some teams move because they want a clear answer when a client asks "where is our data?"

A proper Canadian alternative needs: Canadian jurisdiction (not just a Canadian data center), full-stack support (server components, API routes, databases), and a modern developer experience. MapleDeploy delivers all of these. See our full Vercel comparison for a side-by-side breakdown.