Category: Software Development

Deploy Aplikasi Gratis di 2026: Vercel, Railway, Fly.io — Mana Terbaik?

“Deploy dulu, urusin server nanti” — itu dulu moto yang agak ironis karena deploy itu tidak pernah semudah kedengarannya.

Sekarang? Lanskap-nya sudah berubah cukup signifikan. Ada beberapa platform yang genuinely memudahkan deploy aplikasi tanpa harus punya background DevOps yang dalam, dan sebagian besar punya free tier yang cukup layak untuk project personal atau MVP.

Tapi “gratis” tidak berarti sama. Ada batasan, ada trade-off, dan ada situasi di mana masing-masing platform bersinar — atau gagal. Artikel ini tentang itu.

---

Kriteria Perbandingan

Saya bandingkan tiga platform ini berdasarkan:

• Free tier yang sebenarnya bisa dipakai (bukan hanya di marketing page)
• Kemudahan deploy untuk project nyata
• Support untuk stack yang umum dipakai
• Performa dan reliability
• Pengalaman ketika project mulai tumbuh dan butuh upgrade

---

Vercel: Raja Frontend, Terbatas di Backend

Kelebihan

Vercel adalah pilihan terbaik — mungkin yang terbaik di kelasnya — untuk frontend dan full-stack Next.js. Kalau kamu pakai Next.js, deploy ke Vercel itu semudah push ke GitHub. Literally.

• Zero-config deployment untuk Next.js, Nuxt, SvelteKit, Astro, dan framework modern lainnya
• Edge network global yang membuat website terasa cepat di mana pun pengunjung berada
• Preview deployments otomatis untuk setiap pull request — ini killer feature untuk kolaborasi
• Analytics built-in tanpa setup tambahan
• Free tier cukup generous untuk project personal: unlimited deployments, 100GB bandwidth

Kekurangan

Kalau kamu butuh backend yang “sesungguhnya” — persistent server, long-running process, WebSocket — Vercel mulai menunjukkan batasnya.

• Serverless functions punya execution time limit (default 10 detik, bisa diperpanjang tapi berbayar)
• Tidak cocok untuk aplikasi yang butuh persistent state tanpa external database
• Database tidak disediakan — kamu perlu koneksi ke service eksternal (PlanetScale, Supabase, Neon, dll.)
• Cold start bisa terasa di serverless functions

Free Tier Reality Check

Free tier Vercel itu nyata bisa dipakai untuk:

• Portfolio website
• Blog atau marketing site
• SaaS kecil dengan Next.js
• Side project yang traffic-nya belum besar

Mulai bermasalah ketika: traffic tinggi, butuh bandwidth besar, atau perlu serverless function yang lama.

Verdict Vercel

Pakai Vercel kalau: Project kamu adalah Next.js, Nuxt, atau frontend-heavy. Deploy di sini sebelum pertimbangkan yang lain.

---

Railway: Paling Fleksibel untuk Full-Stack

Railway adalah platform yang terasa paling “developer friendly” untuk aplikasi full-stack yang butuh backend nyata.

Kelebihan

• Deploy apa saja — Node.js, Python, Go, Ruby, PHP, Rust — kalau ada Dockerfile, Railway bisa menjalankannya
• Database termasuk — PostgreSQL, MySQL, Redis, MongoDB tersedia langsung tanpa konfigurasi eksternal
• Persistent servers — tidak seperti Vercel, server kamu jalan terus, tidak ada cold start issue
• Pricing yang transparan — kamu bayar berdasarkan usage (CPU, memory, network), bukan per “feature”
• UI yang intuitif — setup service baru itu semudah klik beberapa kali
• Monorepo support yang bagus

Kekurangan

• Free tier di Railway sudah berubah beberapa kali — sekarang sistemnya kredit $5/bulan. Cukup untuk project kecil, tapi kalau project kamu mulai grow, biaya naik
• Tidak se-opinionated Vercel — artinya kamu perlu configure sendiri lebih banyak hal
• Region terbatas — tidak se-global Vercel dari sisi edge

Free Tier Reality Check

$5 kredit per bulan itu cukup untuk menjalankan:

• Satu backend service kecil (Node.js atau Python)
• Satu database PostgreSQL atau MySQL
• Dengan traffic yang wajar

Tapi kalau aplikasi kamu mulai sering diakses atau database-nya membesar, kredit habis dan kamu perlu upgrade.

Verdict Railway

Pakai Railway kalau: Kamu butuh full-stack app dengan database, server persisten, dan tidak mau ribet konfigurasi. Ini sweet spot Railway.

