Apa itu Coolify dan bedanya dengan Vercel?

Coolify adalah platform deployment open-source yang bisa di-install di VPS sendiri. Fitur intinya mirip Vercel — build otomatis dari Git, preview per-branch, custom domain, SSL otomatis — tapi semuanya jalan di infrastruktur kamu sendiri. Perbedaan terbesar: Vercel gratis untuk personal tapi berbayar cepat saat traffic tinggi atau team plan, sedangkan Coolify gratis selamanya selama kamu bayar server sendiri. Coolify juga support Docker Compose dan backend services seperti Postgres atau Redis, sesuatu yang Vercel tidak bisa lakukan secara native.

Bagaimana cara Coolify membuat preview deployment per pull request?

Coolify menggunakan webhook GitHub/GitLab untuk mendeteksi event PR opened atau push ke branch non-main. Setiap branch mendapat subdomain dinamis dari wildcard domain yang kamu konfigurasi, misalnya feature-login.preview.kodekarawaci.com. Coolify menjalankan build di server menggunakan Nixpacks atau Dockerfile, lalu Traefik (reverse proxy bawaan Coolify) otomatis routing subdomain itu ke container yang baru. Saat PR ditutup, container dan subdomain dibersihkan otomatis.

Berapa spesifikasi VPS minimum untuk menjalankan Coolify dengan preview deployments?

Coolify sendiri butuh sekitar 2 vCPU dan 2 GB RAM untuk idle. Tapi kalau mau menjalankan preview deployments aktif secara bersamaan, saya rekomendasikan minimal 4 vCPU dan 8 GB RAM. Setiap preview container bisa makan 200-500 MB RAM tergantung aplikasi. Di Hetzner CPX31 (4 vCPU, 8 GB, sekitar 200 ribu rupiah per bulan) saya bisa menjalankan 6-8 preview containers bersamaan dengan nyaman. Kalau tim kecil 3-5 orang dengan PR yang tidak terlalu banyak terbuka sekaligus, CPX21 (4 GB) sudah cukup.

Apakah Coolify support monorepo dengan multiple apps?

Ya, Coolify support satu repository dengan beberapa services berbeda. Kamu bisa membuat beberapa Application di dalam satu Project di Coolify, masing-masing menunjuk ke repository yang sama tapi dengan build context atau Dockerfile yang berbeda. Untuk monorepo Turborepo atau Bun workspaces, kamu set Build Command ke perintah yang spesifik per-app, misalnya cd apps/api && bun run build. Preview deployment bisa dikonfigurasi per-application, jadi branch yang sama bisa memicu build di beberapa apps sekaligus.

Apa yang harus dipersiapkan di DNS sebelum wildcard preview deployments bisa jalan?

Kamu butuh wildcard DNS record yang mengarah ke IP VPS Coolify. Tambahkan A record *.preview.domainmu.com ke IP server. Pastikan juga DNS provider kamu support wildcard — Cloudflare, Route53, dan sebagian besar provider modern mendukung ini. Coolify akan otomatis provision SSL certificate untuk subdomain wildcard menggunakan Let's Encrypt DNS challenge atau HTTP challenge via Traefik. Khusus wildcard SSL dengan Let's Encrypt, kamu butuh menggunakan DNS challenge yang memerlukan API key dari DNS provider karena HTTP challenge tidak bisa untuk wildcard.

Preview Deployment Self-Hosted dengan Coolify: Alternatif Vercel On-Premise

Salah satu fitur Vercel yang paling bikin developer ketagihan adalah preview deployment — setiap push ke branch langsung punya URL sendiri yang bisa di-share ke klien atau QA. Masalahnya, begitu skala naik atau kamu kerja di project enterprise yang tidak bisa kode-nya keluar ke cloud publik, Vercel tidak lagi jadi opsi. Saya pernah di posisi itu dengan klien Jakarta yang datanya wajib on-premise, dan jawabannya adalah Coolify.

Kenapa Preview Deployment Itu Penting

Tim yang belum punya preview deployment biasanya jatuh ke salah satu dari dua pola buruk: review PR sambil jalankan di local sendiri (lambat, tidak sesuai environment), atau deploy manual ke staging sebelum review (berantakan kalau ada beberapa PR aktif sekaligus). Preview per-branch memecah masalah itu — setiap branch punya environment terisolasi yang bisa dilihat tanpa setup apapun.

