---
title: "Cara Scale Aplikasi di Helipod: CPU, Memory, dan Horizontal Scaling"
url: "https://helipod.io/blog/scaling-cpu-memory-helipod"
date: "2026-05-13"
updated: "2026-05-13"
author: "Tim Helipod"
tags: ["scaling", "cpu", "memory", "replicas", "helipod", "performance"]
excerpt: "Cara scale aplikasi di Helipod: atur CPU dan memory per pod, tambah replica untuk horizontal scaling, dan kapan scale up atau scale out."
---

# Cara Scale Aplikasi di Helipod: CPU, Memory, dan Horizontal Scaling

Aplikasimu mulai dapat traffic. Response time mulai lambat. CPU usage tinggi terus. Apa yang harus dilakukan?

Di server VPS tradisional, scaling berarti upgrade ke server yang lebih besar (dan lebih mahal), atau setup load balancer yang kompleks. Di Helipod, scaling semudah menggeser slider dan mengubah angka replica.

Artikel ini menjelaskan semua opsi scaling di Helipod dan kapan harus menggunakannya.

## Dua Jenis Scaling

### Vertical Scaling (Scale Up)
Tambah CPU dan Memory pada pod yang sudah ada. Cocok untuk aplikasi yang butuh lebih banyak resource per instance.

### Horizontal Scaling (Scale Out)
Tambah jumlah replica pod yang identik. Cocok untuk menangani traffic tinggi dengan distribusi beban.

Di Helipod, keduanya tersedia dan bisa dikombinasikan.

## Mengakses Settings Scaling

1. Klik service di canvas dashboard
2. Buka tab **Settings**
3. Scroll ke bagian **Scaling & Resources**

Kamu akan melihat:
- **Region & Replicas**: pilih region dan jumlah replica
- **Hardware Limits**: slider CPU dan Memory per replica

## Vertical Scaling: CPU dan Memory

### CPU Slider

Range: **0.25 vCPU** sampai **4 vCPU** (per plan).

| Nilai | Cocok untuk |
|-------|-------------|
| 0.25 vCPU | Side project, traffic sangat rendah |
| 0.5 vCPU | Aplikasi ringan, <50 req/menit |
| 1 vCPU | Aplikasi medium, 50-500 req/menit |
| 2 vCPU | Aplikasi traffic tinggi atau CPU-intensive |
| 4 vCPU | Heavy workload, image processing, ML inference |

**Cara baca CPU di tab Metrics:** CPU ditampilkan dalam **millicores** (m). `1000m = 1 vCPU`.

Jika CPU chart kamu sering **flatline di angka mendekati limit**: itu tanda pod butuh CPU lebih. Jika CPU selalu **di bawah 30%** dari limit, kamu mungkin over-provisioned.

### Memory Slider

Range: **256MB** sampai **8GB** (per plan).

| Nilai | Cocok untuk |
|-------|-------------|
| 256MB | Bot sederhana, webhook handler |
| 512MB | App Laravel/Django/Flask ringan |
| 1GB | App medium dengan database connection pool |
| 2GB | App dengan banyak file processing atau caching |
| 4GB | Next.js dengan banyak SSR, atau ML model kecil |
| 8GB | ML model besar, data processing, database |

**Cara baca Memory di Metrics:** Ditampilkan dalam MB dengan persentase dari limit. Contoh: `325 MB · 31.0% of 1024MB limit`.

**Tanda butuh scale up memory:**
- Memory mendekati atau menyentuh limit (>80%)
- Restarts counter naik (OOM kill)
- Memory naik terus secara linear tanpa turun (memory leak: solve di kode, bukan scale)

### Cara Mengubah CPU dan Memory

1. Buka **Settings → Scaling & Resources**
2. Geser slider CPU ke nilai yang diinginkan
3. Geser slider Memory ke nilai yang diinginkan
4. Klik **Save** atau **Apply Changes**
5. Helipod akan melakukan rolling restart untuk apply perubahan