---

Fly.io: Paling Powerful, Paling Banyak Setup

Fly.io adalah yang paling mendekati “hosting yang sesungguhnya” di antara ketiganya — tapi dengan kemudahan yang lebih baik dari VPS tradisional.

Kelebihan

• Global distribution nyata — deploy container kamu ke multiple region dengan mudah
• Persistent volumes — disk storage yang persisten per app
• Support penuh untuk WebSocket dan long-running connections
• Free tier generous — 3 shared-CPU VMs, 3GB persistent volumes per bulan
• Fly Postgres — database yang hidup dekat dengan app kamu di region yang sama
• Docker-native — kalau kamu punya Dockerfile, Fly bisa deploy

Kekurangan

• Kurva belajar lebih tinggi — deploy pertama butuh beberapa langkah lebih banyak
• flyctl CLI — banyak hal harus dilakukan via CLI, bukan GUI
• Free tier bisa confusing — limitnya ada di “shared CPU seconds” yang butuh hitungan untuk pahami
• Support lebih “community-based” dibanding Railway atau Vercel

Free Tier Reality Check

Free tier Fly.io cukup untuk:

• 2-3 small app yang tidak selalu aktif
• Database PostgreSQL kecil
• App yang butuh persistent storage

Yang perlu diperhatikan: app di free tier akan di-scale down ketika tidak ada traffic, artinya cold start ketika ada pengunjung baru.

Verdict Fly.io

Pakai Fly.io kalau: Kamu butuh kontrol lebih atas infrastruktur, perlu deploy ke multiple region, atau punya app yang butuh persistent storage dengan performa baik.

---

Perbandingan Cepat

| Aspek | Vercel | Railway | Fly.io |

|——-|——–|———|——–|

| Frontend | Terbaik | Bagus | Cukup |

| Backend | Terbatas | Bagus | Terbaik |

| Database | Eksternal | Built-in | Built-in |

| Kemudahan | Sangat Mudah | Mudah | Moderate |

| Kontrol | Rendah | Medium | Tinggi |

| Free Tier | Generous | $5 kredit | 3 VMs |

| Global Edge | Ya | Tidak | Ya |

---

Rekomendasi Berdasarkan Skenario

Project Next.js / frontend-heavy: → Vercel, jangan pikir dua kali

API backend + database, scale kecil: → Railway untuk kemudahan, Fly.io untuk kontrol lebih

App yang butuh WebSocket atau long-running process: → Fly.io atau Railway

Side project yang mau “set and forget”: → Railway (lebih mudah) atau Fly.io (lebih generous free tier untuk server)

Tim yang mau preview deployment otomatis: → Vercel atau Railway (keduanya punya fitur ini)

---

Satu Pendekatan yang Saya Suka

Untuk banyak project, kombinasi yang bekerja dengan baik:

• Vercel untuk frontend / Next.js
• Railway atau Supabase untuk database
• Fly.io untuk service backend yang butuh persistence atau WebSocket

Ini “stack gratis” yang cukup capable untuk menjalankan produk yang sesungguhnya sampai traction yang meaningful.

---

Penutup

Pilihan terbaik tergantung pada nature project kamu. Tidak ada jawaban universal.

Yang pasti: di 2026 ini, tidak ada alasan untuk tidak deploy karena “servernya mahal” atau “ribet konfigurasi”. Ketiga platform ini sudah jauh menyederhanakan proses tersebut.

Punya project yang butuh bantuan setup deployment atau arsitektur cloud yang tepat? Hubungi mafadev — kita diskusikan pilihan terbaik untuk kebutuhan spesifik kamu.

Docker untuk Developer Solo: Setup Minimal yang Cukup

Jujur ya — pertama kali dengar Docker, saya pikir ini alat buat tim DevOps gede di perusahaan besar. Ternyata? Justru developer solo yang paling butuh Docker. Kamu yang kerja sendirian, sering pindah laptop, atau sering ngerjain project berbeda-beda — Docker itu bukan kemewahan, ini kebutuhan.

Artikel ini bukan tutorial Docker dari nol sampai production cluster. Ini tentang setup seminimal mungkin yang langsung berguna untuk kamu yang kerja sendiri.

---

Kenapa Developer Solo Butuh Docker?

Sebelum masuk ke setup, kita perlu sepakat dulu soal masalahnya.

Sebagai developer solo, kamu sering menghadapi situasi seperti gini:

