Build Adapters API adalah kontrak resmi, bertipe, dan versioned yang
distabilkan di Next.js 16.2 (Maret 2026), memungkinkan platform non-Vercel
membaca hasil build Next.js secara resmi lewat dua hook, `modifyConfig` dan
`onBuildComplete`, alih-alih menebak strukturnya lewat reverse engineering
seperti sebelumnya.

**Ringkasan cepat:**

1. Build Adapters API distabilkan di Next.js 16.2, hasil kolaborasi tim Next.js dengan OpenNext, Netlify, Cloudflare, AWS Amplify, dan Google Cloud sejak RFC dipublikasikan April 2025.
2. Adapter bekerja lewat dua hook: `modifyConfig` (mengubah konfigurasi sebelum build) dan `onBuildComplete` (membaca rute, output, dan metadata build setelah `next build` selesai).
3. Adapter berbeda dari output `standalone` - yang pertama kontrak integrasi untuk platform, yang kedua strategi packaging minimal yang bisa dipakai tanpa adapter sama sekali.
4. Developer aplikasi cukup mengarahkan `adapterPath` di konfigurasi ke adapter yang sudah dibuat platform/komunitas, tidak perlu menulis hook sendiri untuk kasus umum.
5. Situs ini sendiri masih memakai output `standalone` plus deploy manual lewat systemd, bukan Adapter API, karena rsync ke VPS tunggal belum butuh kontrak multi-platform.

## Apa Itu Build Adapters API Next.js?

Build Adapters API adalah lapisan integrasi resmi yang membuat Next.js
menghasilkan deskripsi terstruktur dari seluruh aplikasi setelah build:
daftar rute, halaman yang di-prerender, aset statis, target runtime,
dependensi, aturan cache, dan keputusan routing. Menurut
[dokumentasi resmi Next.js](https://nextjs.org/docs/app/api-reference/adapters/creating-an-adapter),
platform hosting mengonsumsi deskripsi ini lewat modul adapter yang
diarahkan lewat opsi `adapterPath` di `next.config.js`, bukan lagi dengan
membongkar struktur folder `.next` secara manual seperti yang terpaksa
dilakukan banyak platform sebelum API ini ada.

Sebelum API ini stabil, [pengumuman resmi Next.js](https://nextjs.org/blog/nextjs-across-platforms)
menyebutkan bahwa setiap platform non-Vercel harus reverse engineering
output build Next.js sendiri-sendiri, dan itu jadi sumber mayoritas keluhan
yang masuk ke tim Next.js dari platform seperti Netlify. RFC untuk desain
API ini dipublikasikan tim Next.js di GitHub pada April 2025, hampir satu
tahun sebelum akhirnya stabil di versi 16.2.

### Dua Hook Utama: `modifyConfig` dan `onBuildComplete`

Adapter mengimplementasikan dua fungsi inti. `modifyConfig` berjalan setiap
kali konfigurasi Next.js dimuat (termasuk saat `next dev`), sehingga harus
dijaga dengan pengecekan fase build agar perubahan khusus produksi tidak
ikut aktif di development. `onBuildComplete` berjalan sekali setelah
`next build` selesai, menerima data rute (header, redirect, rewrite,
rute dinamis) dan output yang sudah diklasifikasi per jenis - halaman App
Router, API routes, halaman Pages Router, berkas statis, dan middleware -
sehingga adapter tinggal memetakan setiap jenis output ke infrastruktur
platform masing-masing.

## Bagaimana Build Adapters API Berbeda dari Output `standalone`?

Dua hal ini sering tertukar karena keduanya muncul di percakapan "deploy
Next.js tanpa Vercel", tapi menyelesaikan masalah berbeda. Output
`standalone` adalah strategi packaging: Next.js melacak file yang benar-
benar dipakai dari `node_modules` dan menyalinnya ke folder minimal
`.next/standalone`, sehingga server produksi tidak perlu `npm install`
penuh. Build Adapters API adalah kontrak integrasi: platform memakai hook
`modifyConfig`/`onBuildComplete` untuk membaca struktur build secara resmi,
lalu memutuskan sendiri bagaimana men-deploy-nya (container, edge function,
static hosting, atau kombinasi).

Situs personal brand ini sendiri (irfanramadhan.com) jadi contoh konkret
bedanya: deploy-nya memakai `output: "standalone"` di `next.config.ts`,
lalu hasil build disalin manual lewat `rsync` ke direktori yang dilayani
`systemd`, tanpa adapter apa pun. Pola ini cukup untuk kasus VPS tunggal
dengan satu target deploy yang sudah diketahui persis - lihat
[panduan deploy Next.js ke VPS tanpa Vercel](/blog/cara-deploy-nextjs-ke-vps-tanpa-vercel)
untuk langkah lengkapnya. Adapter baru benar-benar bernilai ketika sebuah
platform (bukan satu proyek individual) harus mendukung banyak proyek
Next.js sekaligus dengan satu kontrak yang sama, seperti yang dilakukan
OpenNext untuk AWS/Cloudflare atau Netlify untuk infrastrukturnya sendiri.

## Kapan Developer Aplikasi Perlu Peduli dengan Adapter?

Hampir semua developer aplikasi tidak perlu menulis adapter sendiri.
Pekerjaan menulis `modifyConfig`/`onBuildComplete` ada di pihak platform
atau proyek seperti OpenNext, bukan di proyek individual. Yang relevan
bagi developer aplikasi hanya dua: pertama, memahami bahwa platform deploy
pilihannya (Cloudflare, AWS Amplify, Google Cloud, Netlify, atau self-
hosted via OpenNext) kini punya jalur dukungan resmi untuk fitur Next.js
16 terbaru, termasuk perubahan `proxy.ts` yang dibahas di
[fitur baru Next.js 16.1-16.3](/blog/fitur-baru-nextjs-16-1-16-2-16-3).
Kedua, memastikan versi adapter yang dipakai platform sudah mendukung versi
Next.js project-nya, karena kontrak ini versioned dan bisa berubah antar
rilis mayor.

## Ringkasan: Adapter API Standarkan Integrasi Platform, Bukan Gantikan Output Standalone untuk Deploy Manual

- Build Adapters API menyelesaikan masalah platform hosting (reverse engineering build output), bukan masalah packaging yang sudah ditangani output `standalone`.
- Dua hook `modifyConfig` dan `onBuildComplete` adalah inti kontraknya - developer aplikasi cukup mengarahkan `adapterPath`, bukan menulis logika adapter sendiri.
- Proyek dengan satu target deploy sederhana (seperti VPS tunggal situs ini) tetap bisa memakai `output: "standalone"` manual tanpa adapter; adapter bernilai saat sebuah platform harus mendukung banyak proyek sekaligus.
- Kalau butuh bantuan menentukan strategi deploy Next.js yang tepat untuk proyekmu sendiri, baik manual VPS maupun platform terkelola, ini bagian dari [layanan web development](/layanan) yang ditawarkan di situs ini.