Vercel menyelesaikan ini dengan sangat baik di sisi managed, tapi harganya tidak bersahabat untuk tim yang lebih dari beberapa orang atau project yang trafficnya tidak bisa terprediksi. Netlify serupa. Railway punya konsep environment tapi bukan preview deployment yang benar-benar per-branch. Fly.io bisa kalau mau konfigurasi sendiri lewat CI, tapi effort-nya signifikan.

Coolify mengisi gap ini: feature paritas yang cukup dekat dengan Vercel untuk preview deployment, bisa jalan di VPS sendiri, dan gratis.

Setup Coolify dari Nol

Installasi Coolify di VPS cukup satu perintah. Saya pakai Hetzner CPX31 dengan Ubuntu 24.04:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Script itu menginstall Docker, mengkonfigurasi Traefik sebagai reverse proxy, dan menjalankan Coolify UI di port 8000. Setelah itu akses http://IP-SERVER:8000 untuk setup awal, buat akun admin, dan konfigurasi domain untuk Coolify instance-nya sendiri.

Sebelum lanjut, konfigurasi wildcard DNS dulu. Di Cloudflare:

Type: A
Name: *.preview
Value: <IP VPS>
Proxy: DNS only (grey cloud) — penting, bukan proxied
TTL: Auto

Dan satu lagi untuk root subdomain kalau mau Coolify UI-nya di domain sendiri:

Type: A
Name: coolify
Value: <IP VPS>

Wildcard SSL untuk *.preview.domainmu.com butuh DNS challenge. Coolify support beberapa provider lewat Traefik DNS challenge. Di settings Coolify, masuk ke Settings > Configuration > Let’s Encrypt dan aktifkan wildcard. Untuk Cloudflare, tambahkan API token dengan permission Zone:Read dan DNS:Edit.

Membuat Project dan Application

Di Coolify, struktur hierarkinya: Server → Project → Environment → Application. Untuk preview deployment:

Buat Project baru, misalnya tangerang-saas
Di dalam project, buat dua Environment: production dan preview
Di environment preview, buat Application baru dan connect ke repository

Konfigurasi Application yang paling krusial adalah bagian Preview Deployments. Enable toggle-nya, lalu set template subdomain:

Preview URL template: {branch}.preview.domainmu.com

Variabel {branch} akan diganti nama branch secara otomatis, tapi dengan sanitasi — karakter yang tidak valid untuk subdomain (seperti / atau _) otomatis diubah ke -.

Untuk build configuration, Coolify bisa auto-detect stack menggunakan Nixpacks. Tapi untuk kontrol penuh, lebih baik pakai Dockerfile:

FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json bun.lockb ./
RUN npm install -g bun && bun install --frozen-lockfile

FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN bun run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

Webhook dan Trigger Otomatis

Coolify perlu menerima event dari GitHub untuk memicu build otomatis. Di halaman Application, copy webhook URL yang disediakan, lalu tambahkan di GitHub repository:

Settings → Webhooks → Add webhook

Payload URL: https://coolify.domainmu.com/api/v1/applications/<APP-ID>/webhooks/github
Content type: application/json
Secret: <dari Coolify>
Events: Push, Pull requests

Setelah ini, setiap push ke branch apapun (selain branch yang dikonfigurasi sebagai production) akan otomatis memicu preview build. Coolify akan:

Clone branch yang baru di-push
Build Docker image
Deploy container dengan subdomain nama-branch.preview.domainmu.com
Provision SSL otomatis via Traefik

Kalau PR ditutup atau branch dihapus, Coolify menerima event itu dan menghentikan serta menghapus container preview-nya. Tidak ada resource yang terbuang.

Environment Variables per Preview

Satu hal yang sering jadi pertanyaan: bagaimana handle environment variables yang berbeda antara production dan preview? Coolify punya dua level env vars:

Shared — berlaku untuk semua deployments dalam satu Environment
Per-application — spesifik satu Application

Untuk preview, biasanya saya set env vars di level Environment preview yang menunjuk ke service development, misalnya database staging:

DATABASE_URL=postgresql://user:[email protected]:5432/myapp_staging
REDIS_URL=redis://redis-staging.internal:6379
NODE_ENV=staging