• Project A pakai Node 18, Project B masih Node 16 — install dua versi sekaligus? Ribet.
• Membuat app yang butuh PostgreSQL dan Redis — install langsung di laptop? Kotor banget.
• Mau beri akses ke client supaya bisa mencoba aplikasi kamu — “works on my machine” bukan jawaban yang bisa diterima.
• Ganti laptop baru — setup ulang dari awal? Nguras waktu dan tenaga.

Docker menyelesaikan semua itu. Bukan dengan cara yang kompleks, tapi dengan konsep sederhana: setiap aplikasi atau service punya “kotak” sendiri yang terisolasi.

---

Yang Perlu Dipahami Dulu (Tanpa Basa-basi)

Tiga konsep utama Docker yang perlu kamu pegang:

Image

Ini blueprint. Seperti resep masakan — berisi instruksi untuk membuat environment tertentu. Image tidak jalan, image hanya deskripsi.

Container

Ini hasil eksekusi image. Container yang jalan, container yang bisa dipakai. Kamu bisa jalankan banyak container dari satu image yang sama.

Volume

Tempat menyimpan data yang persisten. Karena container itu fana — kalau dihapus, datanya hilang. Volume yang membuat data tetap ada meskipun containernya mati.

Sudah. Tiga itu dulu. Sisanya bisa belajar sambil jalan.

---

Setup Minimal untuk Developer Solo

1. Install Docker Desktop

Kalau kamu pakai Windows atau Mac, install Docker Desktop. Sudah include semua yang dibutuhkan — Docker Engine, Docker Compose, dan GUI kalau mau.

Kalau Linux, install Docker Engine langsung:

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

Tambah user kamu ke grup docker supaya tidak perlu sudo terus:

sudo usermod -aG docker $USER

Log out lalu log in lagi.

2. Forget Docker Commands, Fokus ke Docker Compose

Ini tip paling penting yang jarang disampaikan ke pemula: jangan hafal docker run dulu. Langsung pakai Docker Compose.

Docker Compose memungkinkan kamu define seluruh setup aplikasi dalam satu file docker-compose.yml. Lebih mudah dibaca, lebih mudah di-share, lebih mudah diulang.

Contoh file docker-compose.yml untuk project web sederhana dengan PostgreSQL:

version: '3.8'

services:
app:
build: .
ports:
- "3000:3000"
environment:
- DATABASE_URL=postgresql://user:password@db:5432/mydb
depends_on:
- db
volumes:
- .:/app
- /app/node_modules

db:
image: postgres:15
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: password
POSTGRES_DB: mydb
volumes:
- postgres_data:/var/lib/postgresql/data
ports:
- "5432:5432"

volumes:
postgres_data:

Untuk jalankan semuanya:

docker compose up -d

Untuk stop:

docker compose down

Simpel. Dua perintah ini yang paling sering kamu pakai.

3. Dockerfile yang Tidak Berlebihan

Untuk project Node.js, ini Dockerfile yang cukup untuk development:

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["npm", "run", "dev"]

Pakai Alpine image karena ukurannya kecil. COPY package*.json dulu sebelum source code supaya layer cache-nya efisien — kalau source code berubah tapi package.json tidak, Docker tidak perlu install ulang dependency.

---

Workflow Harian yang Praktis

Ini pattern yang saya pakai sehari-hari:

Mulai kerja:

docker compose up -d

Cek logs kalau ada masalah:

docker compose logs -f app

Masuk ke dalam container:

docker compose exec app sh

Jalankan perintah di dalam container:

docker compose exec app npm run migrate

Selesai kerja:

docker compose down

---

Tips Khusus Developer Solo

Jangan simpan credentials di Dockerfile. Pakai file .env dan tambahkan ke .gitignore. Di docker-compose.yml gunakan:

env_file:
- .env

Simpan image yang sering dipakai. Redis, PostgreSQL, MySQL — pull sekali, pakai berkali-kali tanpa koneksi internet.

Buat alias di shell kamu. Kalau capek menulis docker compose up -d, buat alias:

alias dcu="docker compose up -d"
alias dcd="docker compose down"
alias dcl="docker compose logs -f"

Bersihkan secara berkala. Docker bisa makan disk lumayan banyak kalau dibiarkan:

docker system prune -a

Hati-hati — ini hapus semua image yang tidak sedang dipakai. Pastikan kamu tidak perlu image-image itu lagi.

---

Kapan Tidak Perlu Docker?

Docker bukan solusi untuk semua masalah. Kalau kamu cuma buat script Python sederhana yang tidak butuh service eksternal, tidak perlu Docker. Kalau kamu buat static site, tidak perlu Docker untuk development.

Pakai Docker ketika:

