Deploy Next.js with AZIN

Next.js requires a Node.js server for SSR, Server Components, and API routes — you can't serve it from a static CDN alone. AZIN detects your Next.js project via Railpack, configures the Node.js runtime, and deploys to your own GCP account using GKE Autopilot. No infrastructure YAML. No Dockerfile required. Push code, it's live.

#How AZIN detects Next.js

AZIN uses Railpack to auto-detect your project on every git push. When Railpack finds a package.json with a next dependency, it identifies the project as a Next.js application and applies framework-specific optimizations automatically.

What Railpack sets up for a Next.js project:

• Node.js version from engines.node in package.json → .nvmrc → .node-version → defaults to Node.js 22
• Package manager auto-detected from your lockfile: npm, yarn, pnpm, or bun
• Build command: next build (detected from the build script in package.json)
• Start command: next start (auto-detected by Railpack for Next.js)
• Output tracing: Railpack detects standalone output mode and adjusts the container accordingly
• Caching: build layers cached between deploys for faster subsequent builds

No Dockerfile needed. No Procfile. If your project has a next.config.js with output: 'standalone', Railpack picks that up and produces a minimal container image.

#Deployment config

Connect your GitHub repository and AZIN deploys on every push to your main branch. For a Next.js app with a managed PostgreSQL database:

name: my-nextjs-app
cloud: gcp
region: us-central1
services:
  web:
    build:
      type: railpack
    env:
      NODE_ENV: production
      NEXTAUTH_URL: "https://yourdomain.com"
    scaling:
      min: 1
      max: 10
      target_cpu: 70
  db:
    type: postgres
    plan: production

AZIN injects DATABASE_URL into the web service automatically when you add the db service. The scaling block configures horizontal pod autoscaling on GKE Autopilot — AZIN scales between min and max replicas based on CPU utilization.

For a minimal deployment with no database:

name: my-nextjs-app
cloud: gcp
region: us-central1
services:
  web:
    build:
      type: railpack
    env:
      NODE_ENV: production
    scaling:
      min: 1
      max: 5
      target_cpu: 70

That's the entire config. Railpack handles the rest.

#Next.js config for production

The most impactful change you can make to next.config.js for self-hosted deployment is enabling standalone output mode:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
}
 
module.exports = nextConfig

Standalone output traces only the files your app actually uses and produces a minimal server.js entry point. Railpack detects this configuration and adjusts the container build accordingly — no manual Dockerfile required.

For Next.js Image Optimization, configure remotePatterns to allow your image domains:

// next.config.js
const nextConfig = {
  output: 'standalone',
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-image-cdn.com',
      },
    ],
  },
}
 
module.exports = nextConfig

Image Optimization works out of the box when deployed to a Node.js server. AZIN runs next start, which includes the built-in image optimizer.

Set environment variables through the AZIN Console. Common Next.js production variables:

NODE_ENV=production
NEXTAUTH_URL=https://yourdomain.com
NEXTAUTH_SECRET=your-secret-here
NEXT_PUBLIC_API_URL=https://api.yourdomain.com
DATABASE_URL=  # injected automatically by AZIN when db service is present

#Handling SSR and API routes

Next.js App Router uses React Server Components (RSC) by default. Server Components run exclusively on the server and can fetch data directly in the component tree. This requires a persistent Node.js server — not a static CDN.

AZIN runs next start in a container on GKE Autopilot. A single container handles:

• Server Components — rendered on the server per-request or cached
• Client Components — bundled and served as JavaScript to the browser
• API Routes and Route Handlers — run as Node.js functions in the same process
• Middleware — runs in the Node.js container on AZIN
• Next.js Image Optimization — handled by the next start server

For larger apps that need to separate concerns, add a worker service in azin.yaml:

services:
  web:
    build:
      type: railpack
    env:
      NODE_ENV: production
  worker:
    build:
      type: railpack
    start: node src/workers/queue-processor.js
    env:
      NODE_ENV: production
  db:
    type: postgres
    plan: production
  cache:
    type: redis

Both services share the injected DATABASE_URL and REDIS_URL.

#Why AZIN for Next.js hosting

Your own cloud, not ours. Your Next.js app and PostgreSQL database run in your own GCP account. You own the infrastructure, the data stays in your VPC, and your billing is directly with Google — no platform markup on compute. AWS and Azure support is on our roadmap.

SSR without a platform tax. GKE Autopilot's first cluster is free — you pay only for running pods. For Next.js apps that need persistent Node.js servers for SSR, this cost structure differs from platforms that require dedicated cluster infrastructure before any application pods run.

Managed PostgreSQL in your cloud. AZIN provisions Cloud SQL in your GCP account — the same VPC as your Next.js container. Automated backups, encryption at rest, and connection pooling. The DATABASE_URL is injected automatically.

Per-PR preview environments. Every pull request gets a full-stack preview environment with its own URL and database instance. Review UI changes and API behavior before they merge. Preview environments are provisioned automatically on PR open and torn down on close.

#Related guides

• Deploy Docker containers with AZIN — For custom Dockerfile deployments
• Deploy Node.js with AZIN — Node.js APIs and backend services
• AZIN vs Vercel — Next.js hosting: own cloud vs Vercel's infrastructure
• AZIN vs Railway — Compare deployment platforms for Node.js workloads
• Best Vercel alternatives in 2026 — If you're evaluating your Next.js hosting options

#Frequently asked questions