Variabel ini otomatis tersedia di semua preview containers dalam environment itu. Kalau ada variabel yang perlu berbeda per-branch (misalnya feature flag), kamu bisa tambahkan preview-specific vars di konfigurasi Application dan gunakan variabel {branch} di value-nya untuk substitusi dinamis.

Resource Limits Supaya Tidak Saling Bunuh

Tanpa resource limits, satu preview yang kebetulan memory-hungry bisa mengganggu preview lain atau bahkan Coolify sendiri. Tambahkan limits di konfigurasi Application:

# Di Coolify Advanced Settings → Docker Configuration
memory: 512m
memory_swap: 512m
cpu_shares: 512

Atau kalau kamu prefer Docker Compose override, Coolify support docker-compose.coolify.yml di root repository yang di-merge dengan konfigurasi Coolify saat build.

Trade-off yang Perlu Kamu Terima

Coolify bukan Vercel. Perbedaan yang paling terasa di production:

Build speed lebih lambat. Vercel punya build cache yang sangat agresif di infrastruktur mereka. Di Coolify, layer cache Docker ada tapi terbatas pada satu server. Build pertama setelah server restart atau image prune bisa jalan dari nol. Di proyek React besar, ini bisa 5-8 menit vs 2-3 menit di Vercel.

Operasional jatuh ke kamu. Server down berarti semua preview down. Kamu perlu monitoring sendiri, update Coolify sendiri (mereka rilis cukup aktif), dan pastikan disk tidak penuh karena image Docker menumpuk. Saya pasang alerting Uptime Robot ke Coolify health endpoint dan cron job mingguan untuk docker system prune -f.

Tidak ada edge network. Vercel punya CDN global; Coolify deployments jalan di satu region. Untuk preview yang tujuannya review internal, ini tidak masalah. Untuk preview yang di-share ke klien global, latency bisa terasa.

Wildcard SSL bisa tricky. Kalau DNS provider kamu tidak support API-based DNS challenge, wildcard SSL tidak bisa di-provision otomatis. Kamu terpaksa pakai per-domain SSL yang harus di-request manual tiap ada branch baru — ini praktis menghilangkan nilai preview deployment.

Kapan Coolify Tepat, Kapan Tidak

Coolify masuk akal kalau:

Tim kecil (2-8 orang) yang tidak mau bayar Vercel Team plan
Project dengan requirement data harus on-premise
Kamu sudah punya VPS yang belum dipakai penuh dan mau efisiensi biaya
Backend-heavy project yang juga perlu deploy Postgres, Redis, atau workers di environment yang sama

Coolify kurang cocok kalau:

Kamu deploy ke audience global dan latency edge sangat penting
Tim tidak ada yang mau handle maintenance server
Project sudah at scale di Vercel dan tidak ada pain point biaya — migrasi effort tidak worth it
Butuh integrasi native dengan ecosystem Vercel (Edge Functions, middleware yang di-distribute secara global, dll)

Untuk klien Jakarta yang saya ceritakan di awal — Coolify jalan stabil sejak 8 bulan lalu, rata-rata 5-7 preview containers aktif bersamaan, di Hetzner CPX31. Total biaya infrastructure sekitar 250 ribu per bulan, versus estimasi Vercel Pro yang bisa 800-900 ribu per bulan untuk ukuran tim yang sama.

Verdict

Kalau kamu Gen Z developer yang baru mulai bangun SaaS atau product sambil kerja, Coolify adalah cara paling cost-effective untuk punya developer experience yang mendekati Vercel tanpa bayar premium. Setup awalnya butuh 2-3 jam untuk benar-benar smooth, terutama bagian wildcard SSL dan webhook GitHub. Setelah itu mostly jalan sendiri.

Investasikan waktu untuk memahami bagaimana Traefik routing-nya bekerja — itu yang sering jadi sumber kebingungan pertama. Dokumentasi Coolify cukup bagus untuk kasus umum, tapi untuk edge case seperti monorepo atau custom health checks, kamu perlu baca konfigurasi Traefik label secara langsung.

Self-hosted bukan untuk semua orang, tapi untuk yang mau kontrol penuh atas infrastruktur dengan budget terbatas, Coolify adalah salah satu tool yang paling worth untuk dipelajari di 2026.