Studi Kasus, Migrasi Aplikasi MERN Stack dari On Premise ke DigitalOcean
“Server kantor mati. UPS habis. Semua aplikasi down.”
Di artikel ini, kita membahas migrasi MERN ke DigitalOcean secara praktis agar kamu paham konteks dan penerapannya.
Pesan WhatsApp itu masuk pukul 2 dini hari. Dari client yang menjalankan aplikasi inventory management berbasis MERN stack di server fisik kantornya.
Butuh waktu 6 jam untuk recovery setelah listrik kembali. Data 2 hari hilang karena backup terakhir adalah backup mingguan yang dilakukan hari Jumat.
Kejadian itu menjadi titik balik. Client akhirnya setuju untuk migrasi ke cloud. Dan pilihan jatuh ke DigitalOcean karena budget mereka tidak sesuai dengan AWS pricing.
Ini adalah catatan lengkap proses migrasi tersebut.
Kondisi awal sistem
Sebelum migrasi, mari saya gambarkan kondisi yang ada.
Arsitektur on premise
Aplikasi berjalan di satu server fisik Dell PowerEdge yang sudah berumur 5 tahun.
- Frontend: React app yang diserve oleh Nginx
- Backend: Node.js dengan Express, berjalan via PM2
- Database: MongoDB standalone instance
- OS: Ubuntu 18.04 LTS (sudah out of support)
Semua berjalan di satu mesin. Development, staging, production. Satu server untuk semua.
Masalah yang dihadapi
Selain insiden mati listrik, ada beberapa masalah kronis.
- Single point of failure. Kalau server mati, semua mati.
- Backup manual. Admin IT harus ingat untuk backup setiap minggu.
- Tidak ada monitoring. Mereka baru tahu server bermasalah kalau aplikasi tidak bisa diakses.
- Akses dari luar sulit. Harus VPN ke kantor untuk maintenance.
- Scaling tidak mungkin. Server sudah mentok RAM dan CPU.
Perencanaan migrasi
Sebelum eksekusi, saya habiskan satu minggu untuk assessment dan planning.
Inventory aplikasi
Langkah pertama adalah dokumentasi lengkap tentang aplikasi.
- Versi Node.js yang digunakan (14.x)
- Versi MongoDB (4.4)
- Environment variables yang diperlukan
- File upload dan storage yang ada
- Integrasi dengan sistem lain (tidak ada)
- Volume data di MongoDB (sekitar 15GB)
Arsitektur target di DigitalOcean
Untuk menjaga biaya tetap terkontrol sambil meningkatkan reliability, ini arsitektur yang saya usulkan.
Droplet 1: Application Server
- 2 vCPU, 4GB RAM ($24/bulan)
- Docker untuk containerization
- Nginx sebagai reverse proxy
- Frontend dan Backend dalam container terpisah
Managed MongoDB (DigitalOcean Databases)
- Basic plan ($15/bulan)
- Daily backup otomatis
- Standalone cluster cukup untuk skala ini
Spaces (Object Storage)
- Untuk file uploads
- Lebih reliable daripada disk lokal
- $5/bulan untuk 250GB
Total biaya bulanan: sekitar $44, dibanding maintenance server fisik yang tidak terukur.
Eksekusi migrasi
Proses migrasi dilakukan dalam beberapa fase untuk meminimalkan downtime.
Fase 1: dockerization aplikasi
Sebelum bisa migrasi, aplikasi perlu dicontainerize. Ini langkah yang sering dilewati tapi sangat krusial.
Dockerfile untuk Backend
FROM node:14-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 5000
CMD ["node", "server.js"]
Dockerfile untuk Frontend
FROM node:14-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
Docker Compose untuk Orchestration
version: '3.8'
services:
backend:
build: ./backend
environment:
- MONGODB_URI=${MONGODB_URI}
- JWT_SECRET=${JWT_SECRET}
- NODE_ENV=production
restart: unless-stopped
frontend:
build: ./frontend
ports:
- "80:80"
- "443:443"
depends_on:
- backend
restart: unless-stopped
Kalau kamu belum familiar dengan Docker, saya sudah menulis panduan Docker dari nol yang membahas fundamental containerization.
Fase 2: setup DigitalOcean infrastructure
Membuat Droplet
- Login ke DigitalOcean
- Create → Droplets
- Pilih Ubuntu 22.04 LTS
- Pilih Basic plan, 2 vCPU / 4GB RAM
- Pilih region Singapore (closest ke Indonesia)
- Enable backups (automated weekly)
- Add SSH key untuk akses
Setup Managed MongoDB
- Databases → Create Database Cluster
- Pilih MongoDB
- Pilih Basic plan (shared CPU)
- Region sama dengan Droplet
- Create cluster
Setelah cluster ready, catat connection string yang diberikan.
Setup Spaces untuk Storage
- Spaces → Create Space
- Naming convention yang jelas
- Catat access key dan secret key
Fase 3: migrasi data MongoDB
Ini bagian yang paling kritis. Data tidak boleh hilang.
Export dari Server Lama
mongodump --uri="mongodb://localhost:27017/inventory" --out=/backup/$(date +%Y%m%d)
Compress untuk Transfer
tar -czvf mongodb-backup.tar.gz /backup/20260125/
Transfer ke Server Baru
scp mongodb-backup.tar.gz root@droplet-ip:/tmp/
Import ke Managed MongoDB
mongorestore --uri="mongodb+srv://user:pass@cluster.mongodb.net/inventory" /tmp/backup/inventory/
Proses import memakan waktu sekitar 45 menit untuk 15GB data.
Fase 4: deploy aplikasi
Setelah data siap, saatnya deploy aplikasi.
Clone Repository di Server
git clone https://github.com/company/inventory-app.git /opt/inventory
cd /opt/inventory
Setup Environment Variables
cat > .env << EOF
MONGODB_URI=mongodb+srv://user:pass@cluster.mongodb.net/inventory
JWT_SECRET=your-secure-jwt-secret
DO_SPACES_KEY=your-spaces-key
DO_SPACES_SECRET=your-spaces-secret
DO_SPACES_BUCKET=inventory-files
NODE_ENV=production
EOF
Build dan Run
docker compose build
docker compose up -d
Fase 5: DNS dan SSL
Setup Domain
- Di domain registrar, arahkan A record ke IP Droplet
- Tunggu propagasi (biasanya 5 menit sampai 24 jam)
Setup SSL dengan Let’s Encrypt
Saya menggunakan Nginx sebagai reverse proxy dengan Certbot.
apt install certbot python3-certbot-nginx -y
certbot --nginx -d app.company.com
Certbot otomatis mengkonfigurasi Nginx dan setup autorenewal.
Tantangan yang dihadapi
Migrasi tidak selalu berjalan mulus. Ini beberapa masalah yang muncul.
MongoDB connection string format
Connection string untuk MongoDB Atlas/Managed berbeda dengan standalone. Format mongodb+srv:// memerlukan DNS resolution yang berbeda.
Solusi: Update driver MongoDB di aplikasi ke versi terbaru yang support SRV records.
File upload path
Aplikasi awalnya menyimpan file di /var/uploads/. Di container, path ini tidak persisten.
Solusi: Migrate semua file ke DigitalOcean Spaces dan update aplikasi untuk menggunakan S3 compatible SDK.
const AWS = require('aws-sdk');
const spacesEndpoint = new AWS.Endpoint('sgp1.digitaloceanspaces.com');
const s3 = new AWS.S3({
endpoint: spacesEndpoint,
accessKeyId: process.env.DO_SPACES_KEY,
secretAccessKey: process.env.DO_SPACES_SECRET
});
Timezone issues
Server lama menggunakan timezone Asia/Jakarta. Container default ke UTC.
Solusi: Set timezone di docker-compose.yaml.
environment:
- TZ=Asia/Jakarta
Memory limits
Container backend terkadang crash karena memory limit. Node.js default menggunakan sekitar 1.5GB heap.
Solusi: Set memory limit yang tepat dan add health check.
backend:
deploy:
resources:
limits:
memory: 1G
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
interval: 30s
timeout: 10s
retries: 3
Perbaikan pasca migrasi
Setelah migrasi sukses, saya menambahkan beberapa improvement.
Monitoring dengan uptime kuma
Setup Uptime Kuma di container terpisah untuk monitoring.
uptime-kuma:
image: louislam/uptime-kuma
ports:
- "3001:3001"
volumes:
- uptime-kuma-data:/app/data
restart: unless-stopped
Sekarang ada alert kalau aplikasi down.
Automated backup script
Meskipun DigitalOcean Databases sudah backup otomatis, saya tambahkan backup tambahan ke Spaces.
#!/bin/bash
DATE=$(date +%Y%m%d)
mongodump --uri="$MONGODB_URI" --out=/tmp/backup-$DATE
tar -czvf /tmp/backup-$DATE.tar.gz /tmp/backup-$DATE
s3cmd put /tmp/backup-$DATE.tar.gz s3://inventory-backups/
rm -rf /tmp/backup-$DATE*
Script ini jalan via cron setiap malam.
CI/CD pipeline
Setup GitHub Actions untuk automated deployment.
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Deploy to DigitalOcean
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.DO_HOST }}
username: root
key: ${{ secrets.DO_SSH_KEY }}
script: |
cd /opt/inventory
git pull
docker compose build
docker compose up -d
Untuk hardening server DigitalOcean, pastikan kamu sudah menerapkan best practice keamanan server Linux.
Hasil akhir
Setelah migrasi selesai, ini perbandingannya.
| Aspek | Sebelum | Sesudah |
|---|---|---|
| Uptime | ~95% (tergantung listrik) | 99.9% (SLA DigitalOcean) |
| Backup | Manual mingguan | Otomatis harian |
| Monitoring | Tidak ada | Real-time alerts |
| Deployment | Manual SSH | Automated via GitHub |
| Biaya | Tidak terukur | $44/bulan predictable |
| Maintenance | Admin IT lokal | Remote management |
Client sangat puas. Tidak ada lagi drama mati listrik di tengah malam.
Pelajaran dari proyek ini
Pertama, containerization sebelum migrasi itu wajib. Jangan coba migrasi aplikasi yang masih berjalan langsung di OS.
Kedua, test migrasi data di environment terpisah dulu. Jangan langsung production.
Ketiga, downtime window harus dikomunikasikan dengan jelas ke stakeholder.
Keempat, dokumentasi setiap langkah. Ini akan berguna untuk troubleshooting dan migrasi berikutnya.
Penutup
Migrasi dari on premise ke cloud bukan sekadar memindahkan file. Ini adalah kesempatan untuk memperbaiki arsitektur, meningkatkan reliability, dan mengurangi technical debt.
DigitalOcean terbukti menjadi pilihan yang solid untuk aplikasi skala menengah dengan budget terbatas. Pricing yang straightforward dan dokumentasi yang bagus membuatnya cocok untuk tim kecil.
Kalau aplikasi kamu masih berjalan di server kantor, pertimbangkan migrasi sebelum terjadi insiden yang memaksa.
Lebih baik migrasi terencana daripada recovery darurat di tengah malam.
Semoga pembahasan migrasi MERN ke DigitalOcean ini membantu kamu mengambil keputusan yang lebih tepat di lapangan.
Checklist Implementasi
- Uji langkah di lab terlebih dulu sebelum produksi.
- Dokumentasikan konfigurasi, versi, dan langkah rollback.
- Aktifkan monitoring + alert untuk komponen yang diubah.
- Audit akses dan terapkan prinsip least privilege.
Referensi Resmi
Butuh Bantuan?
Jika ingin implementasi aman di produksi, saya bisa bantu assessment, eksekusi, dan hardening.
Hubungi SayaTentang Penulis
Kamandanu Wijaya
IT Infrastructure & Network Administrator
Administrator infrastruktur & jaringan dengan pengalaman enterprise 14+ tahun, fokus stabilitas, keamanan, dan automasi.
Sertifikasi: Google IT Support, Cisco Networking Academy, DevOps.
Lihat ProfilButuh Solusi IT?
Tim DoWithSudo siap membantu setup server, VPS, dan sistem keamanan lo.
Hubungi Kami