Open Next: self-host Next.js with full Vercel feature parity

Next.js works best on Vercel, where deployment is seamless and features like ISR, middleware, and image optimization just work. But many teams need to self-host: compliance requirements, existing AWS infrastructure, cost concerns, or avoiding vendor lock-in. Open Next bridges this gap by converting Next.js output into packages that run on AWS, Docker, or other platforms.

What Open Next does

Open Next takes the output from next build and transforms it into deployment artifacts for non-Vercel platforms.

The result is a deployment package that replicates Vercel's behavior on your infrastructure.

When to use Open Next

Open Next makes sense when:

• Compliance: You must host on specific clouds or regions
• Cost control: Vercel pricing doesn't fit your traffic patterns
• Existing infrastructure: You already have AWS, and adding Vercel creates complexity
• Vendor lock-in: You want the option to move between platforms
• Edge control: You need custom CloudFront or CDN configurations

For new projects without these constraints, Vercel is simpler. Open Next adds operational overhead.

Installation and setup

Install Open Next as a dev dependency:

npm install -D open-next

Add a build script to package.json:

{
  "scripts": {
    "build": "next build",
    "open-next": "open-next build"
  }
}

Run both builds:

npm run build
npm run open-next

The output appears in .open-next/:

.open-next/
├── server-function/    # Lambda handler for server routes
├── image-optimization-function/  # Image resizing Lambda
├── revalidation-function/  # ISR background revalidation
├── warmer-function/    # Optional cold start warmer
└── assets/             # Static files for S3/CDN

Configuring Open Next

Create open-next.config.ts for customization:

import type { OpenNextConfig } from 'open-next/types/open-next';

const config: OpenNextConfig = {
  default: {
    override: {
      wrapper: 'aws-lambda-streaming',
    },
  },
  imageOptimization: {
    arch: 'arm64',
  },
  revalidate: {
    wrapper: 'sqs-revalidate',
  },
};

export default config;

Options control Lambda architecture, wrapper types, and how revalidation works.

Deploying with SST

SST (Serverless Stack) has first-class Open Next support:

// sst.config.ts
import { SSTConfig } from 'sst';
import { NextjsSite } from 'sst/constructs';

export default {
  config() {
    return {
      name: 'my-nextjs-app',
      region: 'us-east-1',
    };
  },
  stacks(app) {
    app.stack(function Site({ stack }) {
      const site = new NextjsSite(stack, 'site', {
        path: '.',
        environment: {
          DATABASE_URL: process.env.DATABASE_URL,
        },
      });

      stack.addOutputs({
        URL: site.url,
      });
    });
  },
} satisfies SSTConfig;

Deploy with:

npx sst deploy

SST handles CloudFront, Lambda, S3, and all the wiring.

Deploying with CDK

For AWS CDK users:

import * as cdk from 'aws-cdk-lib';
import { Nextjs } from 'cdk-nextjs-standalone';

export class NextjsStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new Nextjs(this, 'NextjsSite', {
      nextjsPath: './',
      environment: {
        DATABASE_URL: process.env.DATABASE_URL!,
      },
    });
  }
}

The cdk-nextjs-standalone package uses Open Next under the hood.

ISR on AWS

Incremental Static Regeneration requires coordination between Lambda, S3, and a revalidation queue:

Open Next sets up this infrastructure. When a page needs revalidation:

1. CloudFront serves stale content
2. Lambda triggers background regeneration
3. New content uploads to S3
4. CloudFront cache invalidates

This matches Vercel's ISR behavior.

Middleware on AWS

Next.js middleware runs on CloudFront Functions or Lambda@Edge:

Open Next chooses based on your middleware complexity. Simple rewrites use CloudFront Functions; middleware with database calls uses Lambda@Edge.

Image optimization

Open Next creates a Lambda function for image optimization:

// open-next.config.ts
{
  imageOptimization: {
    arch: 'arm64',  // Better price-performance
    memory: 1024,   // MB
  },
}

The Lambda resizes images on-demand, similar to Vercel's image optimization. Serve through CloudFront for caching.

Environment variables

Pass environment variables through your deployment tool:

// SST
new NextjsSite(stack, 'site', {
  environment: {
    DATABASE_URL: process.env.DATABASE_URL,
    NEXT_PUBLIC_API_URL: 'https://api.example.com',
  },
});

Build-time variables (NEXT_PUBLIC_*) are embedded during build. Runtime variables are injected into Lambda.

Monitoring and debugging

Add observability to your Lambda functions:

// SST example with tracing
new NextjsSite(stack, 'site', {
  bind: [table],
  environment: { ... },
  nodejs: {
    install: ['@opentelemetry/api'],
  },
});

Use CloudWatch Logs for Lambda output, X-Ray for tracing, and CloudWatch metrics for monitoring. Set up alarms for error rates and latency.

Cold starts

Lambda cold starts affect TTFB. Mitigate with:

Open Next can generate a warmer function that pings your Lambdas periodically.

Common issues

Trade-offs compared to Vercel

Summary

Open Next enables self-hosted Next.js with features that normally require Vercel: ISR, middleware, image optimization, and streaming. Use it when you need AWS, cost control, or compliance. Deploy with SST, CDK, or Terraform. Accept the operational overhead in exchange for infrastructure control. For most projects, Vercel is simpler; for specific requirements, Open Next delivers.