Studi Kasus, Migrasi Aplikasi MERN Stack dari On Premise ke DigitalOcean

Kamandanu Wijaya 25 Januari 2026 ⏱️ 6 menit baca
Diagram migrasi aplikasi MERN 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.

  1. Single point of failure. Kalau server mati, semua mati.
  2. Backup manual. Admin IT harus ingat untuk backup setiap minggu.
  3. Tidak ada monitoring. Mereka baru tahu server bermasalah kalau aplikasi tidak bisa diakses.
  4. Akses dari luar sulit. Harus VPN ke kantor untuk maintenance.
  5. 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

  1. Login ke DigitalOcean
  2. Create → Droplets
  3. Pilih Ubuntu 22.04 LTS
  4. Pilih Basic plan, 2 vCPU / 4GB RAM
  5. Pilih region Singapore (closest ke Indonesia)
  6. Enable backups (automated weekly)
  7. Add SSH key untuk akses

Setup Managed MongoDB

  1. Databases → Create Database Cluster
  2. Pilih MongoDB
  3. Pilih Basic plan (shared CPU)
  4. Region sama dengan Droplet
  5. Create cluster

Setelah cluster ready, catat connection string yang diberikan.

Setup Spaces untuk Storage

  1. Spaces → Create Space
  2. Naming convention yang jelas
  3. 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

  1. Di domain registrar, arahkan A record ke IP Droplet
  2. 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.

AspekSebelumSesudah
Uptime~95% (tergantung listrik)99.9% (SLA DigitalOcean)
BackupManual mingguanOtomatis harian
MonitoringTidak adaReal-time alerts
DeploymentManual SSHAutomated via GitHub
BiayaTidak terukur$44/bulan predictable
MaintenanceAdmin IT lokalRemote 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.

Butuh Bantuan?

Jika ingin implementasi aman di produksi, saya bisa bantu assessment, eksekusi, dan hardening.

Hubungi Saya
Kamandanu Wijaya

Tentang 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 Profil

Butuh Solusi IT?

Tim DoWithSudo siap membantu setup server, VPS, dan sistem keamanan lo.

Hubungi Kami

Artikel Terkait

WhatsApp