Belajar Next.js - Deployment & Hosting

#Pendahuluan

Semua kerja keras kalian bermuara pada satu momen: aplikasi online dan bisa diakses siapa saja. Deployment adalah proses mengubah kode menjadi layanan publik yang andal — dan pilihan platform menentukan kemudahan, biaya, dan skalabilitas.

Episode 20 membahas deployment di Vercel, Netlify, AWS, dan Cloudflare, perbandingan serverless dan edge deployment, preview environments dan custom domains, serta build output dan production readiness.

#Deployment di Vercel, Netlify, AWS, dan Cloudflare

#Platform Managed: Vercel dan Netlify

Vercel adalah rumah resmi Next.js: integrasi terdalam, preview deployment otomatis per PR, dan pengaturan ulang yang sederhana. Hubungkan repository, dan setiap push ke main langsung deploy. Netlify adalah alternatif kuat dengan fitur serupa untuk project JAMstack, termasuk dukungan Next.js. Keduanya ideal untuk tim kecil yang ingin fokus pada aplikasi, bukan infrastruktur. Pilihan antara keduanya sering turun ke integrasi: Vercel menawarkan fitur Next.js paling lengkap, sedangkan Netlify unggul di ekosistem JAMstack yang lebih luas dengan harga kompetitif untuk trafik menengah.

#Platform Manual: AWS dan Cloudflare

AWS memberikan kontrol penuh: deploy Next.js di EC2, atau dengan konfigurasi Lambda untuk mode serverless, plus integrasi dengan S3 dan CloudFront untuk aset statis. Cloudflare menawarkan Workers dan Pages dengan edge network luas — pasangan serasi untuk aplikasi yang memakai edge runtime (episode 21). Kontrol lebih besar berarti tanggung jawab lebih besar: kalian mengelola skala, keamanan, dan biaya sendiri.

Beberapa platform menawarkan analisis biaya dan metrik trafik bawaan. Manfaatkan dashboard tersebut untuk memantau biaya serverless dan mengidentifikasi halaman yang paling banyak diakses.

#Serverless vs Edge Deployment

#Dua Model Eksekusi

Serverless deployment menjalankan setiap request sebagai fungsi yang discale secara otomatis: tidak ada server yang selalu hidup, hanya dikenai biaya per penggunaan. Edge deployment menjalankan kode di titik terdekat pengguna dengan latensi minimal, tapi dengan batasan runtime. Pilihan diatur per route dengan konfigurasi runtime — misalnya menandai route handler untuk edge:

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

Ekspor runtime = "edge" membuat route di atas berjalan di edge. Keputusan memilih keduanya dibahas mendalam di episode 21 — untuk sekarang, pahami bahwa keduanya tidak eksklusif: aplikasi bisa memakai campuran keduanya.

Keputusan serverless atau edge juga memengaruhi biaya. Serverless dikenai biaya per eksekusi dan durasi; edge murah untuk logika singkat. Untuk aplikasi dengan trafik rendah, perbedaan biaya sering tidak signifikan — fokuslah pada kebutuhan latensi dan kapabilitas, bukan hanya angka di tagihan.

#Preview Environments dan Custom Domains

#Preview per Pull Request

Preview environments adalah keunggulan platform managed: setiap pull request mendapat URL unik yang menjalankan build dari branch tersebut. Tim bisa meninjau perubahan sebelum di-merge ke main, dan tester bisa memeriksa fitur di environment yang persis production. Ini menutup loop kualitas yang dimulai di episode 19.

Alur deployment modern: push ke branch main, pipeline CI menjalankan build dan testing (episode 19), lalu platform membangun aplikasi, menempatkan hasilnya di infrastruktur, dan menerbitkan URL produksi. Seluruh proses berjalan dalam hitungan menit dan bisa diputar balik jika terjadi masalah. Di Vercel, alur ini dikelola dari dashboard: hubungkan repository, framework terdeteksi otomatis, atur environment variables, lalu deploy. Perintah CLI melakukan hal yang sama dari terminal untuk kebutuhan automation:

npx vercel --prod

Perintah npx vercel --prod mengunggah dan men-deploy project langsung ke produksi. Untuk pipeline yang lebih terukur, biarkan CI/CD yang menjalankan deployment — manusia tidak perlu menekan tombol. Sebelum deploy pertama, pastikan login sudah dilakukan dengan npx vercel login agar CLI mengenali akun kalian.

#Custom Domains

Setelah deploy, hubungkan domain sendiri: tambahkan record DNS di panel platform, lalu sertifikat HTTPS diterbitkan otomatis. Platform managed menangani renewal sertifikat tanpa intervensi manual. Untuk multi-region, gunakan DNS yang mendukung pemilihan lokasi agar pengguna terarah ke server terdekat.

#Build Output dan Production Readiness

#Output Standalone untuk Kontrol Penuh

Untuk deployment di server sendiri atau container, aktifkan output: "standalone" di next.config.mjs. Ini menghasilkan folder .next/standalone yang berisi aplikasi siap jalan tanpa node_modules lengkap:

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"]

Dockerfile di atas membangun aplikasi lalu menyalin hasil standalone ke image ringan. Kontainer ini bisa dijalankan di mana pun — Docker, ECS, Kubernetes. Ukuran image jauh lebih kecil karena dependency produksi saja yang dibawa.

#Verifikasi Sebelum Rilis

Production readiness berarti: build berjalan tanpa error, type check dan lint lulus, secrets terisi benar, dan variabel NEXT_PUBLIC_ disuntikkan saat build. Pastikan juga halaman diuji di environment preview — memperbaiki masalah di production adalah pelajaran yang mahal.

Checklist singkat sebelum rilis:

• Build berjalan tanpa error di pipeline CI.
• Secrets terisi di dashboard platform, bukan di kode.
• Preview environment sudah diuji oleh tim dan tester.
• Custom domain terhubung dengan HTTPS aktif.
• Web vitals dalam batas yang sehat.
• Monitoring dan logging dari episode 22 sudah aktif.

Tetapkan rutinitas rilis: deploy ke preview, uji alur kritis, lalu promosi ke produksi. Beberapa tim memakai pengalihan trafik bertahap untuk meminimalkan risiko — praktik yang lazim di aplikasi berskala besar.

Setelah rilis pertama, jangan langsung mengumumkan ke publik: amati log dan metrik selama beberapa jam untuk menangkap anomali sebelum pengguna ramai.

#Penutup

Inti yang harus dibawa pulang:

• Vercel dan Netlify menyederhanakan deployment untuk Next.js.
• AWS dan Cloudflare memberi kontrol penuh dengan tanggung jawab lebih besar.
• Serverless menawarkan skala otomatis, edge menawarkan latensi minimal.
• Preview environments memungkinkan peninjauan per pull request.
• Custom domains dengan HTTPS otomatis menaikkan profesionalisme.
• Output standalone memungkinkan deployment di server sendiri via Docker.

Di episode 21 selanjutnya kita akan membahas serverless dan edge runtime — edge functions dan serverless functions, deployment API route di edge, pertimbangan latensi dan perbedaan runtime, serta use case untuk memilih antara edge dan serverless. Arsitektur deployment kalian akan tepat sasaran.