Deploy Vercel Diblokir? Akun Vercel-nya yang Salah

Deploy gagal dua hari. Bukan karena build error, bukan karena lint, bukan karena dependency bentrok. Commit-nya udah masuk GitHub, status di Vercel bilang "Deployment Blocked", dan pesan errornya nggak nyambung sama semua dugaan awal saya: commit author doesn't have contributing access to the project on Vercel.

Yang bikin frustrasi: error itu muncul di project yang saya sendirian. Satu repo, satu akun GitHub, satu akun Vercel, nol kolaborator. Kok bisa "author doesn't have access"?

Dugaan pertama: email git saya nggak valid. Pesan error Vercel emang bilang "The commit author email is not a valid email address", jadi saya ganti git config user.email ke email pribadi. Masih diblokir.

Dugaan kedua: harus pakai email noreply GitHub. Saya ganti lagi ke [email protected], email resmi yang terikat akun GitHub saya. Masih diblokir juga.

Dugaan ketiga: nama author harus benar. Saya samakan user.name dan user.email persis kayak commit lama yang pernah sukses deploy. Sama aja.

Tiga hari nge-push commit kosong dengan pesan "chore: retrigger Vercel deploy". Vercel tetap nol respons.

{

Ternyata masalahnya di akun Vercel, bukan di git

Akar masalahnya baru ketahuan pas saya buka dashboard Vercel dan cek project-nya milik akun mana: repo GitHub saya terhubung ke project di akun Vercel yang berbeda. Jadi semua teori soal email itu benar semua, email noreply GitHub emang identitas yang benar, tapi Vercel mengevaluasinya terhadap akun yang salah.

Mekanismenya begini: setiap kali ada push ke branch yang terhubung, Vercel baca metadata commit (nama + email author), cocokkan dengan akun GitHub yang ter-link ke akun Vercel pemilik project, lalu cek apakah akun GitHub itu punya akses deploy ke project. Di plan Hobby, satu-satunya yang punya akses itu adalah owner akunnya sendiri, nggak ada konsep kolaborator sama sekali.

Jadi begitu project-nya ada di akun Vercel lain (misalnya akun lama, akun klien, atau akun yang dibuat pakai login GitHub berbeda), semua commit saya otomatis dianggap "orang luar". Emang bener anggapannya, dari sudut pandang Vercel, saya bukan pemilik project itu.

Detail penting yang baru saya pahami setelah baca dokumentasinya lebih teliti: Vercel itu nggak pernah memvalidasi email sebagai "email valid" secara harfiah. Yang dia lakukan memetakan commit ke akun lewat rantai tiga lapis:

1. GitHub mencocokkan email commit dengan email terverifikasi di akun GitHub. Email nggak dikenal? GitHub nggak bisa mengasosiasikan committer, dan Vercel langsung menolak.
2. Akun GitHub itu harus ter-link sebagai Login Connection di akun Vercel pemilik project. Satu akun GitHub cuma bisa ter-link ke satu akun Vercel: kalau di-link ke akun kedua, koneksi di akun pertama dihapus diam-diam. Di sinilah kasus "akun Vercel lain" di artikel ini bermula.
3. Plan menentukan siapa yang boleh deploy. Hobby: cuma owner. Pro: semua member tim, bisa auto-approve atau manual.

Makanya saran "samakan email git dengan email Vercel" yang bertebaran di forum itu cuma nyambung kalau email-nya juga email terverifikasi di akun GitHub yang ter-link ke Vercel project-nya. Email-nya cocok tapi akun GitHub-nya beda? Tetap ditolak. Ini persis kasus saya.

Rangkuman batasan plan Hobby

Angka lengkapnya ada di dokumentasi resmi Vercel dan grafiknya udah kalian lihat di atas. Yang paling sering nagih buat upgrade bukan bandwidth-nya. Yang bikin kena sekali itu biasanya tiga hal ini:

• Satu seat, tanpa kolaborator. Commit author harus = owner akun. AI agent, CI bot, atau rekan tim yang commit dengan identitas lain langsung kena blokir deploy. Ini persis yang saya alami. Vercel sempat rilis pengecualian untuk Claude Code dan Cursor Agent lewat bot detection, tapi coverage-nya nggak universal, commit dengan author custom masih kena.
• Non-komersial. Fair use guidelines bilang plan ini buat "personal, non-commercial use". Blog pribadi, portfolio, project open source, aman. Sekali ada payment, ads, atau kerjaan klien, itu udah di luar ketentuan.
• Cron cuma sekali sehari. Minimal interval-nya daily, presisinya per-jam (±59 menit). Detail di docs cron jobs. Yang biasa deploy worker polling tiap 15 menit bakal langsung gagal pas deployment.

Private repo dari GitHub organization juga nggak bisa deploy di Hobby, mau ownernya siapa pun — pilihannya bikin repo publik atau upgrade Pro. Dan penolakan di lapisan identitas ini senyap: KB resmi Vercel ngakui commit yang ditolak di boundary ini sering "fail silently" tanpa error dan tanpa email, saran mereka baca Activity Log, bukan dashboard deployment. Pola di forum komunitas 2026 banyak yang mirip: "dulu deploy aman, tiba-tiba diblokir tanpa ganti apa pun", dipicu pengetatan aturan sisi Vercel, bukan salah setting user.

Angka-angka lain yang jarang disadari: function timeout default 300 detik (5 menit) dengan Fluid compute, bandwidth 100 GB/bulan, 1 juta edge request, 6.000 menit build, 100 deploy per hari, 200 project, 50 domain per project. Semua cukup buat personal project, tapi sempit buat produk beneran.

Fix-nya dan pelajarannya

Setelah tahu masalahnya di ownership akun, ada empat jalan keluar. Urutannya dari yang paling saya rekomendasikan:

1. Transfer project ke akun Vercel yang beneran saya pakai. Ini yang akhirnya saya lakukan. Lewat Project Settings → General, pindahkan project ke akun yang ter-link ke akun GitHub didiet86. Catatan: transfer antar akun Hobby butuh akses ke dua-duanya, dan setup environment variables harus diulang di akun tujuan.
2. Samakan identitas commit dengan akun GitHub yang ter-link ke Vercel. Ini yang saya lakuin duluan sebelum sadar masalahnya bukan di situ, dan ternyata emang perlu juga sebagai langkah dasar. Email git harus terdaftar (verified) di akun GitHub yang terhubung ke Vercel.
3. Pakai Deploy Hooks buat deploy tanpa integrasi Git. Kalau nggak mau ubah identitas commit, Vercel punya Deploy Hooks, URL khusus yang bisa di-POST buat memicu deploy, nggak peduli siapa author commitnya. Arahkan CI untuk push ke GitHub biasa, lalu trigger hook ini setelahnya.
4. Deploy via CLI/CI dengan token, abaikan integrasi Git. Jalankan vercel deploy langsung dari pipeline (GitHub Actions, atau di kasus saya: agent yang jalan di VPS). Identitas commit jadi nggak relevan karena deploy-nya nggak lewat integrasi Git. Autentikasi pakai VERCEL_TOKEN, bukan metadata git.

Yang saya pilih: opsi 1 + 2 digabung. Project ditransfer ke akun yang bener, identitas commit disamakan dengan akun GitHub yang ter-link. Beres, deploy langsung jalan tanpa commit "retrigger" lagi.

Buat kamu yang pakai AI agent (Hermes, Claude Code, Cursor, dan lainnya): urutan pengecekan yang sekarang jadi SOP saya. (1) Buka dashboard Vercel, lihat nama tim/akun pemilik project. (2) Account Settings → Login Connections, pastikan akun GitHub yang ter-link memang akun yang push commit. (3) Jalankan git config user.email di mesin yang bikin commit, cocokkan dengan email terverifikasi di akun GitHub itu. (4) Masih bingung? Baca Activity Log, bukan dashboard deployment. Empat langkah ini bakal menyelamatkan kamu dari tiga hari kayak punya saya.

Kesalahan saya: mengasumsikan masalah ada di layer yang salah. Tiga hari penuh ngutak-atik git config, padahal git-nya nggak pernah salah. Error message Vercel ("commit author is not a valid email address") nyesatin karena emang valid; yang nggak valid itu hubungannya sama akun Vercel yang own project.

Dan satu lagi: commit kosong berpesan "chore: retrigger Vercel deploy" itu nggak akan nolong kalau masalahnya di ownership. Udah saya buktikan tiga hari. Wkwkwk.