Cara Cek Tanggal Mati Node, Python, dan PostgreSQL Pakai API endoflife.date

Masalah klasik upgrade bukan cuma mencari waktu, tapi mengingat kapan tenggatnya. Node 24 mulai tidak disupport kapan? Python 3.13 masih dapat security fix sampai kapan? Pertanyaan itu punya jawaban yang tersedia secara machine-readable, dan tidak perlu dihafal. Situs endoflife.date menyediakan seluruh datanya sebagai JSON, satu endpoint per produk. Tabel di artikel ini ditarik sendiri pada 21 September 2026 lewat endpoint tersebut, jadi semua angkanya bisa diulang dengan command yang sama.

Dipakai dulu, baru dibaca detailnya

Endpoint-nya mengikuti pola sederhana:

curl -s https://endoflife.date/api/nodejs.json | jq ".[0:4]"

Hasilnya adalah array satu objek per rilis mayor, dengan field seperti cycle, latest, eol, support, dan lts. Untuk Ubuntu, ganti nama produknya:

curl -s https://endoflife.date/api/ubuntu.json | jq -r ".[] | [.cycle, .latest, .eol, .lts] | @tsv"

Field cycle bukan versi penuh, melainkan nomor rilis mayor, sedangkan latest berisi versi patch terbaru yang tercatat saat itu. Jadi kalau produksi jalan di Node 24.13.2 dan latest menunjukkan 24.21.0, itu sinyal bahwa ada belasan rilis patch yang belum dipakai, bukan sinyal langsung bahwa versi lo rentan.

Tabel yang ditarik hari ini

Angka di bawah ini hasil query 21 September 2026, kolom terakhir adalah tanggal end-of-life menurut sumber yang sama.

Field false dan null itu bukan tanpa arti

Ini bagian yang paling sering bikin salah baca. Pada JSON, eol bisa bernilai tanggal ISO, false, atau string. Nilai false berarti sumber belum punya tanggal end-of-life untuk siklus itu, bukan berarti produk tidak akan pernah usang. Di data yang sama, siklus nginx 1.31 dan 1.30 bernilai false, sementara 1.29 bertanggal 2026-05-13. Untuk Redis, yang tersedia justru field support: siklus 8.8 tercatat selesai masa support pada 2026-07-29 dan 8.6 pada 2026-05-25, sedangkan 8.10 masih berstatus didukung.

Bedanya penting saat dipakai di script. Kalau pipeline lo membandingkan tanggal dengan naive parsing, false bisa berubah menjadi error, yang lebih buruk lagi bisa dianggap "tidak ada tenggat" lalu hilang dari laporan. Aturan amannya: perlakukan tanggal sebagai satu-satunya sinyal yang bisa dipakai otomatisasi tanpa penilaian manusia, dan perlakukan selain tanggal sebagai "perlu dicek ke sumber vendor".

Jebakan kedua: support dan eol bukan hal yang sama

Node.js 24 adalah contoh paling jelas. Di data yang ditarik hari ini, Node 24 berstatus LTS dengan tanggal mulai LTS 2025-10-28, masa support berakhir 2026-10-20, dan eol baru jatuh 2028-04-30. Artinya ada rentang hampir dua tahun di mana rilis itu masih dapat security fix, tapi tidak lagi dapat update fitur atau dukungan reguler. Banyak tim salah membaca ini sebagai "masih aman sampai 2028", padahal kalender upgrade yang sehat berpijak pada tanggal support, bukan tanggal eol.

Untuk yang suka angka konkret dari data hari ini: Node 26 mulai jadi LTS pada 2026-10-28, jadi rencana upgrade ke generasi baru idealnya disusun sebelum akhir Oktober. Node 25 tercatat sudah lewat tanggal EOL pada 2026-06-01, sehingga kalau masih ada image yang memakai siklus itu, itu temuan, bukan rencana masa depan.

Script 20 baris untuk inventaris

Inti automasinya cuma perlu tiga kemampuan: ambil JSON, cocokkan dengan versi terpasang, cetak selisih tanggal. Contoh minimal yang bisa ditempel ke cron:

