Mengganti tagihan Heroku $3.000/bulan dengan server $55/bulan

• Platform lowongan kerja nirlaba Idealist bermigrasi ke server dedicated berbiaya rendah untuk mengatasi masalah biaya environment staging yang mahal di Heroku
• Di Heroku, karena struktur penagihan per environment, setiap environment staging menimbulkan biaya sekitar $500 per bulan
• Sebagai gantinya, mereka menyiapkan beberapa environment pada satu server Hetzner CCX33 ($55/bulan), sambil mempertahankan pengalaman git push dan otomasi yang sama seperti Heroku melalui Disco
• Enam environment staging berjalan stabil di satu server, dengan penggunaan CPU 2% dan memori 14GB dari total 32GB, sehingga masih sangat longgar
• Dengan ini, environment staging berubah dari 'sumber beban biaya' menjadi 'resource yang bisa dibuat dengan bebas', dan budaya eksperimen serta deployment tim pengembang meningkat besar

---

Pengalaman strategi praktis menghemat biaya Heroku

Masalah: environment staging $500 per bulan

• Idealist.org adalah platform lowongan kerja nirlaba berskala besar yang dikunjungi jutaan orang setiap bulan, sehingga environment staging yang hampir identik dengan produksi menjadi hal yang penting
• Di Heroku, biaya satu environment staging yang menggabungkan web/worker dyno dan add-on yang diperlukan seperti Postgres mencapai sekitar $500/bulan
• Bahkan jika hanya mempertahankan dua environment, dev dan main, biaya tetapnya sudah melebihi $1.000
• Model harga Heroku adalah penagihan per environment; meski jumlah dyno dikurangi, penghematan biayanya kecil, dan biaya melonjak tajam seiring bertambahnya aplikasi

Eksperimen: pindah ke satu server

• Untuk penghematan biaya yang ideal, mereka mulai bereksperimen dengan menyewa satu server Hetzner CCX33 ($55/bulan)
• Dengan memanfaatkan solusi Disco, metode deployment git push Heroku yang sudah ada diterapkan langsung ke server
• Semua environment staging memanfaatkan instance Postgres bersama di server yang sama, sehingga beban biaya database terkelola dapat ditekan secara signifikan
• Dari sudut pandang pengujian, pendekatan ini juga cocok karena database terpisah per pengembang bisa diinisialisasi ulang dengan mudah

Mengapa memakai Disco: perbedaannya dibanding Docker Compose

• Hanya menjalankan docker-compose up di server saja tidak cukup memberikan pengalaman pengembang yang baik
• Disco menawarkan kelebihan berikut
  • Proses deployment git push yang sama seperti Heroku
  • Dukungan deployment zero-downtime otomatis untuk semua deployment
  • Penerbitan dan pembaruan sertifikat SSL otomatis untuk URL per branch
  • Web UI yang intuitif untuk pengelolaan log dan environment
• Dengan begitu, mereka tetap mendapatkan kenyamanan pengembangan tanpa perlu membangun dan memelihara otomasi pengelolaan deployment sendiri

Ledakan environment staging dan efisiensi resource server

• Dengan Disco, perluasan environment staging menjadi sangat mudah
• Dalam satu server, mereka menjalankan environment berikut secara bersamaan
  • Branch utama
  • Branch feature-freeze
  • Environment throwaway sementara untuk PR
  • Environment jangka panjang untuk pengembangan fitur besar, dan lain-lain
• Total ada 6 environment staging independen yang berjalan tanpa kendala
• Jika tetap di Heroku, ini akan membutuhkan $3.000 per bulan, tetapi di Hetzner hanya menghabiskan CPU 2% dan memori 14GB (dari 32GB) dalam struktur berbiaya rendah

Trade-off dan pertimbangan realistis

• Ini bukan pengganti yang sepenuhnya sempurna; ada beberapa beban operasional tambahan
• Pekerjaan infrastruktur seperti pengaturan DNS dan CDN untuk tiap environment baru belum diotomatisasi
• Muncul tanggung jawab operasional seperti monitoring server, pembaruan keamanan, dan respons saat terjadi gangguan
• Karena region AS Hetzner terbatas, ini bisa jadi kurang cocok untuk layanan produksi yang menargetkan pengguna di Amerika Serikat
• Ada trade-off ketersediaan berupa kesiapan menerima instal ulang jika server mengalami gangguan
• Penyesuaian aplikasi terhadap networking Docker memerlukan sekitar satu hari kerja engineer

