Panduan Membangun Lingkungan Self-Hosting Terbaik

 (codecaptured.com)
26 poin oleh GN⁺ 2025-07-20 | 2 komentar | Bagikan ke WhatsApp
  • Setelah bertahun-tahun mencoba berbagai pendekatan self-hosting, penulis membagikan pengalaman berhasil membangun lingkungan kustom yang sesuai kebutuhan
  • Tujuan utamanya adalah kontrol atas data pribadi dan menjaga infrastruktur yang andal, dengan menggabungkan sejumlah teknologi inti seperti NixOS, ZFS, Tailscale, dan Authelia
  • Dengan mempertimbangkan kemudahan penggunaan untuk keluarga dan orang terdekat, aksesibilitas juga ditingkatkan melalui SSO dan halaman awal terpisah
  • Masalah yang ditemui saat operasional nyata beserta solusi konkretnya dijelaskan secara rinci, misalnya proxy publik untuk layanan privat, lingkungan VPN campuran, dan integrasi autentikasi
  • Ke depannya, penulis berencana menambahkan peningkatan lain seperti infrastruktur backup dan penguatan keamanan, serta menyertakan pengalaman dan referensi yang berguna

Perkenalan dan motivasi

  • Setelah mencoba berbagai cara self-hosting selama beberapa tahun, penulis akhirnya membangun lingkungan yang “cukup bagus” untuk kebutuhannya sendiri
  • Penulis merujuk pada banyak sumber open source dan pengalaman orang lain, lalu membagikan proses ini agar dapat membantu developer lain

Tujuan

  • Dengan mengendalikan langsung data pribadi dan layanan terkait, penulis ingin meningkatkan privasi serta meminimalkan risiko perubahan atau penghentian layanan yang diandalkan
  • Penulis juga berfokus menyediakan kontrol ini kepada keluarga dan orang terdekat, agar tercipta lingkungan layanan yang dapat dipercaya

Persyaratan

  • Kebutuhan utama

    • Membatasi sebisa mungkin paparan layanan ke internet publik untuk mengurangi risiko insiden keamanan
    • Meminimalkan downtime infrastruktur inti akibat kesalahan (menghindari dependensi melingkar dan memastikan rollback konfigurasi mudah dilakukan)
    • Memiliki langsung komponen inti seperti autentikasi, jaringan, dan domain, dengan mengutamakan open source
    • Memperhatikan kemudahan penggunaan dari sudut pandang keluarga dan orang terdekat (login SSO yang konsisten, kebutuhan maintenance minimal)
    • Secara aktif mengadopsi konfigurasi deklaratif berbasis file (mudah untuk version control, backup/pemulihan, serta memanfaatkan konfigurasi milik orang lain)
    • Update harus mudah dan aman agar bisa dikelola secara berkala

  • Kebutuhan non-prioritas

    • Tidak perlu modularitas atau kerapian yang ekstrem (praktikalitas lebih utama)
    • Tidak semua harus open source, tetapi digunakan jika memungkinkan
    • Tidak mengejar high availability (HA); menerima downtime sesekali demi struktur yang lebih sederhana

Pemilihan teknologi

  • NixOS

    • Sebuah distribusi Linux yang mengelola seluruh konfigurasi OS secara deklaratif dengan bahasa Nix dan package manager-nya
    • Karena konfigurasi dinyatakan sebagai kode, version control dan rollback yang sistematis menjadi memungkinkan
    • Mendukung berbagai paket serta integrasi dengan Docker/PODMAN dan lain-lain
    • Penulis juga menambah wawasan dengan merujuk pada konfigurasi Nix milik developer lain

  • ZFS

    • Filesystem berperforma tinggi dengan kemampuan perlindungan data yang kuat seperti snapshot dan rollback
    • Terdiri dari 4 HDD 10TB dalam konfigurasi RAIDZ2 (tahan terhadap kegagalan dua disk sekaligus), dengan SSD 256GB untuk caching
    • Dataset file dan media dipisahkan, lalu dikelola melalui mount NFS sesuai kegunaan
    • Membentuk arsitektur penyimpanan utama yang sederhana namun andal

  • Tailscale & headscale

    • Tailscale: Mesh VPN yang mudah diakses, memungkinkan akses ke jaringan internal tanpa mengekspos ke internet publik hanya dengan memasang klien
    • Headscale: backend Tailscale open source yang bisa di-self-host, untuk menghilangkan risiko perubahan kebijakan perusahaan
    • Efektif untuk meningkatkan keamanan jaringan, meski mengharuskan pemasangan klien di perangkat pengguna
    • Dari sisi usability, kebutuhan memasang klien di tiap perangkat bisa menjadi hambatan awal

  • Authelia & LLDAP

    • Authelia: solusi SSO, autentikasi, dan otorisasi berbasis OpenID Connect yang dapat diintegrasikan dengan proxy nginx
    • LLDAP: LDAP ringan, digunakan untuk manajemen pengguna dan grup di Authelia serta autentikasi cadangan
    • Dapat berjalan baik dengan resource minimal, tetapi konfigurasi cukup rumit dan ada kurva belajar untuk memahami integrasi tiap layanan

