Struggling with Vercel lock-in for your Next.js app? This senior engineer’s guide breaks down your real-world options, from the quick OpenNext escape hatch to a full migration strategy for true cloud independence.

So You Want to Break Up with Vercel? Let’s Talk Self-Hosting Next.js (and OpenNext).

I remember the day the bill came in. It was a Tuesday. We were a lean team, proud of our new marketing site built on Next.js, and traffic was finally spiking after a successful campaign. Then I saw the invoice from Vercel, and my coffee went cold. It wasn’t astronomical, but it was enough to make our finance lead walk over to my desk with that ‘we need to talk’ look. “I thought the whole point of this serverless thing was to save money?” he asked. That was the moment the convenience of Vercel became the “Vercel Problem” I had to solve. It’s a story I’ve heard a dozen times since from other engineers.

First, Let’s Understand the “Golden Cage”

Before we dive into solutions, let’s be fair. Vercel is a fantastic platform. Its seamless integration with Next.js is a thing of beauty, and for many projects, it’s the perfect fit. The problem isn’t that Vercel is bad; it’s that its convenience creates a “golden cage.”

The core issue is the tight coupling between advanced Next.js features and Vercel’s proprietary, black-box infrastructure. Features like:

• On-demand ISR (Incremental Static Regeneration)
• Edge Middleware
• Advanced Image Optimization
• Server Actions

These are designed to work flawlessly… on Vercel. When you try to take your app and run it on your own infrastructure (like AWS or GCP), you quickly realize you can’t just deploy a simple Node.js server. You have to replicate a complex, distributed system of Lambdas, an object store, a CDN, and routing logic that Vercel abstracts away. This is where the pain begins.

Solution 1: The ‘Get Me Out Now’ Fix with OpenNext

This is where that Reddit thread started, and for good reason. OpenNext is a fantastic open-source project that acts as an adapter. It takes your Next.js build output and transforms it into a package that can be deployed on AWS with a more Vercel-like architecture (Lambda, S3, CloudFront).

How it works:

OpenNext essentially acts as a compatibility layer. You add it to your build process, and it intelligently bundles your app into deployable assets for AWS. It separates server code into a Lambda function, static assets into an S3 bucket, and image optimization into another Lambda, all fronted by a CloudFront distribution.

The Good:

• Fastest Migration Path: You can get your existing Next.js app off Vercel and onto your own AWS account with minimal code changes.
• Feature Parity: It does a damn good job of replicating most of the core Next.js features you rely on.

The Reality Check:

OpenNext is not a magic bullet. You’re trading one abstraction (Vercel) for another. You now own the complex AWS infrastructure that OpenNext provisions. If that CloudFormation stack fails, it’s on you to debug it. It’s a brilliant tool, but it’s best viewed as a bridge, not always a final destination.

Darian’s Pro Tip: Use OpenNext to escape immediate cost or compliance issues. But while it’s running, start planning your long-term strategy. Don’t let the “quick fix” become a new form of technical debt.

Solution 2: The ‘Built to Last’ Fix with Containerization

This is my preferred approach for teams that have an established DevOps culture. Instead of trying to replicate Vercel’s serverless model, we embrace a more traditional, portable one: containers.

How it works:

Since Next.js 12, there’s a fantastic feature in the build output called standalone. This creates a folder with only the necessary files to run the app, drastically reducing your Docker image size. You build a simple Node.js server inside a Docker container and deploy it anywhere—AWS Fargate, Google Cloud Run, or your own Kubernetes cluster (like our prod-k8s-us-east-1).

A basic Dockerfile might look something like this:

# Install dependencies only when needed
FROM node:18-alpine AS deps
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile

# Rebuild the source code only when needed
FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# This is the magic part for the standalone output
ENV NEXT_TELEMETRY_DISABLED 1
RUN yarn build

# Production image, copy all the files and run next
FROM node:18-alpine AS runner
WORKDIR /app
ENV NODE_ENV production
ENV NEXT_TELEMETRY_DISABLED 1

# Copy the standalone output
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
ENV PORT 3000

CMD ["node", "server.js"]

The Good:

• Total Portability: A Docker container runs anywhere. No vendor lock-in. Period.
• Full Control: You control the environment, the networking, the scaling. It fits into your existing infrastructure-as-code (Terraform, Pulumi, etc.) beautifully.

The Reality Check:

You lose the “magic.” Vercel’s automatic image optimization? Gone. You’ll need to set up your own solution, like Thumbor, Imgix, or use CloudFront’s built-in resizing. Edge middleware? Not happening in the same way. You’ll need to configure your CDN to handle that logic. This path requires more DevOps expertise upfront.

Solution 3: The ‘Nuclear’ Option – Re-evaluate the Framework

Sometimes, the friction is a sign of a deeper mismatch. If your entire philosophy is built around cloud agnosticism and avoiding vendor-specific features, then continuing to fight with a framework that is increasingly intertwined with one specific vendor might not be the best use of your time.

How it works:

You make the hard decision to migrate to a framework designed from the ground up for platform independence. Frameworks like Astro or Remix are excellent examples. Remix, for instance, has a clear adapter-based deployment model, allowing you to build for any target, from a simple Express server to Cloudflare Workers, without changing your application code.

The Good:

• Philosophical Alignment: You’re using a tool that matches your team’s core principles on infrastructure. This reduces friction in the long run.
• Clear Deployment Story: These frameworks have a very explicit and simple story for self-hosting.

The Reality Check:

This is a rewrite. It’s the most expensive and time-consuming option. I would only recommend this if you’re early in a project’s lifecycle or if the pain of self-hosting your Next.js app is actively costing you more in engineering hours than a migration would.

Comparison at a Glance

Here’s how I break it down for my teams when we’re at this crossroads:

Approach	Best For…	Key Trade-off
OpenNext	Teams needing to get off Vercel fast due to cost or compliance, without a major refactor.	You still have a complex abstraction layer to manage; you just own the AWS bill for it now.
Docker Container	Teams with existing DevOps/IaC practices who want full control and portability.	You lose Vercel’s “magic” features and must build/configure your own alternatives (e.g., image optimization).
New Framework	Teams starting a new project or those whose long-term strategy is fundamentally incompatible with the Vercel/Next.js model.	The highest upfront cost in engineering time and effort (a full rewrite/migration).

Ultimately, there’s no single right answer. My advice? Don’t get stuck in the hype. Evaluate your team’s skills, your company’s budget, and your long-term infrastructure strategy. The freedom of self-hosting is powerful, but it comes with responsibility. Choose wisely.

---

🤖 Frequently Asked Questions