Insight dan perubahan yang didapat

• Setelah dioperasikan lebih dari 6 bulan, infrastruktur ini menjadi struktur permanen
• Perubahan terbesar bukan hanya penghematan biaya, tetapi juga perubahan cara pandang bahwa environment staging adalah resource yang melimpah dan bebas digunakan
• Pengembang kini bisa membuat environment per pull request kapan pun dibutuhkan, tanpa perlu khawatir soal persetujuan atau biaya
• Tim pun menyadari bahwa bukan hanya beban biaya, tetapi keengganan untuk memakainya sendiri adalah kerugian yang sebenarnya
  • "Beban finansial selama ini membatasi kecepatan pengembangan dan eksperimen"

[GN⁺]

Komentar Hacker News

• Dari screenshot htop, yang langsung terlihat adalah tidak adanya swap, jadi saya menyarankan mengaktifkan earlyoom untuk mencegah seluruh server tumbang saat layanan tiba-tiba melahap memori secara tidak normal; OOM killer bawaan kernel Linux biasanya bertindak terlalu lambat. Ada juga cara mengaktifkan zram untuk mengompresi RAM dan melakukan overprovisioning seperti pro. Perangkat lunak yang berjalan lama sering menimbulkan kebocoran memori, dan kompresi cukup efisien untuk kasus seperti ini. Saya sudah merangkum cara menerapkannya pada server bare metal Hetzner dengan Ansible di gist, dan ini juga bekerja sama di VM

  • Saya sama sekali tidak setuju; begitu swap terpakai, kebanyakan aplikasi akan mulai mengalami masalah serius. Ini fakta yang sudah sangat dikenal, dan instance AWS EC2 juga menonaktifkan swap secara default. Tentu AWS juga ingin menjual lebih banyak RAM, tetapi swap memang tidak cocok dengan ekspektasi masa kini. Di era 90-an orang masih mau menunggu 2–3 detik per klik, sekarang kalau tidak responsif orang mengira sistem mati dan langsung reboot

  • Alternatif lainnya adalah menambah memori dan menyesuaikan oom_score per aplikasi, memberi bobot kill lebih tinggi pada aplikasi yang tidak penting dan bobot negatif pada yang penting. Misalnya, OpenSSH sudah disetel dengan oom_score_adj sebesar -1000. Praktis menonaktifkan overcommit pada server staging/production juga sangat berguna. Nilai min_free dan reserve bisa dihitung dengan rumus resmi sesuai kapasitas RAM. Saya melihat ini efektif di lapangan selama lebih dari 10 tahun mengoperasikan 50.000 server fisik tanpa swap. OOM hanya terjadi ketika kebutuhan memori salah dihitung saat proses deploy kode, atau saat praktik terbaik Java tidak diikuti, tetapi itu cerita panjang. Ada juga cara memberi batas memori per aplikasi dengan cgroup, tapi saya lewati penjelasannya. Jika ini server murni in-memory yang tidak perlu menulis ke disk, saya juga menyarankan mengatur agar OOM sama sekali tidak terjadi dan membiarkannya self-healing otomatis. Memberi waktu untuk menangkap pesan crash lewat DRAC/iLO dan menyetel reboot saat panic (kernel.panic, vm.panic_on_oom, dsb.) juga berguna. Sebagai catatan, pada sistem diskless berbasis NFS ini juga bisa dipakai dengan sengaja sebagai pemicu restart seluruh farm saat pemulihan gangguan

  • Terima kasih atas informasinya, saya sekarang mengendalikan ambang RAM lewat limit sistem (systemd), tetapi penasaran apakah earlyoom adalah pilihan yang lebih baik untuk mencegah seluruh instance menjadi tidak responsif akibat proses yang berperilaku aneh

  • Menyediakan swap dalam jumlah sangat kecil sebagai cadangan, misalnya sekitar 1GB, menurut saya adalah ide yang bagus

  • Sejak 2010 saya sudah tidak memakai swap