Desain struktur

  • Arsitektur

    • Setiap server diberi nama berdasarkan planet di Star Wars
    • Titik masuk (public server) adalah "taris", yang menyediakan layanan penting seperti Authelia, headscale, dan blog
    • headscale, Authelia, dan LLDAP harus dapat diakses dari luar, sehingga dijalankan secara publik dalam lingkup terbatas
    • Layanan privat (Foundry VTT, monitoring, dll.) diproksikan melalui NGINX agar dapat diekspos secara selektif

  • Server privat

    • Di server utama "kuat", penulis menggunakan TrueNAS untuk mengelola VM NixOS dan pool penyimpanan ZFS
    • Cakupan snapshot/backup dipisahkan menjadi "files" (data yang tidak bisa dipulihkan) dan "media" (data yang bisa dipulihkan jika diinginkan)
    • Layanan utama dijalankan di VM "bespin" dengan NixOS, dan ada juga VM terpisah untuk pengujian bernama "alderaan"

  • Layanan lainnya

    • Perangkat mission-critical dibuat sebagai appliance dengan satu tujuan khusus (misalnya smart home memakai Home Assistant OS terpisah)
    • Server Matrix dan klien Element menggunakan Ansible Playbook resmi
    • Email dan pengelolaan kata sandi di-outsourcing ke layanan eksternal ProtonMail dan Bitwarden untuk mencegah dependensi melingkar

Isu individual dan penyelesaiannya

  • Halaman awal layanan

    • Dashboard sederhana berbasis Flame untuk meningkatkan aksesibilitas layanan bagi tiap pengguna
    • Karena ringan dipakai dan punya kualitas visual yang baik, solusi ini praktis digunakan sampai ada layanan pengganti

  • Menggunakan Tailscale bersama VPN lain

    • Beberapa OS (terutama Android dan Windows) tidak bisa menjalankan banyak VPN sekaligus
    • Dengan menggabungkan fitur exit node Tailscale dan Gluetun (klien VPN berbasis container), trafik bisa dialihkan melalui VPN eksternal seperti ProtonVPN
    • Namun, ada efek samping seperti konsumsi baterai meningkat dan penurunan kecepatan sesekali

  • Hal-hal yang perlu diperhatikan pada autentikasi

    • Protokol autentikasi utama untuk tiap layanan self-hosted: OIDC (prioritas utama), OAuth, LDAP
    • Tiap layanan dan Authelia memerlukan konfigurasi terpisah
    • Akun admin wajib tetap dipertahankan terpisah dari integrasi Authelia/LLDAP agar ada jalur pemulihan saat autentikasi bermasalah
    • Untuk layanan yang tidak mendukung OIDC, kontrol akses dapat dibuat melalui integrasi proxy NGINX dan Authelia
    • OIDC Authelia dan kontrol akses NGINX Proxy perlu dikonfigurasi secara terpisah

  • Penerbitan DNS dan SSL

    • Layanan publik dijalankan dengan metode umum (domain → IP publik)
    • Layanan internal menggunakan subdomain "internal" dan IP Tailscale untuk mencegah eksposur ke luar
    • Sertifikat SSL memanfaatkan dukungan Lets Encrypt bawaan NixOS (HTTP-01 untuk layanan publik, DNS-01 untuk layanan internal)

  • Hal yang perlu diperhatikan saat instalasi NixOS di VPS

    • Banyak VPS tidak menyediakan opsi instalasi NixOS
    • Jika perlu memasang NixOS, pengguna perlu merujuk ke wiki komunitas dan memastikan jalur instalasi yang didukung

  • Mount VM untuk dataset TrueNAS

    • Firewall bawaan TrueNAS secara default memblokir akses host dari VM
    • Dengan mengikuti panduan resmi (membuat jaringan bridge), mount dataset NFS dapat diimplementasikan

  • Proxy publik untuk layanan pribadi

    • Saat menggunakan headscale, layanan privat bisa diekspos ke luar melalui NGINX proxyPass
    • Selain Tailscale Funnel resmi, penulis juga menyediakan contoh konfigurasi dan referensi susunan sistem