Perubahan resource akan **ter-apply langsung** tanpa perlu redeploy kode.

### Estimasi Biaya Setelah Scale

Ingat formula harga resource Helipod:
- CPU: **Rp 300 / 0.25 vCPU / hari**
- RAM: **Rp 400 / 256MB / hari**

**Contoh kalkulasi:**

| Spec | CPU Cost/hari | RAM Cost/hari | Total/hari | ~Total/bulan |
|------|--------------|--------------|------------|-------------|
| 0.25 vCPU + 256MB | Rp 300 | Rp 400 | Rp 700 | ~Rp 21.000 |
| 0.5 vCPU + 512MB | Rp 600 | Rp 800 | Rp 1.400 | ~Rp 42.000 |
| 1 vCPU + 1GB | Rp 1.200 | Rp 1.600 | Rp 2.800 | ~Rp 84.000 |
| 2 vCPU + 2GB | Rp 2.400 | Rp 3.200 | Rp 5.600 | ~Rp 168.000 |
| 4 vCPU + 4GB | Rp 4.800 | Rp 6.400 | Rp 11.200 | ~Rp 336.000 |

## Horizontal Scaling: Replicas

Replicas adalah cara menjalankan beberapa instance pod yang identik secara bersamaan, dengan traffic didistribusikan secara otomatis antar instance.

### Cara Mengatur Replicas

Di **Settings → Scaling & Resources → Region & Replicas**, ada kontrol `+` dan `-` untuk mengatur jumlah replica.

Batas replica per plan:
| Plan | Max Replicas | Spec per Replica |
|------|-------------|-----------------|
| Free | 0 (no replicas) | - |
| Mekanik | 3 | Max 2 vCPU / 2GB |
| Pilot | 10 | Max 4 vCPU / 4GB |
| Enterprise | Custom | Custom |

### Kapan Pakai Replicas?

**Gunakan replicas jika:**
- Traffic tinggi dan satu pod tidak cukup untuk handle semua request
- Butuh **high availability**: jika satu pod mati, pod lain tetap melayani traffic
- Aplikasi kamu **stateless** (tidak menyimpan state di memory antar request)

**Jangan pakai replicas jika:**
- Aplikasi kamu **stateful** (menyimpan session di memory, tidak di database/Redis)
- Menggunakan file local yang perlu dibaca/tulis (pakai persistent volume atau object storage)
- Punya cron job atau scheduler yang tidak boleh jalan lebih dari satu instance

### Stateless vs Stateful

Ini konsep penting untuk horizontal scaling.

**Stateless** (aman untuk replicas):
- Session disimpan di database atau Redis
- Cache disimpan di Redis
- File disimpan di object storage (S3, Spaces) atau persistent volume yang shared
- Tidak ada in-memory data yang perlu dibagi antar instance

**Stateful** (butuh pertimbangan extra):
- Session disimpan di memory aplikasi
- Cache in-memory yang berbeda per instance
- File yang ditulis ke disk local container

**Cara bikin stateless:**

Laravel:
```env
SESSION_DRIVER=redis
CACHE_DRIVER=redis
QUEUE_CONNECTION=redis
```

Django:
```python
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': os.environ['REDIS_URL'],
    }
}
```

Next.js, sudah stateless by default (state di client atau database).

### Traffic Distribution

Helipod menggunakan **round-robin load balancing** antar replicas melalui Traefik. Setiap request baru dikirim ke replica berikutnya secara bergantian.

Ini berarti satu user bisa dilayani oleh replica yang berbeda di setiap request, pastikan session management sudah stateless sebelum menambah replicas.

## Strategi Scaling yang Direkomendasikan

### Langkah 1: Mulai Kecil

Mulai dengan spec minimum yang cukup, bukan spec maksimum. Lebih mudah scale up daripada scale down karena takut tidak cukup.