• Kemarin saya melihat Nate Berkopec menulis hal serupa soal performa rails, katanya Heroku 25–50 kali lebih mahal jika dilihat dari performa. Sungguh terasa seperti mereka sama sekali tidak punya niat untuk bersaing harga, dan seandainya mereka hanya melisensikan seluruh stack dengan harga masuk akal seperti Sidekiq, bahkan jika hardwarenya terpisah, itu tetap akan jauh lebih baik. Dyno 1GB RAM seharga $50 pada 2025 itu nyaris seperti perampokan, apalagi aplikasi rails standar tidak mengalami lonjakan kebutuhan resource dibanding dulu, malah lebih efisien, tetapi harganya justru makin mahal dan kualitasnya menurun. Lucu juga bahwa begitu banyak developer menjalankan aplikasi di heroku dengan biaya ratusan dolar per bulan sambil memakai mesin yang lebih lambat daripada MacBook untuk pengembangan. Pada akhirnya ini tidak jauh berbeda dari arah dunia saat ini: alih-alih memberikan produk bagus dengan harga wajar ke khalayak luas, mereka fokus pada pelanggan papan atas yang paling kaya dan terus menaikkan harga

  • Ini bukan cuma soal kenaikan harga. Menurut saya Heroku dan vendor cloud diuntungkan oleh efek psychological price anchor. Saat mulai memakai sebuah layanan, pengguna menetapkan patokan harga tertentu, lalu setelah itu ekspektasi mereka hanya berubah secara linear. Padahal performa hardware komputasi nyata meningkat secara eksponensial, sementara persepsi pengguna hanya linear. Harga Heroku tidak banyak berubah setidaknya selama 7 tahun, tetapi hardwarenya berkembang pesat. Jadi alasan orang merasa ini seperti penipuan adalah karena mereka sebenarnya membandingkan titik acuan tahun 2025 dengan harga dari pertengahan 2010-an. Vendor cloud besar menambahkan hambatan seperti membuka kunci performa hardware baru atau memperbarui SKU. Heroku tidak punya tekanan pesaing seperti itu, jadi mereka membiarkan harga tetap, dan tulisan seperti ini muncul setiap kali engineer baru mulai menyadari seberapa jauh performa hardware telah berubah

  • Anda bilang dyno 1GB RAM seharga $50 itu perampokan, tapi AWS juga tidak jauh beda. Dengan $50/bulan Anda mendapat m7a.medium, yaitu 1vCPU dan 4GB RAM. RAM-nya memang lebih besar, tapi jadi kelihatan kenapa AWS bisa terus mengumpulkan uang

  • Saya setuju dengan pendapat bahwa seandainya ada model lisensi seluruh stack perangkat lunak dengan harga murah seperti Sidekiq, itu akan bagus, dan karena itu kami membuat canine.sh sebagai open source. Kami merasa tidak ada alasan bagi penyedia PaaS untuk menambahkan margin berlebihan di atas cloud yang sendiri sudah penuh margin

  • Ini mirip seperti bilang ganti oli di bengkel lokal atau steak di restoran itu mahal karena kalau dimasak sendiri pasti lebih murah

• Cloud membuat orang lupa betapa banyak hal yang sebenarnya bisa dijalankan di satu server. Bahkan untuk lingkungan staging saja, saya memang sulit memahami mengapa itu harus dijalankan di cloud mahal, meski saya paham kebutuhan itu karena cloud modern sekarang punya banyak komponen yang saling terkait dan rumit

  • Mengajarkan dasar-dasar cloud kepada banyak developer dan punya beberapa ahli cloud itu cukup cost-effective untuk jangka waktu tertentu. Jika lingkungan staging/prod dibuat mirip, kesalahan juga bisa ditemukan lebih cepat. Nantinya tagihan cloud akan melampaui biaya tenaga kerja, dan pada titik itu keluar dari cloud benar-benar menguntungkan. Pada akhirnya akan datang saatnya berpindah ke server sendiri menjadi lebih murah daripada gabungan biaya tim dan hardware

  • Rasanya cloud membuat developer jadi takut pada server Linux itu sendiri. Menurut saya sebagian besar margin itu adalah biaya dari kecemasan developer. Padahal self-hosting sebenarnya mudah dan menyenangkan. Saya tidak pernah tertarik dengan Heroku, Vercel, dan sejenisnya, dan saya percaya tidak ada pengalaman yang lebih baik daripada langsung menyalakan server sendiri sejak awal. Saya merekomendasikan semua developer untuk mencobanya sendiri

  • Sangat membantu jika bisa menyalin penuh lingkungan prod agar mirip dengan operasional nyata. Proses deploy jadi serupa, menghemat waktu, dan memungkinkan pengujian yang lebih dekat ke prod yang sesungguhnya

  • Menarik juga kalau ada situs belajar infrastruktur berbasis ide ini: Anda diberi resource X di cloud dan harus mengaturnya agar bisa menangani beban tertentu, lalu skor performa bisa diperlombakan dengan orang lain

  • Sekitar tahun 2006, mesin AWS terkecil itu setara desktop developer yang lumayan, sampai-sampai Anda harus menyewanya lebih dari 2 tahun agar nilainya sebanding. Sekarang mesin AWS setara ponsel atau laptop murahan, dan kalau disewa 3–6 bulan saja sudah lebih untung beli hardwarenya sendiri. Kecuali Anda mendapat diskon 75%, on-premise lebih hemat baik dari sisi biaya maupun tenaga kerja dibanding cloud