• Project kamu butuh database atau service eksternal (Redis, Elasticsearch, dll.)
• Kamu mau konsistensi environment antara development dan production
• Kamu sering onboarding orang baru ke project kamu
• Kamu mau bisa restore setup dengan cepat di laptop baru

---

Penutup

Docker untuk developer solo bukan tentang jadi DevOps handal. Ini tentang tidak buang waktu setup ulang setiap ganti laptop, tidak debat “works on my machine” sama client, dan punya environment yang bersih untuk setiap project.

Setup minimal yang saya bagikan di atas sudah cukup untuk 80% kebutuhan developer solo. Sisanya bisa belajar sambil jalan — Docker punya ekosistem yang besar, tapi fondasinya sederhana.

Mulai dengan satu project, buat docker-compose.yml-nya, dan rasakan bedanya.

Punya project yang butuh setup Docker yang proper atau bantuan containerisasi aplikasinya? Yuk ngobrol — hubungi mafadev dan kita diskusikan bareng.

Setiap kali ada project baru, pertanyaan ini hampir selalu muncul: REST atau GraphQL?

Saya sudah pakai keduanya di berbagai project — dari side project kecil sampai sistem yang dipakai ribuan user. Dan jawaban jujur saya adalah: keduanya bagus, tergantung konteks. Tapi “tergantung konteks” itu sering terasa seperti jawaban yang tidak membantu.

Jadi artikel ini akan lebih spesifik: kapan REST adalah pilihan tepat, kapan GraphQL lebih masuk akal, dan apa red flag yang menandakan kamu salah pilih.

REST API: Pondasi yang Tidak Kemana-mana

REST (Representational State Transfer) sudah ada sejak lama. Hampir semua backend developer pernah membuat REST API — dan itu bukan kebetulan.

Kelebihan REST yang Sering Diremehkan

Simplicity yang genuine. REST itu konseptual straightforward: resource punya URL, HTTP method (GET, POST, PUT, DELETE) menentukan aksi. Tidak perlu schema, tidak perlu query language khusus.

Kalau kamu onboarding developer baru ke project, mereka bisa paham REST endpoint dalam hitungan menit. Itu valuable banget di tim.

Caching yang built-in dan proven. HTTP caching bekerja dengan sangat baik untuk REST. Browser, CDN, reverse proxy — semua sudah tau cara handle GET request yang cacheable. Untuk aplikasi yang read-heavy dengan data yang tidak sering berubah, ini performance gain yang gratis.

Tooling yang mature. Postman, curl, browser dev tools, monitoring tools — semua bekerja native dengan REST. Debugging lebih mudah karena setiap request adalah URL yang bisa kamu buka langsung di browser (untuk GET).

Stateless by design. Tiap request membawa semua informasi yang dibutuhkan. Ini membuat horizontal scaling lebih mudah dan sistem lebih predictable.

Kapan REST Pilihan Tepat

• Public API yang akan dipakai third party — mereka expect REST dan lebih nyaman consume-nya
• Service sederhana dengan resource yang well-defined dan tidak banyak relasi
• Tim kecil atau project kecil di mana overhead setup GraphQL tidak worth it
• Butuh caching yang kuat (terutama untuk public data)
• Microservices yang komunikasinya sederhana

---

GraphQL: Power yang Datang dengan Complexity

GraphQL dikembangkan oleh Facebook (sekarang Meta) dan dirilis ke publik di 2015. Ini bukan teknologi baru lagi — sudah cukup mature dan banyak dipakai di production.

Apa yang GraphQL Selesaikan

GraphQL muncul karena ada masalah nyata dengan REST di aplikasi yang kompleks:

Over-fetching. Kamu hit endpoint /api/users/123 tapi cuma butuh nama dan email — tapi yang datang adalah seluruh objek user dengan 30+ fields. Bandwidth dan processing yang terbuang.

Under-fetching. Kamu butuh data user + list post mereka + profil picture — tapi harus hit 3 endpoint berbeda. Ini membuat N+1 requests yang memperlambat aplikasi.

Versioning yang painful. Setiap kali ada perubahan kebutuhan data di frontend, backend harus update atau membuat endpoint versi baru.

GraphQL menyelesaikan ini dengan pendekatan: client yang menentukan data apa yang dibutuhkan.

query {
user(id: "123") {
name
email
posts(limit: 5) {
title
publishedAt
}
}
}

Satu request, dapat persis data yang dibutuhkan. Tidak lebih, tidak kurang.

Kelebihan GraphQL yang Nyata