for p in nodejs python postgresql ubuntu openssl go; do
  curl -s "https://endoflife.date/api/$p.json" -o "/tmp/eol-$p.json"
done

jq -r ".[] | [.cycle, .latest, (.eol | tostring)] | @tsv" /tmp/eol-nodejs.json

Langkah lanjutan yang biasa dipakai di proyek nyata: simpan versi runtime di satu file (misalnya hasil node --version, python3 --version, psql --version dari host produksi), lalu bandingkan major-nya dengan daftar siklus. Kalau tidak ada yang cocok dengan siklus yang masih bertanggal masa depan, output-nya satu baris peringatan. Tidak perlu dashboard untuk tahu bahwa sebuah sistem berjalan di rilis yang sudah lewat tenggat.

Versi mana yang layak dipasang untuk proyek baru

Untuk instalasi baru, pertanyaannya bukan "versi terbaru apa", tapi "berapa lama proyek ini harus hidup". Aturan praktisnya bisa diturunkan langsung dari JSON yang sama. Pada Node.js, siklus bernomor genap yang punya tanggal LTS adalah kandidat default, dan hari ini ada dua: 24 dengan support sampai 2026-10-20 dan 26 yang baru mulai LTS pada 2026-10-28. Untuk proyek yang baru mulai September 2026 dan ditargetkan jalan tiga tahun, memilih 24 berarti menjadwalkan upgrade sebelum akhir Oktober, sementara menunggu beberapa minggu lagi membuat 26 jadi pilihan yang lebih panjang umurnya.

Python punya kekhasan yang terlihat di data yang sama: tidak ada siklus yang bertanda LTS. Semua cycle bernilai lts: false, dan yang membedakan cuma kombinasi support serta eol. Karena itu strategi versioning Python biasanya mengikuti jadwal rilis bahasa, bukan label komersial, dan pilihan aman untuk proyek panjang adalah siklus dengan tanggal support paling jauh yang sudah benar-benar stabil di ekosistem dependency lo.

Ubuntu memberi contoh lain: 26.04 LTS dengan EOL 2031-05-29, jauh di depan 25.10 yang tercatat sudah lewat pada 2026-07-01. Untuk server yang jarang direinstal, selisih lima tahun itu nyata, dan memasang rilis non-LTS hanya beralasan kalau ada kebutuhan perangkat keras atau kernel tertentu.

Gabungkan kalender EOL dengan radar keamanan

Tanggal EOL tidak menyebut ada celah yang dieksploitasi. Sebaliknya, daftar Known Exploited Vulnerabilities menyebut eksploitasi tanpa memberi tanggal usang. Keduanya baru berguna kalau disilangkan:

• Versi masih didukung, tidak ada CVE relevan: masuk antrean upgrade biasa.
• Versi masih didukung, ada CVE relevan: patch ke versi perbaikan yang sudah ada, tidak perlu tunggu upgrade mayor.
• Versi sudah lewat masa support, ada CVE relevan: prioritas tertinggi, dan kalau patch tidak tersedia, mitigasi jaringan jadi pekerjaan utama, bukan sekadar catatan.
• Versi sudah lewat tanggal EOL tanpa CVE: tetap tenggat, karena yang belum ditemukan bukan berarti tidak ada.

Radar keamanannya bisa dibaca di laporan mingguan yang sudah tayang di blog ini, dan data EOL-nya cukup satu file JSON per produk yang diperbarui mingguan. Tidak perlu sistem besar untuk sampai ke keputusan yang benar.

Pertanyaan yang biasanya muncul

Kenapa data di sini bisa berbeda dari artikel lain? Karena tanggal pengambilan. Angka di halaman ini ditarik 21 September 2026, dan field latest bergerak hampir setiap minggu. Sebelum membandingkan, cek tanggal sumbernya.

Boleh dipakai untuk laporan ke klien? Boleh sebagai lampiran, dengan catatan sumbernya adalah basis data komunitas yang menghimpun keterangan vendor. Untuk pernyataan resmi, kutip halaman vendor lalu sebut tanggalnya.

