Spesifikasi VPS untuk menjalankan Python yang aman di produksi kecil: 2 vCPU, 2–4 GB RAM, SSD 40–80 GB, Ubuntu LTS, Nginx + Gunicorn, dan panel seperti aaPanel. Shared hosting hanya cocok bila ada Python selector, SSH terbatas, dan worker yang jelas.
Banyak proyek Flask atau Django gagal di hosting murah. Proses worker mati. Versi Python terkunci. Database ikut sesak di RAM yang sama.
Highlight
Ini Spesifikasi VPS & Web hosting Untuk menjalankan python
- Aplikasi Python butuh proses worker sendiri; paket shared tanpa Python Manager sering menghentikan proses di tengah request.
- aaPanel punya modul Python Project; Anda bisa set versi interpreter, virtualenv, dan reverse proxy ke Nginx.
- PostgreSQL atau MariaDB butuh RAM terpisah dari worker Gunicorn; jangan bagi 1 GB untuk semua layanan.
- Ubuntu 22.04/24.04 LTS plus Nginx lebih stabil untuk deploy FastAPI, Django, dan Flask di VPS Indonesia.
- Redis membantu antrian Celery dan cache sesi; spek 4 GB ke atas baru nyaman bila Redis ikut hidup.
Spesifikasi VPS Minimum untuk Menjalankan Aplikasi Python
Tim lapangan memakai angka di bawah ini untuk proyek Python ringan sampai menengah. Bukan spek “semua kasus”.
| Skala proyek | vCPU | RAM | Storage | Catatan runtime |
|---|---|---|---|---|
| Sandbox / staging | 1 | 1–2 GB | 20–40 GB SSD | 1 worker Gunicorn; tanpa Redis |
| Produksi kecil (API / compro dinamis) | 2 | 2–4 GB | 40–80 GB SSD | 2–4 worker; MariaDB atau PostgreSQL |
| Produksi menengah + antrian | 4 | 4–8 GB | 80–160 GB SSD | Worker + Redis + backup harian |
| Traffic padat / ML ringan | 6–8 | 8–16 GB | 160 GB+ NVMe | Pisahkan DB ke instance lain bila mungkin |
Bandwidth 1–3 TB/bulan cukup untuk API internal UMKM. Swap 1–2 GB boleh ada. Namun jangan andalkan swap sebagai RAM utama.
Pilih distro yang Anda kuasai. Ubuntu LTS dan Debian sering lebih ramah untuk paket Python. Bila masih ragu soal pilihan OS, baca dulu rekomendasi distro Linux untuk VPS sebelum beli paket.
Lokasi server dekat pengguna. Untuk audiens Jabodetabek, VPS Jakarta atau Singapore sering memberi latensi lebih rendah daripada region jauh.
IOPS disk ikut menentukan. SSD/NVMe mempercepat migrasi database dan cold start worker. HDD murah justru memperlambat deploy container dan backup.
Snapshot provider beda dengan backup aplikasi. Snapshot memulihkan seluruh disk. Backup SQL memulihkan data tanpa mengulang setup panel dari nol.
Web Hosting Biasa vs VPS untuk Python
Shared hosting murah jarang memberi kontrol penuh atas versi Python. Banyak paket hanya mengizinkan PHP dan MySQL. Provider sering memotong proses panjang seperti Celery atau WebSocket FastAPI.
VPS memberi root, firewall, dan kebebasan memasang interpreter. Trade-offnya jelas: Anda ikut merawat OS, update, dan backup. Shared lebih “klik-klik”, tapi ruang gerak sempit.
Kapan shared masih masuk akal? Bila panel menyediakan Python Selector, Passenger, atau App Manager. Aplikasi Anda pun hanya serving HTTP sederhana tanpa antrian berat.
Windows VPS jarang kami sarankan untuk Flask atau Django. Lisensi lebih mahal. Toolkit Linux (systemd, Nginx, apt) lebih matang untuk stack ini.
Bila Anda membangun situs perusahaan yang nanti butuh API Python terpisah, rencanakan infrastruktur sejak awal. Banyak pemilik usaha memesan jasa website company profile dulu, lalu baru menambah layanan Python di VPS sendiri.
Hosting domain gratis hampir selalu tidak cocok untuk app Python produksi. Batas CPU keras. Port terbatas. Log sulit dibaca.
Control Panel yang Mendukung Aplikasi Python: aaPanel dan Alternatif
Panel mempercepat setup tanpa menghapus kebutuhan spek yang benar. Spek lemah tetap lemah, meski UI-nya cantik.
aaPanel: dukungan Python Project
aaPanel (dulu BT Panel) punya App Store dan modul Python Project. Anda memilih versi Python, membuat virtual environment, lalu mengarahkan domain ke app via Nginx reverse proxy.
Alur praktis di lapangan:
- Install aaPanel di Ubuntu LTS dengan spek minimal 2 GB RAM.
- Pasang Nginx, database, dan modul Python dari App Store.
- Buat proyek, set path project, entry file, dan jumlah process.
- Uji lokal di VPS, baru pasang SSL di domain produksi.
Kelebihannya: visual jelas untuk pemula. Kekurangannya: Anda tetap membaca log error Gunicorn atau uWSGI. Panel tidak mengganti debugging.
Perbandingan panel gratis untuk pemula ada di artikel panel hosting aaPanel, HestiaCP, dan CyberPanel. Untuk Python, aaPanel paling sering kami pakai dulu sebab modulnya langsung ada.
Panel lain: Hestia, CyberPanel, cPanel, Plesk
- HestiaCP: ringan; Python lewat custom template atau proxy manual.
- CyberPanel: dekat dengan OpenLiteSpeed; cocok bila Anda sudah nyaman LSWS.
- cPanel + CloudLinux: Python Selector tersedia di banyak hosting berbayar.
- Plesk: ada toolkit Python; cocok lingkungan yang sudah terbiasa Plesk.
Menurut kami, freelancer yang sering ganti stack lebih cocok memakai aaPanel di VPS 2–4 GB. Shared cPanel mahal sering membatasi worker tanpa ruang debug.
Pasang hanya satu panel per VPS. Dua panel di mesin yang sama saling berebut port, cron, dan path web root.
Spesifikasi Server: OS, Web Server, dan Runtime Python
Stack yang kami pakai berulang di klien UMKM Tangerang Selatan sederhana. Ubuntu LTS. Python 3.10 atau 3.12. Virtualenv. Gunicorn. Nginx sebagai reverse proxy. Systemd untuk auto-start.
Nginx menangani TLS, static file, dan rate limit ringan. Gunicorn atau uWSGI menangani kode Python. Jangan expose Gunicorn langsung ke internet tanpa proxy.
Pilihan web server lain masih bisa Anda uji. Apache bisa memakai mod_wsgi. LiteSpeed punya opsi untuk app dinamis. Bandingkan perilaku request di studi kasus benchmark Apache, Nginx, dan LiteSpeed sebelum mengunci pilihan.
Daftar aplikasi web server yang sering muncul di produksi ada di ringkasan aplikasi web server yang banyak dipakai. Untuk Python modern, Nginx plus worker masih kombinasi yang paling sering kami temui.
Environment file (.env) jangan masuk git publik. Simpan secret di luar document root. Rotasi kunci database setelah staf keluar proyek.
Versi Python ikut spek. Kunci ke minor version di production. Jangan biarkan apt mengupgrade interpreter diam-diam tanpa uji regresi.
Dokumentasi resmi Python tentang penempatan di web server tetap jadi rujukan aman: docs.python.org – Web Servers HOWTO.
Caching dan static file
Static CSS/JS lebih aman dilayani Nginx atau object storage. Cache aplikasi (page cache, query cache) beda lapisan. Jangan menaruh cache halaman di dalam worker Python tanpa uji memori.
Database untuk Aplikasi Python: MySQL, PostgreSQL, dan Redis
Django sering nyaman di PostgreSQL. Flask dan FastAPI fleksibel: MariaDB/MySQL atau PostgreSQL. Redis kami pakai untuk sesi, rate limit, dan broker Celery.
| Komponen | RAM cadangan | Disk | Catatan |
|---|---|---|---|
| MariaDB / MySQL kecil | 512 MB–1 GB | 10–30 GB | Cocok compro + API ringan |
| PostgreSQL kecil | 1–2 GB | 20–40 GB | Lebih nyaman untuk relasi kompleks |
| Redis | 256–512 MB | kecil (RAM-bound) | Persistensi AOF opsional |
Satu VPS 2 GB yang menjalankan Nginx + Gunicorn + PostgreSQL + Redis akan terasa sesak. Worker Python sering kena OOM kill dulu.
Dasar konsep penyimpanan data ada di artikel tentang database. Setelah hidup di produksi, rawat ukuran dan backup lewat prosedur di cara backup dan maintain database yang aman.
Bila tabel membengkak, perbaiki indeks dan arsip dulu. Naikkan spek VPS belakangan, bukan sebagai reaksi pertama saat query lambat.
Connection pool di ORM (SQLAlchemy, Django DB) menahan koneksi. Spek CPU kecil plus pool terlalu besar justru membuat antrian di database, bukan di worker.
Studi kasus: deploy FastAPI UMKM di Tangerang Selatan
Partner kami di Tangerang Selatan membangun API stok untuk toko interior. Awalnya mereka pakai shared hosting PHP-only. Endpoint Python tidak pernah hidup stabil.
Lalu kami pindahkan ke VPS 2 vCPU / 4 GB / 80 GB SSD di Jakarta. Panel: aaPanel. Runtime: Python 3.12, FastAPI, Uvicorn worker di belakang Nginx.
Database MariaDB mendapat cadangan 1 GB RAM. Redis 256 MB untuk cache daftar produk. Backup otomatis tiap malam ke storage terpisah.
Hasilnya: latency p95 turun dari timeout menjadi sekitar 180–250 ms di jam sibuk. Biaya VPS lebih tinggi dari shared. Namun downtime hampir hilang.
Batasan jujur: tim toko belum punya DevOps full-time. Jadi update OS dan patch keamanan tetap kami dampingi di awal. Spek bagus tanpa perawatan tetap berisiko.
Checklist Spek Sebelum Deploy Proyek Python ke Produksi
Sebelum go-live, cek daftar ini. Bila satu poin kosong, tunda rilis publik.
- RAM cukup untuk OS + web server + worker + database (+ Redis bila ada).
- Python version terkunci; virtualenv terpisah per proyek.
- Process manager (systemd / supervisor) menghidupkan ulang worker saat crash.
- Nginx (atau setara) memutus TLS dan membatasi body size upload.
- Firewall hanya membuka 80/443; SSH kunci publik, bukan password lemah.
- Backup database teruji restore, bukan file dump yang hanya menumpuk tanpa uji.
- Log aplikasi terpisah dari log access Nginx agar debug cepat.
- Monitoring disk: full disk membunuh write database lebih cepat daripada CPU penuh.
Keamanan berlapis bukan opsional setelah app terbuka ke publik. Susun lapisan dasar lewat panduan keamanan website berlapis.
Setelah live, perawatan VPS lebih luas dari “restart Apache” saja. Ruang lingkup kerja itu mirip panduan di jobdesc maintenance VPS dan dedicated server.
Di proyek website dan API klien, tim HardaWebPro sering memisahkan spek staging dan produksi. Staging boleh 1–2 GB. Produksi jangan ikut hemat bila database dan worker sudah saling berebut RAM.
Bila Anda masih merancang situs bisnis dan API Python menyusul, lihat pendekatan kerja di situs HardaWebPro. Proses build situs dan eksperimen server kami pisahkan agar brief tidak bercampur.
Spek di brochure provider sering mengabaikan overhead panel dan database. Ukur ulang setelah app menerima traffic nyata selama seminggu.
Naikkan vCPU setelah RAM cukup. Banyak app Python kehabisan memori dulu, baru CPU. Monitor free -h, load average, dan restart worker sebelum membeli paket lebih mahal.