Satu endpoint, banyak query. Dibanding puluhan REST endpoint, GraphQL hanya punya satu entry point. Client query apa yang mereka butuhkan.

Strongly typed schema. GraphQL schema adalah kontrak antara backend dan frontend. Kedua tim bisa bekerja paralel berdasarkan schema yang sudah disepakati, bahkan sebelum implementasinya selesai.

Introspection. GraphQL API bisa “mendeskripsikan dirinya sendiri”. Tool seperti GraphiQL atau Apollo Studio bisa auto-generate dokumentasi dari schema.

Ideal untuk relasi data yang complex. Kalau data kamu sangat relational dan frontend butuh banyak kombinasi berbeda, GraphQL sangat elegant.

Realita GraphQL yang Harus Kamu Tau

Learning curve itu nyata. Query language, schema definition, resolver, N+1 problem (ya, GraphQL punya versinya sendiri), batching dengan DataLoader — ini semua hal yang harus kamu pelajari dan implement dengan benar.

Caching lebih susah. Karena semua request ke satu endpoint dengan HTTP POST, caching berbasis URL tidak berlaku. Kamu butuh application-level caching atau tool khusus seperti Apollo Client.

Security lebih complex. GraphQL memungkinkan query yang sangat nested dan expensive. Tanpa rate limiting dan query complexity analysis, API kamu rentan terhadap denial-of-service melalui query yang mahal.

Over-engineering risk. Saya pernah lihat project kecil yang pakai GraphQL padahal REST endpoint 5 biji sudah cukup. Hasilnya: complexity yang tidak sebanding dengan benefit.

---

Perbandingan Langsung: Kasus Nyata

Kasus 1: E-commerce sederhana (catalog, cart, checkout)

Rekomendasi: REST

Operasinya straightforward, resource-nya well-defined (products, orders, users), dan caching untuk catalog produk sangat valuable. REST lebih dari cukup, dan onboarding developer baru lebih mudah.

Kasus 2: Platform media sosial dengan feed kompleks

Rekomendasi: GraphQL

Feed yang personalized butuh kombinasi data yang berbeda-beda tergantung user, device, dan context. GraphQL memungkinkan setiap client ambil data yang tepat tanpa over-fetch. Ini exactly use case di mana GraphQL bersinar.

Kasus 3: Internal dashboard / admin panel

Rekomendasi: Tergantung

Kalau datanya sudah dari REST API yang ada, consume langsung dari REST. Kalau kamu build dari scratch dan datanya complex, GraphQL bisa masuk akal. Tapi untuk admin panel dengan tim kecil, REST sering lebih pragmatis.

Kasus 4: Public API untuk third-party developer

Rekomendasi: REST

Third-party developer expect REST dan sudah familiar dengan HTTP, curl, dan Postman. GraphQL punya learning curve yang bisa jadi barrier untuk adopsi.

---

Tren di 2026: Apa yang Berubah?

Beberapa tahun terakhir, ada beberapa perkembangan menarik:

tRPC naik daun untuk full-stack TypeScript project — ini alternatif yang menarik untuk keduanya, khususnya kalau kamu pakai Next.js.

REST + OpenAPI semakin kuat — dengan tooling seperti Swagger UI dan auto-generated client, REST modern lebih developer-friendly dari sebelumnya.

GraphQL Federation memungkinkan multiple GraphQL service digabung jadi satu schema — ini membuat GraphQL lebih viable untuk microservices architecture.

AI-generated API clients — dengan AI, generate client dari REST atau GraphQL schema jadi jauh lebih mudah, mengurangi salah satu pain point dari kedua pilihan.

---

Kesimpulan Pragmatis

Kalau harus ringkas jadi satu guideline:

• Mulai dengan REST. Ini default yang reasonable untuk sebagian besar project. Simpel, proven, tooling mature.
• Pertimbangkan GraphQL ketika kamu punya multiple client (web, mobile, third-party) dengan kebutuhan data yang berbeda, atau data relations yang sangat kompleks.
• Jangan over-engineer. Pilihan teknologi terbaik adalah yang bisa kamu deliver dengan cepat dan maintain dengan nyaman.

Dan ingat: kamu bisa punya keduanya. Beberapa project besar pakai REST untuk public API dan GraphQL untuk internal/mobile client. Ini bukan pilihan mutually exclusive.

---

Lagi desain arsitektur backend untuk project baru dan tidak yakin mau pilih yang mana? Atau sudah mulai dan merasa ada yang tidak beres? Hubungi mafadev — saya senang diskusi dan bantu kamu buat keputusan yang tepat untuk konteks kamu.