Spesifikasi VPS untuk Laravel tidak bisa ditentukan hanya dari jumlah user atau ukuran database. Dua aplikasi dengan jumlah pengguna yang sama dapat membutuhkan resource sangat berbeda jika pola request, query, queue, report, file processing, dan integrasinya berbeda. Cara yang lebih aman adalah mengukur workload, menentukan starting CPU, RAM, dan storage yang masuk akal, lalu memvalidasi hasilnya setelah aplikasi berjalan.
Transparansi AI. Artikel ini disusun dengan bantuan AI untuk riset dan drafting, kemudian ditinjau dan disunting oleh tim Sequel Cloud untuk memastikan akurasi teknis dan relevansi isi.
Intisari Artikel
- Jumlah user membantu memberi konteks, tetapi bukan rumus untuk menentukan CPU atau RAM.
- CPU, RAM, PHP-FPM, database, queue, dan storage perlu dibaca bersama karena masing-masing dapat menjadi bottleneck yang berbeda.
- Starting specification adalah hipotesis awal berdasarkan workload, bukan keputusan yang dianggap benar selamanya.
- Setelah deployment, ukur hasilnya. Upgrade resource dilakukan ketika evidence menunjukkan capacity memang menjadi masalah.
Jangan Mulai dari Paket Server
Pertanyaan seperti “Laravel butuh VPS berapa GB RAM?” terdengar sederhana. Masalahnya, Laravel sendiri bukan workload.
Laravel adalah framework. Beban server datang dari aplikasi yang dibangun di atasnya.
Aplikasi inventory internal dengan 20 pengguna mungkin hanya melakukan request CRUD singkat. Aplikasi lain dengan jumlah pengguna yang sama bisa menjalankan PDF generation, import Excel, queue worker, API pihak ketiga, pencarian data besar, dan laporan dengan query yang lebih berat.
Jumlah user sama. Resource yang dibutuhkan bisa jauh berbeda.
Saat aplikasi sibuk, pekerjaan apa yang sebenarnya dilakukan server dan resource mana yang mulai tertekan?
Server dengan spesifikasi besar tidak otomatis menyelesaikan masalah. Jika bottleneck ada pada query, application logic, external API, atau konfigurasi yang salah, menambah CPU dan RAM dapat menghasilkan server yang lebih mahal tanpa improvement yang sebanding.
Sebaliknya, optimasi kode juga memiliki batas. Jika aplikasi memang kekurangan memory, worker terus mengantre, atau storage menjadi bottleneck, infrastructure perlu ikut dinaikkan.
Right-sizing berada di tengah: cari bottleneck dulu, lalu tambahkan resource yang memang dibutuhkan.
Jika masih belum yakin apakah keterbatasan berasal dari shared hosting atau application layer, selesaikan diagnosis terlebih dahulu melalui Shared Hosting vs VPS NVMe untuk Laravel.
Lima Hal yang Perlu Diukur Sebelum Menentukan Spesifikasi
1. CPU: apakah server kekurangan tenaga komputasi?
CPU menangani banyak pekerjaan selama request Laravel diproses. Demand bisa naik ketika aplikasi generate laporan, mengolah file, menjalankan banyak request PHP secara bersamaan, atau memproses background job.
CPU yang melonjak tinggi selama beberapa detik belum tentu masalah. Yang lebih penting adalah melihat apakah penggunaan tinggi berlangsung terus saat response time ikut memburuk dan pekerjaan mulai mengantre.
2. RAM: bukan hanya untuk Laravel
RAM VPS dipakai bersama oleh operating system, web server, PHP-FPM, database, Redis/cache, queue worker, control panel, dan proses lain yang berjalan di server.
| Komponen | Apa yang menggunakan memory |
|---|---|
| Operating system | Kernel, service system, filesystem cache. |
| Web server | Nginx/Apache dan connection handling. |
| PHP-FPM | Worker yang mengeksekusi request Laravel. |
| Database | Buffer/cache, connection, dan query processing. |
| Redis / cache | Data yang memang sengaja disimpan di memory. |
| Queue worker | Worker untuk pekerjaan background. |
| Panel / service lain | Resource tambahan yang ikut menetap di server. |
| Headroom | Ruang agar spike tidak langsung menyentuh batas resource. |
Pembagian RAM bukan formula tetap; yang penting adalah budget memory seluruh service saat workload sibuk.
MySQL menggunakan InnoDB buffer pool untuk menyimpan data dan index yang sering diakses di memory. Besarnya alokasi perlu mempertimbangkan service lain yang juga memakai RAM pada server yang sama.
Sumber: MySQL 8.4 Reference Manual — InnoDB Buffer Pool.
3. PHP-FPM: berapa banyak request yang perlu dilayani bersamaan?
PHP-FPM menjalankan sejumlah worker. Parameter pm.max_children menentukan batas jumlah child processes yang dapat dibuat dan secara praktis membatasi berapa request yang bisa diproses bersamaan oleh pool tersebut.
Semakin banyak worker yang perlu aktif bersamaan, semakin besar memory budget yang perlu disiapkan. Tetapi jangan menggunakan asumsi seperti “satu worker Laravel selalu 50 MB”. Memory worker harus diukur pada aplikasi aktual.
PHP-FPM memory budget ≈ observed memory per worker × concurrent workers yang memang dibutuhkan.
Sumber: PHP Manual — FPM Configuration.
4. Database: ukuran file bukan rumus RAM
Database berukuran 20 GB tidak berarti server wajib mempunyai RAM 20 GB. Sebaliknya, database yang kecil juga tidak otomatis ringan.
Yang lebih relevan adalah working set, pola query, connection, dan seberapa efektif data yang sering diakses dapat dilayani dari memory.
| Yang dilihat | Pertanyaan yang dijawab |
|---|---|
| Database size | Berapa storage yang dibutuhkan sekarang dan bagaimana pertumbuhannya? |
| Working set | Data/index apa yang aktif disentuh workload? |
| Slow queries | Apakah latency berasal dari query yang mahal? |
| Connections | Apakah banyak connection aktif bersamaan? |
| Buffer behaviour | Apakah workload sering harus kembali membaca dari storage? |
| Temporary work | Apakah report, sort, atau join menghasilkan pekerjaan sementara yang berat? |
5. Storage: jangan samakan IOPS, latency, dan throughput
IOPS menunjukkan jumlah operasi input/output per detik. Latency menunjukkan waktu yang dibutuhkan satu operasi I/O untuk selesai. Throughput menunjukkan volume data yang dapat dipindahkan dalam periode tertentu.
Storage cepat membantu ketika storage memang menjadi bottleneck. Tetapi storage 25.000 IOPS tidak menghilangkan row-lock contention, query buruk, atau application bottleneck.
MySQL memiliki parameter innodb_io_capacity untuk menyesuaikan background I/O berdasarkan kemampuan storage yang digunakan.
Sumber: MySQL 8.4 Reference Manual — Configuring InnoDB I/O Capacity.
Dari Measurement ke Starting Size
Setelah metric dasar tersedia, sizing mulai mempunyai konteks. Daripada memakai jumlah user sebagai formula paket, gunakan pola workload untuk menentukan resource mana yang perlu dievaluasi lebih dulu.
| Workload Pattern | Apa yang Biasanya Terlihat | Resource yang Perlu Dievaluasi | Starting Direction |
|---|---|---|---|
| Laravel ringan / internal CRUD | Request singkat, queue minimal, DB relatif ringan. | Baseline RAM + CPU. | Small VM. |
| Transactional application | Banyak request bersamaan, database aktif, cache/queue digunakan. | CPU + RAM + database + storage latency. | Medium VM. |
| Reporting / background-heavy | Worker lama, export/import, PDF, processing. | CPU + worker memory. | More CPU/RAM atau pisahkan worker. |
| Database-sensitive workload | Query aktif, data/index besar, frequent I/O. | RAM + DB tuning + storage. | More memory / faster storage sesuai diagnosis. |
| Sustained high workload | Beberapa resource terus mendekati limit. | CPU + RAM + I/O + architecture. | Larger VM atau evaluasi dedicated compute. |
Tabel ini bukan jawaban paket final. Fungsinya adalah mempersempit apa yang harus diukur dan resource mana yang paling mungkin perlu dinaikkan.
Contoh Sizing: Fokus pada Cara Berpikir, Bukan Angka Sakti
Misalnya sebuah aplikasi ERP Laravel sedang dipindahkan dari environment lama ke VPS. Berikut contoh ilustratif untuk menunjukkan proses berpikirnya—bukan benchmark universal.
| Observasi | Implikasi |
|---|---|
| Request web normal relatif ringan. | CPU request biasa bukan masalah utama. |
| Beberapa laporan menggunakan CPU lebih tinggi. | Perlu ruang CPU untuk peak/reporting. |
| PHP-FPM menjalankan beberapa worker bersamaan. | RAM harus menghitung worker concurrency. |
| MySQL dan Laravel berada di server yang sama. | RAM perlu menyisakan budget database. |
| Redis dan queue worker aktif. | Ada resident memory tambahan. |
| Database transaction cukup aktif. | Storage latency dan DB behaviour perlu dipantau. |
| Usage meningkat pada jam operasional. | Perlu headroom, bukan sizing berdasarkan average saja. |
Dari observasi tersebut, PIC IT bisa memutuskan memulai dari 2 vCPU dan 4 GiB RAM sebagai planning assumption. Angka ini bukan berasal dari rumus “30 user = 4 GiB”, tetapi dari resource budget workload yang ingin diuji.
Jika memakai qVM, konfigurasi yang saat ini sesuai dengan contoh tersebut adalah qVM-4: 2 vCPU, 4 GiB RAM, dan 80 GiB NVMe. Harga saat ini Rp230.000/bulan.
Setelah VPS Live, Jangan Berhenti Mengukur
Sizing tidak selesai saat invoice dibayar. Loop yang lebih sehat adalah:
Sizing yang sehat adalah loop: deploy bukan akhir, tetapi awal validation.
Jika response time membaik dan CPU, memory, PHP-FPM, database, serta storage masih mempunyai ruang yang sehat, tidak ada alasan menaikkan resource hanya karena paket lebih besar tersedia.
Sebaliknya, jika workload memperlihatkan sustained saturation atau queue yang sebelumnya belum terlihat, hasil tersebut menjadi evidence untuk scaling berikutnya.
Kapan Tambah CPU, RAM, atau Storage?
| Kondisi yang Terlihat | Jangan Langsung Menyimpulkan | Evaluasi |
|---|---|---|
| CPU tinggi saat peak. | “Tambah RAM.” | CPU saturation, request profile, worker/job. |
| RAM hampir habis. | “Tambah RAM pasti selesai.” | Process memory, swap, worker count, DB/cache. |
| PHP-FPM queue penuh. | “CPU kurang.” | Worker memory, request duration, pm.max_children. |
| Query lambat. | “Disk kurang cepat.” | Query plan, index, locking, buffer behaviour, I/O. |
| Disk latency tinggi. | “Tambah CPU.” | Storage workload, IOPS, throughput, filesystem. |
| Storage hampir penuh. | “Tambah RAM.” | Capacity growth dan storage sizing. |
Dengan cara ini, upgrade menjadi keputusan yang punya alasan teknis, bukan trial-and-error dengan invoice.
Kapan qVM Masih Masuk Akal, Kapan qMetal Mulai Dievaluasi?
Pertanyaan pertama bukan qVM atau qMetal. Pertanyaan pertama tetap: berapa resource yang dibutuhkan workload ini dan bagaimana pola penggunaannya?
qVM masih masuk akal ketika
- Virtual compute masih sesuai untuk workload.
- Kebutuhan resource masih efisien dijalankan sebagai VM.
- Fleksibilitas scaling CPU, RAM, dan storage masih relevan.
- Root access dan self-service provisioning dibutuhkan.
qMetal mulai layak dievaluasi ketika
- Kebutuhan resource VM sudah besar.
- Workload konsisten berat dalam waktu panjang.
- Dedicated physical resource menjadi penting.
- Economics large VM mulai kurang efisien dibanding dedicated compute.
Tidak ada rule “100 user masih VPS, 101 user harus bare metal” atau “database 100 GB otomatis harus qMetal”. Yang menentukan tetap workload, resource requirement, dan operational context.
qVM: Mulai dari Resource yang Masuk Akal, Bukan Paket Terbesar
Setelah hasil sizing menunjukkan bahwa VPS memang merupakan infrastructure fit, qVM memberi jalur yang cukup sederhana untuk memulai dari resource yang dibutuhkan sekarang tanpa harus langsung mengambil dedicated server.
qVM menggunakan NVMe storage, menyediakan full root access, built-in monitoring, API-driven provisioning, serta dukungan scaling CPU, RAM, dan storage. Storage-performance claim saat ini hingga 25.000 IOPS.
Untuk Laravel, nilai utamanya bukan sekadar “NVMe lebih cepat”. Nilai yang lebih relevan adalah fleksibilitas untuk menjalankan proses:
Jika hasil sizing mengarah ke 2 vCPU dan 4 GiB RAM, misalnya, qVM-4 menyediakan konfigurasi tersebut dengan 80 GiB NVMe pada harga saat ini Rp230.000/bulan. Jika kebutuhan ternyata lebih rendah atau lebih tinggi, tersedia flavor lain tanpa harus memaksakan satu paket untuk semua workload.
qVM — VPS NVMe untuk workload yang sudah siap naik kelas
Mulai dari resource yang sesuai kebutuhan sekarang, lalu scale berdasarkan measurement. Pilihan yang lebih masuk akal daripada langsung membeli server terbesar untuk mengantisipasi semua kemungkinan.
Setelah Sizing Selesai, Setup Laravel Tidak Harus Dimulai dari Server Kosong
Resource yang tepat baru menyelesaikan satu bagian pekerjaan. Setelah qVM dipilih, tim masih perlu menyiapkan environment aplikasi.
Di Marketplace Sequel, aaPanel dapat dipilih saat provisioning qVM sehingga panel terpasang otomatis. Ini berguna jika tim ingin mengelola Laravel melalui control panel tanpa melakukan instalasi panel dari nol.
aaPanel cukup umum digunakan pada deployment Laravel karena membantu pekerjaan seperti pengelolaan web server, PHP version, database, SSL, dan service lain melalui interface yang lebih mudah diakses. Namun panel tetap bukan bagian dari sizing formula—resource server tetap harus mengikuti workload aplikasi.
Jika resource VPS sudah ditentukan, panel mana yang lebih sesuai untuk workflow tim? Lihat pembahasan aaPanel vs CloudPanel untuk Laravel.
Cara Menjelaskan Sizing ke Owner Tanpa Membawa Dashboard Monitoring ke Meeting
PIC IT biasanya tidak kesulitan menjelaskan CPU atau RAM ke sesama technical team. Yang lebih sulit adalah menjawab: “Kenapa perlu budget sebesar ini?”
Jawabannya tidak perlu berupa presentasi panjang. Terjemahkan hasil teknis menjadi kondisi operasional dan alasan keputusan.
Template yang Bisa Diteruskan
KONDISI
Aplikasi [nama aplikasi] mengalami [symptom yang benar-benar ditemukan] pada [jam/kondisi].
DAMPAK
Kondisi tersebut menyebabkan [pekerjaan antre / response lebih lambat / proses user tertunda / dampak aktual].
YANG SUDAH DICEK
Tim sudah memeriksa [CPU / memory / PHP workers / database / storage / query / metric relevan].
TEMUAN
Saat kondisi tersebut muncul, [metric yang terukur] menunjukkan [hasil].
REKOMENDASI
Starting resource yang disarankan: [CPU] / [RAM] / [storage], karena [hubungkan dengan hasil pengukuran].
BUDGET
Estimasi biaya: Rp[angka]/bulan.
VALIDATION
Setelah implementasi, hasil akan dievaluasi dari [metric] selama [periode/kondisi peak]. Jika improvement tidak sesuai expectation, diagnosis dibuka kembali sebelum menaikkan resource berikutnya.Contoh Terisi
KONDISI
ERP internal melambat saat jam transaksi paling ramai.
DAMPAK
Beberapa user menunggu lebih lama saat menyimpan transaksi dan membuka laporan.
YANG SUDAH DICEK
Monitoring dilakukan pada CPU, available memory, PHP-FPM worker, dan database saat jam sibuk.
TEMUAN
Workload masih cocok dijalankan pada virtual compute, tetapi memory budget perlu menampung PHP-FPM, MySQL, queue, dan Redis secara bersamaan. Diperlukan headroom agar server tidak langsung berada dekat batas ketika workload naik.
REKOMENDASI
Mulai dari 2 vCPU dan 4 GiB RAM, kemudian pantau utilisasi dan response time setelah aplikasi berjalan.
BUDGET
Jika menggunakan qVM-4, biaya saat ini Rp230.000/bulan.
VALIDATION
Setelah migration, cek response time, CPU, memory pressure, PHP-FPM queue, dan database behaviour pada jam sibuk. Upgrade berikutnya hanya dilakukan jika measurement menunjukkan resource tertentu memang menjadi limit.Yang dibawa ke owner adalah evidence → recommendation → budget → validation, bukan angka kerugian yang dibuat tanpa data bisnis.
Glosarium Singkat
| Istilah Teknis | Bahasa Awam | Makna dalam Artikel |
|---|---|---|
| Right-sizing | Memilih ukuran yang pas | Menentukan resource berdasarkan workload, bukan membeli sebesar mungkin. |
| vCPU | Kapasitas CPU virtual | Resource compute yang tersedia pada VM. |
| PHP-FPM worker | Proses yang melayani PHP | Worker memproses request dan ikut memakai RAM. |
| Concurrency | Pekerjaan bersamaan | Berapa request atau job yang perlu diproses pada waktu yang sama. |
| Working set | Data yang aktif dipakai | Bagian data/index yang sering disentuh workload. |
| InnoDB buffer pool | Cache utama MySQL di RAM | Menyimpan table/index pages agar akses tidak selalu kembali ke storage. |
| IOPS | Operasi I/O per detik | Salah satu ukuran kemampuan storage menangani operasi baca/tulis. |
| Storage latency | Waktu tunggu storage | Berapa lama satu operasi storage membutuhkan waktu. |
| Swap | Storage yang membantu memory | Dapat muncul saat memory pressure tinggi dan jauh lebih lambat daripada akses RAM. |
| Headroom | Ruang kapasitas cadangan | Resource yang belum terpakai agar spike tidak langsung menyentuh limit. |
| Vertical scaling | Menambah resource server | Menaikkan CPU, RAM, atau storage pada server yang sama. |
| Bare metal | Dedicated physical server | Compute fisik dedicated untuk kebutuhan yang memang memerlukan resource besar atau dedicated. |
FAQ Spesifikasi VPS Laravel
Berapa RAM minimum yang dibutuhkan Laravel?
Laravel mempunyai runtime/server requirements, tetapi tidak menetapkan satu angka RAM universal untuk semua aplikasi. Kebutuhan RAM bergantung pada application workload, PHP workers, database, queue, cache, dan service lain yang berjalan pada server.
Apakah jumlah user cukup untuk menentukan spesifikasi VPS?
Tidak. Jumlah user adalah context, bukan sizing formula. Yang lebih penting adalah apa yang dilakukan user, berapa banyak request yang berjalan bersamaan, berapa lama request diproses, dan workload database/background job yang ikut berjalan.
Database 20 GB berarti RAM juga harus 20 GB?
Tidak. Ukuran database membantu capacity planning, tetapi kebutuhan RAM lebih terkait dengan working set, query behaviour, connection, buffer/cache, dan service lain yang menggunakan memory.
Kapan perlu menambah CPU dan kapan menambah RAM?
Tambah CPU layak dievaluasi ketika evidence menunjukkan sustained compute saturation. Tambah RAM lebih relevan ketika memory pressure, swap, worker capacity, atau kebutuhan database/cache memang menjadi limit. Jika root cause berada pada query atau application logic, keduanya belum tentu menyelesaikan masalah.
Kapan qMetal perlu dipertimbangkan?
qMetal mulai relevan ketika resource VPS sudah besar, workload terus-menerus berat, dedicated physical resource diperlukan, atau economics virtual compute mulai kurang efisien. Tidak ada threshold universal berdasarkan jumlah user atau ukuran database.
Jadi, Berapa Spesifikasi VPS yang Ideal untuk Laravel?
Tidak ada jawaban universal seperti “10 user = 2 GiB” atau “100 user = 16 GiB”. Jawaban yang lebih berguna adalah: mulai dari workload yang dapat diukur.
Lihat CPU, memory, PHP-FPM worker, database, queue, dan storage. Tentukan starting resource berdasarkan kondisi tersebut. Setelah deployment, validasi hasilnya pada jam kerja yang benar-benar mewakili workload.
Kalau hasil measurement menunjukkan VPS masih menjadi infrastructure fit, pilih resource yang cukup untuk kebutuhan sekarang dengan headroom yang masuk akal. Kalau workload berubah, ukur lagi.
Right-sizing bukan memilih server sekali lalu selesai. Right-sizing adalah proses menjaga resource tetap sesuai dengan kondisi aplikasi yang nyata.
Daftar Pustaka
- Laravel. (n.d.). Deployment. Laravel Documentation. Retrieved September 7, 2026, from https://laravel.com/docs/13.x/deployment
- PHP Documentation Group. (n.d.). Configuration. PHP Manual: FastCGI Process Manager (FPM). Retrieved September 7, 2026, from https://www.php.net/manual/en/install.fpm.configuration.php
- Oracle. (n.d.). InnoDB buffer pool. MySQL 8.4 Reference Manual. Retrieved September 7, 2026, from https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool.html
- Oracle. (n.d.). Configuring InnoDB I/O capacity. MySQL 8.4 Reference Manual. Retrieved September 7, 2026, from https://dev.mysql.com/doc/refman/8.4/en/innodb-configuring-io-capacity.html