Konfigurasi starting point yang direkomendasikan:
- Simple Laravel/Django/Flask: 0.5 vCPU + 512MB
- Next.js / NestJS: 0.5 vCPU + 1GB
- Background worker: 0.25 vCPU + 256MB
- PostgreSQL: 0.5 vCPU + 512MB (untuk app kecil-medium)

### Langkah 2: Monitor Selama 1 Minggu

Pantau tab **Metrics** selama seminggu pertama:
- CPU average usage di atas 70%? → Scale up CPU
- Memory di atas 80% limit? → Scale up Memory
- Restarts > 0? → Cek App logs, kemungkinan OOM atau crash

### Langkah 3: Scale Berdasarkan Data

Jangan scale berdasarkan asumsi. Scale berdasarkan metrics actual:

```
CPU < 30% consistently → pertimbangkan scale DOWN (hemat biaya)
CPU 30-70% → zona nyaman
CPU > 70% consistently → scale UP atau tambah replica
Memory > 80% → scale UP memory
Restarts > 0 → investigasi root cause dulu
```

### Langkah 4: Traffic Spike, Tambah Replicas

Untuk traffic spike yang predictable (misalnya jam 9 pagi, atau saat promo):
1. Tambah replicas sebelum spike
2. Pantau metrics selama spike
3. Kurangi replicas setelah spike untuk hemat biaya

## Scaling Database

Database adalah sering bottleneck pertama sebelum aplikasinya sendiri. Untuk PostgreSQL di Helipod:

**Scale up PostgreSQL pod:**
- Tambah RAM untuk connection pool dan buffer cache
- Tambah CPU untuk query-heavy workload

**Optimasi sebelum scale:**
```sql
-- Cek query yang lambat
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

-- Cek missing indexes
SELECT relname, seq_scan, idx_scan
FROM pg_stat_user_tables
WHERE seq_scan > idx_scan
ORDER BY seq_scan DESC;
```

**Connection pooling:**
Untuk aplikasi dengan banyak replica, pertimbangkan PgBouncer sebagai connection pooler agar tidak terlalu banyak koneksi ke PostgreSQL:

```bash
# Deploy PgBouncer sebagai pod terpisah
# dan arahkan connection dari app ke PgBouncer, bukan langsung ke PostgreSQL
DB_HOST=pgbouncer  # bukan postgres langsung
```

## Tips Hemat Biaya saat Scaling

**1. Scale down di jam sepi**
Jika traffic aplikasimu jelas-jelas rendah di malam hari, kurangi replicas di malam hari dan tambah lagi di pagi hari. Helipod menghitung resource per hari, jadi mengubah spec di tengah hari tetap lebih hemat.

**2. Monitor overkill**
Pakai tab Metrics untuk identifikasi service yang over-provisioned. CPU selalu <10%? Memory selalu <30%? Turunkan spec dan hemat biaya.

**3. Pisahkan background worker**
Jangan jalankan background worker (queue, scheduler) di pod yang sama dengan web server. Deploy sebagai pod terpisah dengan spec yang lebih kecil.

**4. Gunakan `helipack.json` untuk hint resource:**
```json
{
  "spec": {
    "cpu": 0.5,
    "memory": 512
  }
}
```

## Kesimpulan

Scaling di Helipod dirancang semudah mungkin, geser slider untuk vertical scaling, ubah angka untuk horizontal scaling. Tidak perlu konfigurasi load balancer, tidak perlu setup auto-scaling rules yang kompleks.

Yang terpenting: scale berdasarkan data dari tab **Metrics**, bukan berdasarkan asumsi. Mulai kecil, monitor, dan scale saat memang dibutuhkan.

Ingin setup database untuk aplikasimu? Baca [Deploy PostgreSQL di Helipod](/blog/deploy-postgresql-di-helipod).

Punya pertanyaan? Hubungi kami di [support@helipod.io](mailto:support@helipod.io) atau bergabung ke komunitas di [hangar.helipod.io](https://hangar.helipod.io).