• Halo, saya sedang mengembangkan PaaS open source bernama Disco bersama teman saya Antoine Leclair. Belakangan ini banyak diskusi soal self-hosting dan keluar dari cloud, jadi kalau ada pertanyaan saya dengan senang hati akan menjawab

  • Saat Anda menyebut "penggunaan resource server sangat rendah", itu malah lebih mengesankan kalau diingat bahwa load average di htop dihitung per inti CPU. Misalnya, jika ada 8 core maka load average 0,1 berarti hanya sekitar 1,25% dari total kapasitas CPU. Saya menikmati membaca blognya; saya juga banyak belajar dari pola seperti ini

  • Saya penasaran apa yang membuat Disco secara khusus menawarkan sesuatu yang berbeda dibanding alat seperti Coolify. Saya meng-host sebagian besar layanan saya di Hetzner VPS, jadi kalau ada keunggulan khas Disco saya ingin mengetahuinya

• Kami punya pengalaman serupa di Hack Club. Organisasi nirlaba kami fokus membantu siswa SMA belajar coding dan elektronika. Dulu kami memakai Heroku, tetapi bukan cuma soal biaya; kami juga mulai bertanya apakah aplikasi utilitas kecil ini benar-benar layak menelan $15 per bulan. Tahun ini kami mulai self-hosting dengan Coolify dan menjalankan 300 layanan di satu server Hetzner seharga $300 per bulan. Hasilnya, kami bisa men-deploy jauh lebih banyak kode. Pelajaran terbesar kami adalah bahwa jika Anda hanya butuh uptime 99%, bukan 99,99%, maka dunia pilihan Anda jadi jauh lebih luas. Sebagian besar alat developer terobsesi pada 99,99%, tetapi jika 99% sudah cukup maka semuanya bisa dijalankan dengan sangat efisien. Saya jadi tertarik dengan Disco dan pasti ingin mencobanya

  • Terima kasih, kalau ada pertanyaan soal layanan Disco, silakan tanya kapan saja lewat Discord. Ada dua contoh serupa: sebuah bootcamp/sekolah developer di Puerto Rico men-deploy semua proyek akhir siswanya ke satu VPS, dan di Recurse Center ada satu Raspberry Pi yang meng-host 75 proyek web (tautan)

  • Dan kalau benar-benar butuh 99,99%, menurut saya justru lebih baik menghindari hyperscaler, contohnya outage AWS selama beberapa jam baru-baru ini

  • 300 layanan? Saya penasaran masing-masing layanan itu dipakai untuk apa

• Dari situasinya, self-hosting memang tampak seperti solusi yang sangat menarik, tetapi saya ingin menyinggung soal tulisannya sendiri. Tulisan ini terasa sangat banyak diedit oleh AI, dan khususnya bagian "Bridging the Gap: Why Not Just Docker Compose?" menyalin-tempel 1:1 bagian "Powerful simplicity" dari landing page produk Disco. Postingan blog ini juga merupakan satu-satunya studi kasus yang ditampilkan di halaman utama mereka

  • Itu sepenuhnya benar, saya ingin memberi tiga alasan (bercanda), tetapi library kami open source dan kami bangga bahwa Idealist bisa menghemat biaya. Kalau kebanggaan itu termasuk promosi, maka saya memang bangga

  • Anda bilang tulisan pemasaran itu masalah, tapi saya penasaran kenapa Anda menganggapnya masalah. Apakah itu sesuatu yang dilarang oleh pedoman Hacker News, atau menurut Anda semua pemasaran harus diberi label? Hampir tidak ada tulisan di dunia ini yang benar-benar bukan pemasaran

  • Menulis posting blog pemasaran tentang persaingan harga tapi di situs perusahaan sendiri tidak mencantumkan harga dan hanya menerima booking meeting adalah salah satu red flag terbesar soal harga menurut saya

  • Saya juga langsung penasaran dengan model pendapatannya dan mencoba mencarinya, tetapi kesan saya cuma bahwa itu akan diumumkan segera

  • Ini bukan pertama kalinya ada tulisan yang disertai unsur pemasaran, dan saya penasaran apa sebenarnya masalah dari pemasaran lewat artikel berbasis studi kasus. Ini contoh yang relatif ringan, dan walaupun bersifat marketing saya tetap merasa tulisan ini menarik dan berguna