Ada API untuk semua produk? Tidak. Yang tidak tersedia harus diambil dari situs vendor, dan biasanya cuma butuh satu baris manual per kuartal.

Kalau server lo tidak pernah bisa di-reboot? Maka yang dicari justru rilis dengan dukungan terpanjang dan mekanisme live patching dari distro. Itu keputusan arsitektur, dan keputusan arsitektur lebih murah dibuat saat masih nol host.

Kapan harus tetap buka halaman vendor

endoflife.date menghimpun tanggal dari keterangan vendor, dan seperti semua basis data yang dirawat komunitas, ia bisa tertinggal beberapa hari dari pengumuman resmi. Karena itu pembagiannya jelas:

• Untuk radar internal dan perencanaan, API ini lebih dari cukup, sekaligus lebih mudah dipakai daripada membaca belasan halaman.
• Untuk klaim ke klien, audit, atau kontrak, sebut halaman vendor sebagai sumber akhir, lalu lampirkan tanggal pengecekannya.
• Untuk produk yang tidak ada di daftarnya, tidak ada jalan pintas: buka kebijakan support vendor tersebut dan tulis tanggalnya sendiri.

Satu kebiasaan yang bikin perbedaan itu tidak menyakitkan: catat tanggal pengambilan data di samping angkanya. Laporan tanpa tanggal pengambilan tidak bisa dibedakan dari tebakan yang kebetulan benar.

Rencana upgrade yang tidak dimulai dari ketakutan

Dengan kalender EOL di tangan, urutan kerja jadi membosankan dengan cara yang bagus. Pertama, pilih satu runtime per kuartal untuk dinaikkan, bukan semuanya sekaligus. Kedua, naikkan versi patch lebih dulu, karena risikonya paling kecil dan sering menyelesaikan separuh temuan keamanan. Ketiga, untuk lompatan mayor, siapkan catatan kompatibilitas: dependency mana yang menahan, fitur mana yang dihapus, dan bagaimana cara memutar balik kalau gagal.

Untuk PostgreSQL, lompatan mayor membawa konsekuensi khusus karena format storage-nya. Sebelum naik dari 15 ke 18, baca bagian upgrade di dokumentasi resmi dan tentukan apakah pakai pg_upgrade atau restore dari dump; keduanya punya konsekuensi waktu henti yang beda jauh. Data EOL hanya memberitahu tenggat, keputusan tekniknya tetap milik dokumentasi vendor.

Tiga angka yang paling sering bikin salah ambil keputusan

Pertama, tanggal support yang sudah dekat sementara tanggal EOL masih jauh. Node 24 masuk kategori ini hari ini: support berakhir 2026-10-20, EOL baru 2028-04-30, jadi tim yang berpatokan pada angka kedua akan merasa aman dua tahun lebih lama dari seharusnya. Kedua, siklus yang sudah lewat EOL tapi masih dipakai di image dasar lama, seperti Ubuntu 25.10 dengan 2026-07-01 dan Go 1.25 dengan 2026-08-19. Ketiga, mengira field latest adalah versi yang harus dipakai. Versi terbaru memang sebaiknya jadi target untuk upgrade patch, tapi untuk lompatan mayor yang menentukan adalah dukungan ekosistem dependency, bukan tanggal di kolom terakhir tabel ini.

Sumber

• Dokumentasi API endoflife.date, sumber seluruh tabel di atas, ditarik 21 September 2026.
• Halaman Node.js, Python, PostgreSQL, OpenSSL, Go, MySQL, Redis untuk tampilan per produk.
• Repositori endoflife.date kalau ingin melihat proses perawatan datanya.
• Kebijakan versi PostgreSQL sebagai rujukan vendor untuk keputusan final.

Yang bisa dilakukan lima belas menit ke depan cuma satu: jalankan command pertama untuk tiap runtime di daftar inventaris, lalu tulis hasilnya di satu file. Tanggal-tanggal itu sudah ada di internet sejak lama. Yang belum ada cuma catatan lo sendiri.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.