Learning Next.js - Deployment & Hosting

#Introduction

All your hard work comes down to one moment: the application goes online and anyone can access it. Deployment is the process of turning code into a reliable public service — and the platform choice determines ease, cost, and scalability.

Episode 20 covers deployment on Vercel, Netlify, AWS, and Cloudflare, comparing serverless and edge deployment, preview environments and custom domains, and build output and production readiness.

#Deployment on Vercel, Netlify, AWS, and Cloudflare

#Managed Platforms: Vercel and Netlify

Vercel is the official home of Next.js: the deepest integration, automatic preview deployments per PR, and simple rollbacks. Connect the repository, and every push to main deploys immediately. Netlify is a strong alternative with similar features for JAMstack projects, including Next.js support. Both are ideal for small teams that want to focus on the application rather than infrastructure. The choice between them often comes down to integration: Vercel offers the most complete Next.js features, while Netlify excels in the broader JAMstack ecosystem with competitive pricing for mid-tier traffic.

#Manual Platforms: AWS and Cloudflare

AWS gives full control: deploy Next.js on EC2, or with Lambda configuration for serverless mode, plus integration with S3 and CloudFront for static assets. Cloudflare offers Workers and Pages with a broad edge network — a perfect match for applications using the edge runtime (episode 21). More control means more responsibility: you manage scaling, security, and costs yourself.

Several platforms offer built-in cost analysis and traffic metrics. Use those dashboards to monitor serverless costs and identify the most-visited pages.

#Serverless vs Edge Deployment

#Two Execution Models

Serverless deployment runs each request as a function that scales automatically: no always-on server, only pay-per-use. Edge deployment runs code at the point closest to the user with minimal latency, but with runtime restrictions. The choice is set per route with a runtime configuration — for example, marking a route handler for the edge:

export const runtime = "edge"
 
export async function GET() {
  return Response.json({ lokasi: "dekat pengguna" })
}

Exporting runtime = "edge" makes the route above run at the edge. The decision between the two is covered in depth in episode 21 — for now, understand that they're not mutually exclusive: an application can use a mix of both.

The serverless or edge decision also affects cost. Serverless is billed per execution and duration; edge is cheap for short logic. For low-traffic applications, the cost difference is often insignificant — focus on latency needs and capabilities, not just the number on the bill.

#Preview Environments and Custom Domains

#Preview per Pull Request

Preview environments are the advantage of managed platforms: every pull request gets a unique URL running the build from that branch. The team can review changes before merging to main, and testers can inspect features in an environment exactly like production. This closes the quality loop that started in episode 19.

The modern deployment flow: push to the main branch, the CI pipeline runs build and testing (episode 19), then the platform builds the application, places the result on its infrastructure, and publishes the production URL. The whole process runs in minutes and can be rolled back if something goes wrong. On Vercel, this flow is managed from the dashboard: connect the repository, the framework is detected automatically, set environment variables, then deploy. The CLI command does the same from the terminal for automation needs:

npx vercel --prod

The command npx vercel --prod uploads and deploys the project straight to production. For a more scalable pipeline, let CI/CD run the deployment — humans don't need to press buttons. Before your first deploy, make sure you're logged in with npx vercel login so the CLI recognizes your account.

#Custom Domains

After deploying, connect your own domain: add a DNS record in the platform panel, then the HTTPS certificate is issued automatically. Managed platforms handle certificate renewal without manual intervention. For multi-region setups, use DNS that supports location selection so users are routed to the nearest server.

#Build Output and Production Readiness

#Standalone Output for Full Control

For deployment on your own server or in a container, enable output: "standalone" in next.config.mjs. This produces a .next/standalone folder containing an application ready to run without the full node_modules:

FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build
 
FROM node:20-alpine
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/static ./.next/static
EXPOSE 3000
CMD ["node", "server.js"]

The Dockerfile above builds the application, then copies the standalone output into a lightweight image. This container can run anywhere — Docker, ECS, Kubernetes. The image is much smaller because only production dependencies are included.

#Verifying Before Release

Production readiness means: the build runs without errors, type check and lint pass, secrets are filled correctly, and NEXT_PUBLIC_ variables are injected at build time. Also make sure pages are tested in a preview environment — fixing problems in production is an expensive lesson.

A short checklist before release:

• Build runs without errors in the CI pipeline.
• Secrets are filled in the platform dashboard, not in code.
• The preview environment has been tested by the team and testers.
• The custom domain is connected with HTTPS active.
• Web vitals are within healthy limits.
• Monitoring and logging from episode 22 are active.

Set a release routine: deploy to preview, test critical flows, then promote to production. Some teams use gradual traffic shifting to minimize risk — a common practice in large-scale applications.

After the first release, don't announce to the public right away: watch logs and metrics for a few hours to catch anomalies before users flood in.

#Closing

Here's what to take away:

• Vercel and Netlify simplify deployment for Next.js.
• AWS and Cloudflare give full control with greater responsibility.
• Serverless offers automatic scale; edge offers minimal latency.
• Preview environments enable per-pull-request review.
• Custom domains with automatic HTTPS raise professionalism.
• Standalone output enables deployment on your own server via Docker.

In the next episode, episode 21, we'll discuss serverless and edge runtime — edge functions and serverless functions, deploying API routes at the edge, latency considerations and runtime differences, and use cases for choosing between edge and serverless. Your deployment architecture will be right on target.