• Harga Heroku benar-benar gila. Sekitar 10 tahun lalu, di startup tempat saya bekerja, saya terkejut melihat mereka menghabiskan lebih dari $10.000 per bulan hanya untuk menjalankan layanan yang membuat kode QR dalam tabel HTML lalu menampilkannya di email. Biayanya sekitar $0,15 per item. Lead developer kami bahkan belum pernah melakukan profiling kode, dan akhirnya berhasil menurunkannya jadi $0,01 per item, tapi tetap saja absurd

  • Saya tidak mengerti kenapa membuat satu kode QR bisa memakan biaya sebanyak itu padahal bukan sesuatu yang rumit; bahkan dengan edge cloud hosting saja itu bisa dilakukan gratis

• Saya tidak terlalu paham kenapa harus ada 6 server staging (masing-masing $500). Kalau itu karena timnya besar, bukankah biaya server $3.000 itu kecil dibanding biaya tenaga kerja tahunan di atas $100 ribu? Saya melihat idealist.org, kelihatannya cuma papan lowongan kerja dan terasa berlebihan

  • Enam server staging itu dipakai untuk main, dev, dan beberapa branch agar QA non-developer bisa langsung memeriksanya. Setiap deploy staging cepat membengkakkan biaya karena memakai dyno Performance-M, beberapa dyno Standard, RabbitMQ, database, dan lain-lain. Layanan Idealist melayani 100.000 pengguna harian, jadi di balik keandalan dan kecepatannya memang ada banyak pekerjaan teknis

  • Dari yang saya baca, sepertinya mereka membuat server staging sebagai lingkungan dev agar tiap developer bisa menjalankan beberapa layanan sekaligus, jadi wajar jumlahnya banyak

  • Dalam menghitung biaya nyata, orang sering mengabaikan biaya tenaga kerja (man-day)

• Saya ingin mengganti Heroku tetapi hanya ingin membuang situs Django dan databasenya lalu selesai, tanpa harus mengelola sistem sendiri. Menurut Anda opsi terbaik untuk itu apa?

  • Render.com mungkin yang paling mirip dan saya sangat puas memakainya. Workflow-nya sama seperti Heroku, lebih murah, dan saya puas dengan restart malam serta dukungan versi Python terbaru

  • Saya juga menyarankan belajar Docker Swarm. Deploy cukup dengan push kontainer lalu satu perintah. Saya juga membuat rove.dev, alat CLI gratis untuk deploy sekaligus diff layanan. Atau Anda bisa mempertimbangkan PaaS berbasis VM juga, seperti Semaphore, Dokku, Dokploy, dan lain-lain

  • Pilih saja VPS yang Anda suka sesuai harga/performa/lokasi/dukungan, lalu pasangkan alat deploy seperti Coolify atau Dokploy. Baru-baru ini saya memindahkan Django/Postgres dari Google App Engine dengan mudah menggunakan Coolify dan Mythic Beasts. Bahkan dengan skill yang sudah lama berkarat pun migrasinya benar-benar mudah

  • Menurut saya cukup jalankan satu server di hetzner lalu atur nginx dan layanan systemctl

  • PythonAnywhere(tautan) juga lumayan

• Proyek yang keren. Dari dokumentasinya, GitHub integration tampaknya seperti syarat wajib untuk Disco; apakah benar? Dan apakah saya juga bisa langsung men-deploy image Docker yang sudah ada di registry saya tanpa proses build terpisah, mirip --skip-push --version latest di Kamal?

  • Benar, untuk saat ini integrasi GitHub memang diperlukan. Namun Disco juga bisa langsung menarik dan men-deploy image Docker yang sudah ada (kami meng-self-host RabbitMQ seperti ini). Sebagai contoh, lihat cara men-deploy image Meilisearch di sini dan tutorial ini. Ngomong-ngomong, apakah alur deploy Anda biasanya memang membangun image lalu mendorongnya ke registry? Saya penasaran mendengar proses deploy Anda lebih detail