Langkah berikutnya dan tantangan

  • Perlu menambahkan server backup khusus dan sistem verifikasi pemulihan
  • Berencana memanfaatkan kontrol akses Tailscale/headscale secara lebih aktif
  • Akan melanjutkan penguatan keamanan tambahan seperti akses SSH
  • Sedang mempertimbangkan adopsi solusi DNS lokal terenkripsi dan caching seperti Pi-hole dan AdGuard Home
  • Juga mempertimbangkan ekspansi layanan baru seperti Forgejo, Manyfold, dan RomM

Referensi

Bacaan terkait

2 komentar

 
opminsu 2025-07-25

Keren sekali!
 
GN⁺ 2025-07-20
Komentar Hacker News

  • Jika ingin keluarga atau teman bisa menggunakannya dengan mudah, tujuannya adalah memberi satu akun login per orang agar mereka bisa mengakses berbagai layanan berbasis SSO (single sign-on). Bagian ini memang sangat sulit, tapi sekaligus juga keren. Open source dan Linux memang paradoksal: benar-benar dipakai di mana-mana dan menangani semua protokol, tetapi untuk lingkungan klien yang nyata—yakni menyatukan orang-orang dan membangun sendiri elemen groupware—justru jadi lebih rumit. Proses mengintegrasikan banyak sistem secara organik, sampai membangun infrastruktur direktori, memang mengejutkan. Dulu aku tak pernah menyangka suatu hari akan mengoperasikan sendiri FreeIPA atau layanan direktori yang kompatibel dengan Windows, tetapi belakangan rasanya dunia berbasis OpenID memang mulai benar-benar mapan.

    • Terima kasih atas empatinya. Login yang sederhana dan aksesibilitas memang merupakan kebutuhan paling sulit dalam proyek ini, dan menurutku itu titik yang menentukan apakah orang benar-benar akan memakainya atau tidak. Open source memang ada di mana-mana, tetapi masalah mulai muncul saat pengguna umum mencoba benar-benar memakainya sendiri. Menurutku paradoks ini muncul karena tiap proyek ingin berinovasi sendiri-sendiri. Tidak adanya pihak yang menarik semuanya ke satu arah adalah kelebihan sekaligus kekurangan. Meski begitu, kalau melihat lingkungan self-hosting dalam 5 tahun terakhir, rasanya instalasi dan penggunaannya memang jauh lebih mudah.

    • Aku sangat setuju dengan paradoks itu. Kemarin juga aku menulis di platform validasiku tentang betapa sulitnya FOSS diakses oleh orang nonteknis. Aku jadi berpikir apakah solusi yang tepat mungkin berupa platform seperti system integrator yang menghubungkan pengguna teknis dan pengguna nonteknis.

    • Sebenarnya tidak terlalu sulit. Kalau kamu tidak terpaku pada layanan tertentu dan menjadikan dukungan SSO sebagai kriteria utama pemilihan, setup-nya justru bisa cukup mudah. Aku sendiri awalnya hampir tidak punya pengalaman, tetapi dengan caddy dan authentik aku bisa cepat menyelesaikan sistem self-host. Alternatifnya, yunohost adalah distro yang sangat mudah dan bahkan mengatur SSO secara otomatis.

    • Aku menggunakan authentik untuk autentikasi SSO Google, Discord, dan GitHub. Semuanya bekerja cukup baik untuk semua orang.

  • Aku paham bahwa menemukan sistem yang benar-benar "pas" untuk diri sendiri bisa memakan waktu. Karena tujuan, preferensi, dan lingkungan tiap orang berbeda, aku ingin merangkum proses setup finalku dalam sebuah posting blog untuk dibagikan. Isinya mencakup tujuan dan kebutuhan, teknologi yang dipakai, desain, serta proses pemecahan masalah. Caraku mungkin tidak cocok untuk semua orang, tetapi semoga tetap bisa jadi referensi bagi orang lain. Aku juga berkembang berkat banyak konten dan perangkat lunak gratis, jadi aku ingin terus membagikan bantuan.

    • Aku penasaran bagaimana pengalamanmu memakai Nix untuk homelab. Aku sendiri sudah lebih dari 7 tahun menjalankan setup yang cukup hardcore dengan rack 25U, kubernetes kecil, ceph, sampai Talos Linux, tetapi makin lama aku ingin menyederhanakannya, dan entah kenapa ujung-ujungnya selalu sampai ke Nix dan ZFS. Kesulitan-kesulitan terkait ini terasa sangat akrab. Kalau kamu juga penasaran soal apa pun, silakan tanya.

    • Aku penasaran apakah kamu pernah mempertimbangkan memakai coolify. Aku sudah lebih dari setahun memakainya, dan aku cukup suka karena bisa auto-deploy dari GitHub semudah Heroku https://coolify.io/

    • Aku penasaran apakah kamu juga memakai fitur enkripsi ZFS. Dulu aku menjalankan berbagai VM seperti FreeIPA di Debian+ZFS, lalu demi menyederhanakan semuanya aku beralih ke struktur yang hanya menjalankan library enkripsi Seafile di VPS dan memakai ZFS send/receive untuk backup ke server rumah. Server itu menyala setiap malam, lalu setelah update dan sinkronisasi selesai kembali tidur. Untuk lebih aman, aku juga sedang mempertimbangkan menjalankan ZFS di desktop Linux (Fedora) dengan enkripsi penuh. Karena dataset utamanya sudah terenkripsi, sinkronisasi ke drive eksternal atau cloud juga jadi jauh lebih mudah. Mengunggah seluruh arsip fotoku ke Seafile di VPS terasa terlalu mahal, jadi aku masih mencari jalan keluarnya.

    • Ulasan setup dan penjelasan detailnya sangat bermanfaat. Aku belum bisa langsung mengadopsinya seperti kamu, tetapi aku jadi memutuskan untuk memasang flame sebagai dashboard dan bereksperimen bersama keluarga.

    • Senang bertemu denganmu, pekerjaanmu sangat menarik. Aku juga sedang mengerjakan proyek serupa berbasis NixOS. Tujuanku adalah membuat kotak kecil yang hampir nol konfigurasi dengan nuansa Apple, sehingga siapa pun cukup mencolokkannya ke modem lalu lewat wizard instalasi web dan selesai. Masih tahap awal, tetapi sudah berjalan di rumah. Perangkat ini sekaligus berperan sebagai hybrid router (OPNSense/PFSense) dan app server (Nextcloud, Synology, Yunohost, dll.). Semua konfigurasinya juga dikelola dalam satu halaman modul Nix: dynamic DNS, sertifikat Let's Encrypt, alokasi subdomain otomatis per aplikasi, pemblokiran iklan, dan headscale bawaan. Sekarang aku juga sedang membuat SSO, dan ingin mengambil beberapa ide dari tulisanmu. Detailnya ada di https://homefree.host

  • Kadang saat melihat jaringan rumahku, aku membayangkan kerusakan yang akan kutinggalkan untuk keluarga kalau aku meninggal, atau betapa sulitnya orang luar memahami setup-ku. "Main homelab" sebenarnya mengisi sesuatu yang mirip dengan hobi lelaki generasi lama yang membuat rel kereta mini bawah tanah. Ini bukan sindiran buruk; rasanya memang ada naluri pada sebagian orang untuk memiliki dunia miniatur yang bisa mereka kendalikan sepenuhnya.

    • Aku juga memikirkan hal yang sama, jadi aku menulis dokumentasi untuk berjaga-jaga. Bagian 1 berisi uang dan lokasi dokumen penting, bagian 2 adalah panduan tentang cara membuat rumah kembali "lebih bodoh". Misalnya, cara menyingkirkan smart switch dan mengembalikannya ke sakelar tradisional, memindahkan layanan kunci seperti Bitwarden ke cloud, biaya menjaga domain/mail tetap aktif, cara mengembalikan router ke perangkat default dari ISP, dan sebagainya. Istriku tidak terlalu antusias dengan smart home, tetapi merasa tenang setelah tahu rumah selalu bisa dikembalikan jadi "rumah bodoh" lagi kapan saja. Sejujurnya aku juga tidak tahu seberapa tidak nyamannya kalau semua ini hilang, tetapi ada sedikit hiburan dari pikiran bahwa itu bukan lagi urusanku.

    • Aku menyimpan foto keluarga kami di home lab RAID1, dan tiap malam melakukan backup rsync ke drive eksternal pada komputer di rumah mertua. Tujuannya agar saat backup berjalan, kalau terjadi sesuatu pun keluarga tetap bisa mengaksesnya dengan mudah. Karena istriku tidak tertarik pada IT, aku hanya bilang, "colok USB, semuanya ada di situ".

    • Menurutku skenario ancaman yang tidak terlalu berguna seperti pencurian disk fisik bisa diabaikan. Menyimpan semua foto dan dokumen penting tanpa enkripsi, sambil meninggalkan penjelasan yang mudah dipahami, justru lebih praktis. Yang lebih mengkhawatirkan malah sisi home automation.

    • Memikirkan dari awal apa yang akan terjadi jika operator homelab lama tidak ada atau berhalangan itu memang penting secara praktis. Aku sendiri tidak secara khusus mendesain semuanya supaya mudah seperti itu, tetapi rasanya memang perlu dipikirkan lebih jauh. Intinya adalah meninggalkan data penting dan kredensial untuk mengaksesnya. Sebaiknya juga memanfaatkan layanan seperti Nextcloud agar data otomatis tersinkron ke perangkat keluarga, dan membuat keluarga atau teman benar-benar mencoba memakainya sendiri. Di rumah kami juga aku berusaha membuat Home Assistant cukup seperti peralatan rumah tangga esensial yang dipakai bersama pasangan. Ini lebih mudah dikelola ketika hadir sebagai benda fisik, bukan VM terpisah. Tentu saja semua ini banyak unsur harapannya juga, jadi penting untuk setidaknya menyusun rencana rinci bersama keluarga dekat.

    • Aku juga cukup banyak memikirkan bagian ini. Aku berasumsi NAS dan layanan Docker tidak akan mungkin bisa boot dengan baik tanpa diriku. Backup kata sandi offsite rasanya juga tak akan bisa dipulihkan tanpa bantuan ahli. Karena itu, aku menyimpan snapshot incremental harian ke folder baru di hard disk eksternal NTFS lewat cron. Ukurannya kurang dari 50GB sehingga murah untuk diduplikasi. Kalau aku berhalangan, tinggal colok hard disk itu lalu salin foldernya. Aku juga punya salinan seluruh library Seafile di masing-masing laptop. Domain email sudah kubayar di muka untuk 10 tahun dan di-host di iCloud; karena foto keluarga sebagai lampiran membuat kapasitas cepat penuh dan email terpental, aku sedang mempertimbangkan migadu.

  • Aku juga sangat tertarik pada bidang ini. Aku ingin memperingatkan bahwa kalau kamu benar-benar menjalankan usaha sendiri/merintis bisnis IT, dorongan untuk membangun homelab bisa jadi makin kuat. Lama-lama menjalankan container sederhana saja terasa tidak cukup, lalu kamu mulai mengurus berbagai dokumen untuk memperoleh DBA dan ASN yang sah, sampai benar-benar punya blok IP/IPV6 sendiri dan berevolusi menjadi ISP sendiri. Banyak orang menyelesaikan masalah ingress (akses dari luar) dengan tailscale, dan ini memang sangat sulit. Secara teori, struktur berbasis STUN/TURN yang hanya me-cache file statis di seluruh server, sementara akses dinamis diautentikasi di login wall lewat email magic link, menurutku tidak terlalu berbahaya atau mahal. Saat membangun lingkungan remote development, aku jadi punya alasan tambahan untuk menggali area ini lebih dalam. Referensi: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN

    • Aku membangun ingress dengan Fly.io, memakai nginx cache di sisi remote, dan menambahkan container peer Fly Wireguard di pod ingress. Cara ini memang tidak gratis, tetapi dari sisi biaya paling masuk akal karena mendukung anycast ingress tanpa perlu membuka port apa pun langsung dari rumah.

  • Belakangan aku sedang mengutak-atik Immich, dan tiap kali bingung apakah sebaiknya dipakai dari luar rumah hanya lewat tailscale atau sekalian menaikkan reverse proxy di VPS. Hal yang paling kupikirkan adalah mencari solusi monitoring/keamanan yang ramah pengguna untuk mendeteksi siapa yang mencoba menyerang dari sisi VPS.

    • Aku juga sedang memikirkan hal yang sama. Kalau kamu menemukan info tentang solusi keamanan/monitoring, tolong bagikan.

  • Setup-ku jauh lebih sederhana

    • satu mesin
    • proxy nginx
    • banyak layanan di mesin yang sama; sebagian hanya internal, sebagian terbuka ke luar, tetapi semuanya diakses via web
    • layanan internal memakai HTTP basic auth dengan kata sandi panjang (password manager bawaan Firefox)
    • layanan eksternal bersifat publik atau memakai Google OAuth
    • semuanya kutulis kode sendiri dari nol, karena memang itulah tujuan homelab
    • baik gambar maupun video dibaca browser dengan baik
    • yang sulit selalu backend, frontend-ku hampir terasa seperti HTML era 90-an

    • HTTP mengirim kata sandi dalam plaintext, jadi setidaknya lebih aman memakai sertifikat self-signed.

    • Membangun sendiri infrastruktur atau layanan dalam bentuk kode memang sangat bagus untuk belajar. Keren juga karena bisa benar-benar menyesuaikannya dengan kebutuhan sendiri.

  • Aku ingin mencoba menjalankan homelab seperti ini, tetapi tidak punya waktu. Memasang semuanya di akhir pekan mungkin bisa, tetapi aku tidak punya kelonggaran untuk merawat dan meng-update-nya secara konsisten. Jadi aku serahkan saja ke penyedia cloud dan tidak terlalu memikirkannya. Kalau ada yang seperti aku dan hanya memakai cloud, aku penasaran bagaimana pendekatan kalian.

    • Pada setup lamaku dulu, maintenance yang tidak berjalan baik memang bikin stres. Karena itu aku jadi menyukai NixOS dan ZFS; keduanya sangat mudah untuk rollback. Kalau update lalu ada masalah, tinggal pulihkan ke versi sebelumnya, dan debugging bisa dilakukan saat sempat. Dan menurutku opsi cloud juga sah-sah saja kalau kamu puas dengan pengalaman itu. Setup mandiri memang jelas memakan waktu, jadi yang penting tiap orang menimbang biaya dan nilainya.

    • Aku menjalankan sekitar 12 layanan self-hosted, dan biasanya upgrade bahkan tidak sampai 1 menit per bulan. Tiap layanan punya folder sendiri, di dalamnya ada stack docker-compose dan folder data; untuk update tinggal docker compose pull lalu up -d dan selesai. Sesekali memang ada upgrade yang butuh perubahan konfigurasi, tetapi kebanyakan selesai dalam hitungan menit. Tanpa VM, menurutku self-hosting yang sepenuhnya otomatis dengan Docker Compose adalah cara paling sederhana.

    • Ini bukan sesuatu yang selesai dalam satu hari akhir pekan saja. Dalam kasusku, semuanya dimulai dari sekadar mencoba memasang Plex, lalu setahun kemudian berubah menjadi struktur kompleks dengan Proxmox dan berbagai home automation. Setengah bercanda setengah serius, kalau mau setup minimal sebaiknya mulai dengan docker compose karena pengelolaannya mudah dan upgrade-nya juga sederhana.

  • Aku ragu apakah perlu sampai menerapkan SSO. Kalau keluarga/teman memakai klien wireguard (di iOS juga sangat sederhana), mereka bisa masuk ke jaringan rumah hanya dengan satu toggle, dan semua layanan internal langsung bisa dipakai tanpa SSO terpisah. Untuk jaringan rumah tangga kecil, menurutku kelebihannya jauh lebih besar daripada kekurangannya.

    • Layanan yang kami pakai seperti Nextcloud dan Mealie pada dasarnya memang punya akun per pengguna. Berkat SSO, semua layanan bisa diakses dengan akun yang sama, dan aku merasa tidak perlu lagi mengelola kata sandi untuk semua itu. Setup-nya memang sedikit lebih kompleks, tetapi operasionalnya justru jadi lebih mudah, sehingga kemungkinan keluarga benar-benar memakainya juga lebih tinggi.

    • Aku men-self-host 20 aplikasi, dan sudah muak harus mengelola autentikasi masing-masing secara terpisah, jadi sekarang sedang menerapkan SSO. Saat ingin membuka sebagian aplikasi itu ke keluarga, kemampuan menangani autentikasi dari satu tempat adalah prioritas utama, jadi aku sulit setuju dengan pendekatan yang disebut di atas.

  • Aku penasaran kenapa harus memakai flame. Itu artinya membawa puluhan atau ratusan dependensi pihak ketiga seperti node, react, redux, dan sebagainya ke dalam "kerajaan keamanan", padahal fungsi halaman awal sebenarnya bisa dilakukan dengan satu halaman HTML sederhana berisi daftar tautan.

    • Aku memakai flame karena sudah pernah memakainya, jadi terasa familier dan bisa langsung menyelesaikan masalah. Aku juga suka desainnya, dan karena ditempatkan di balik Tailscale dan Authelia, aku tidak terlalu khawatir soal keamanan. Nanti aku juga berencana melihat alternatif lain.

  • Aku ingin mencoba self-hosting dengan NixOS, tetapi belum sampai benar-benar melakukannya. Lingkunganku saat ini dikelola dengan beberapa VM dan satu file docker compose per VM; playbook ansible hanya menyalin file compose, lalu OS Fedora Server dipertahankan satu rilis di belakang dan di-upgrade saat masa dukungannya habis. Karena aku juga menjalankan nix-darwin di Mac, aku memahami kelebihan konfigurasi Nix, tetapi aku belum merasakan efisiensi atau hasil yang sepadan dengan waktu yang dibutuhkan untuk mem-porting lingkungan nyataku ke Nix. Mungkin lain cerita kalau LLM (AI besar) bisa mendikte file konfigurasi untukku, tetapi untuk saat ini motivasi untuk mencobanya masih kurang.

    • Aku juga sempat mencoba NixOS, lalu dalam seminggu memigrasikan seluruh jaringan rumah dan dua server produksi sekaligus. Sudah berjalan sekitar 3–4 bulan, dan sejauh ini aku jauh lebih puas daripada yang kukira. Migrasi server ternyata lebih mudah daripada memindahkan workstation. Belakangan aku juga bermain-main dengan mainan Jetson Orin Nano yang kusetup memakai NixOS. Kalau masih zaman Gentoo, ini tak akan pernah terpikirkan. Hal yang paling menyebalkan di Gentoo dulu adalah waktu kompilasi yang sangat lama di mesin lama; misalnya membangun GHC di XPS 2019 bisa memakan waktu 6 jam.

    • Buatku, perbedaan terbesar dari NixOS adalah betapa mudahnya rollback saat ada yang kacau. Pendekatan berbasis ansible atau compose memang juga memungkinkan backup/pemulihan, tetapi tetap ada beban harus menulis sistem itu sendiri. Meski begitu, kalau kamu sudah puas dengan sistem sekarang, menurutku itu juga bagus.

    • Kalau kamu sudah cukup banyak memakai IaC, aku juga tidak terlalu merasakan efisiensi tambahan yang diberikan NixOS begitu besar.