Panduan

Oleh Matt Connor 2026-10-10

Cara Menjalankan Rocket.Chat di VPS dengan Docker Compose

Q: Bagaimana cara mencadangkan Rocket.Chat yang di-self-host?

Buat dump database yang konsisten menggunakan mongodump, bukan dengan menyalin volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Arsip tersebut berisi pengguna, channel, pesan, dan pengaturan. Arsip juga berisi file yang diunggah jika penyimpanan tetap menggunakan GridFS. Salin arsip ke luar server. Otomatiskan pencadangan setiap malam dengan cron. Lakukan uji mongorestore pada server sementara agar Anda mengetahui bahwa proses pemulihan benar-benar berfungsi.

Panduan lengkap self-host Rocket.Chat di VPS dengan Docker Compose, termasuk replica set MongoDB satu node, TLS, pencadangan, dan solusi error umum.

Yang akan Anda bangun

Chat tim privat yang sepenuhnya Anda miliki: Rocket.Chat yang berjalan pada VPS milik Anda sendiri menggunakan Docker Compose, dengan TLS termination, serta setiap pesan tersimpan dalam database MongoDB yang dapat dicadangkan dan dipindahkan. Rocket.Chat adalah alternatif open-source yang matang untuk Slack dan Teams, dengan channel, pesan langsung, thread, berbagi file, serta fitur suara dan video. Semuanya berjalan pada hardware yang Anda sewa dan kendalikan. Namun, Rocket.Chat bukan satu-satunya opsi yang layak. Jika Anda masih menentukan pilihan, perbandingan Mattermost, Rocket.Chat, Synapse, dan Zulip membandingkan semuanya berdasarkan hal-hal yang sering menimbulkan masalah di kemudian hari: RAM, database, push mobile, SSO, dan upgrade. Aplikasi ini terdiri dari satu container yang dapat berjalan dalam hitungan menit. Hampir semua masalah yang benar-benar terjadi berada pada database di sebelahnya. Karena itu, sebagian besar panduan ini membahas MongoDB, terutama satu persyaratan yang sering mengejutkan pengguna saat pertama kali mengetahuinya: Rocket.Chat tidak dapat berjalan dengan MongoDB standalone. Rocket.Chat memerlukan replica set, meskipun "set" tersebut hanya terdiri dari satu node.

Prasyarat, dan perhitungan RAM yang sering diabaikan

Sesuaikan kapasitas server secara realistis. Batas minimum yang masuk akal untuk tim kecil adalah 2 vCPU dan 4 GB RAM. Proses Node.js milik Rocket.Chat biasanya memerlukan sekitar 1 hingga 1.5 GB sendiri, sedangkan cache WiredTiger MongoDB secara default menggunakan nilai yang lebih besar antara 50% dari (total RAM dikurangi 1 GB) atau 0.256 GB. Default tersebut mengasumsikan bahwa mongod menggunakan mesin secara eksklusif: nilainya dihitung dari total RAM dan tidak memperhitungkan penggunaan Node yang sudah berjalan. Karena itu, nilainya menjadi 1.5 GB pada server dengan RAM 4 GB dan sekitar 0.5 GB pada server dengan RAM 2 GB, di luar heap Node, penggunaan memori mongod di luar cache, dan sistem operasi. Pada VPS dengan RAM 2 GB, keduanya dapat berjalan saat boot, tetapi akan berebut memori begitu trafik nyata masuk: MongoDB memperbesar cache-nya, Node memperbesar heap-nya, kernel kehabisan halaman memori, dan out-of-memory killer menghentikan proses yang paling besar, biasanya mongod. Container menampilkan Killed, Docker me-restart container tersebut, dan server chat Anda terputus setiap beberapa menit saat menerima beban yang seharusnya dapat ditanganinya. RAM 2 GB cukup untuk uji coba dengan dua orang, tetapi tidak cukup untuk server tim. Mulailah dengan RAM 4 GB, dan gunakan RAM 8 GB jika Anda memperkirakan puluhan pengguna bersamaan, panggilan video, atau riwayat upload yang terus bertambah. Perhitungkan juga layanan lain yang harus dijalankan oleh server tersebut. Menempatkan workspace AFFiNE bergaya Notion pada VPS yang sama menambahkan empat container yang berebut halaman memori yang sama, sehingga kebutuhan RAM-nya harus ditambahkan di atas kebutuhan Rocket.Chat, bukan diambil dari alokasinya.

Anda juga memerlukan tiga hal sebelum memulai. Nama domain dengan A record yang mengarah ke IP publik VPS. Fitur real-time Rocket.Chat dan klien seluler memerlukan hostname yang stabil, bukan IP tanpa domain. Port 80 dan 443 harus terbuka pada firewall server dan firewall jaringan provider. Pada sebagian besar panel, firewall provider merupakan kontrol yang terpisah. Anda juga memerlukan VPS KVM Ubuntu 24.04 yang masih baru, dengan akses root atau sudo. Jika Anda masih mempertimbangkan apakah server chat merupakan layanan pertama yang tepat untuk dijalankan, panduan tentang layanan yang layak di-self-host pada 2026 menjelaskan berbagai komprominya.

Instal Docker Engine dan plugin Compose

Gunakan repositori apt milik Docker, bukan paket docker.io yang disediakan Ubuntu dan bukan biner Python standalone docker-compose yang sudah usang. Compose modern adalah plugin Docker yang dipanggil sebagai docker compose, dengan spasi, bukan tanda hubung. docker-compose v1 yang lama sudah tidak didukung dan tidak menangani sintaks healthcheck serta dependensi di bawah ini dengan benar.

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Pastikan kedua komponen tersedia:

sudo docker version
sudo docker compose version

docker compose version yang menampilkan baris versi adalah pemeriksaan yang penting. Rilis saat ini menampilkan Docker Compose version v5.x (v5.6.0, dirilis pada 2 October 2026, merupakan versi terbaru per 2026-10-10); instalasi yang lebih lama mungkin masih menampilkan v2.x, dan Docker mendukung keduanya. Docker menjelaskan bahwa Compose v5 secara fungsional identik dengan v2, tetapi diberi nomor v5 untuk menghindari kerancuan dengan format file compose v2 dan v3 yang lama. Keduanya dapat digunakan dalam panduan ini. Jika muncul error docker: 'compose' is not a docker command, plugin belum terinstal dan Anda akan mengalami kegagalan yang membingungkan pada tahap berikutnya. Perbaiki masalah ini sekarang.

File Compose: MongoDB sebagai replica set satu node

Bagian ini sering dikonfigurasi secara keliru, jadi baca dengan saksama. Rocket.Chat menggunakan change stream MongoDB untuk mengirim pesan baru secara real time kepada klien yang terhubung, dan change stream hanya tersedia pada replica set. Jika Rocket.Chat diarahkan ke mongod standalone biasa, aplikasi akan terhubung, gagal membuka change stream, lalu terus-menerus melakukan restart loop. Solusinya sederhana: jalankan satu container MongoDB biasa, tetapi mulai dengan --replSet, lalu inisialisasi set yang memiliki satu anggota.

Buat direktori kerja dan sebuah compose.yml:

services:
  mongodb:
    image: mongo:8.0
    restart: always
    command: ["mongod", "--replSet", "rs0", "--bind_ip_all", "--oplogSize", "128"]
    volumes:
      - mongodb_data:/data/db
      - mongodb_config:/data/configdb
    healthcheck:
      test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 10s
      retries: 12

  rocketchat:
    image: registry.rocket.chat/rocketchat/rocket.chat:8.5.1
    restart: always
    depends_on:
      mongodb:
        condition: service_healthy
    environment:
      MONGO_URL: "mongodb://mongodb:27017/rocketchat?replicaSet=rs0"
      MONGO_OPLOG_URL: "mongodb://mongodb:27017/local?replicaSet=rs0"
      ROOT_URL: "https://chat.example.com"
      PORT: "3000"
    ports:
      - "127.0.0.1:3000:3000"

volumes:
  mongodb_data:
  mongodb_config:

Beberapa pilihan di sini memang disengaja. Port Rocket.Chat dipublikasikan ke 127.0.0.1:3000, bukan 0.0.0.0. Aplikasi itu sendiri tidak menggunakan TLS, sehingga hanya reverse proxy pada server yang sama yang boleh mengaksesnya. Jika di-bind ke semua interface, halaman login tanpa enkripsi akan langsung terekspos ke Internet publik. MongoDB sama sekali tidak dipublikasikan ke host. MongoDB hanya dapat diakses melalui jaringan internal Compose dengan nama mongodb, yaitu hostname yang digunakan oleh MONGO_URL. MONGO_URL meneruskan ?replicaSet=rs0, yang menetapkan nama set secara eksplisit. MongoDB merekomendasikan pengaturan ini agar perilaku antar-driver konsisten. Jika pengaturan tersebut tidak digunakan, hal itu tidak langsung menyebabkan masalah: directConnection memiliki nilai default false, sehingga driver tetap menemukan replica set dan mengirim operasi ke primary, selama set diinisialisasi dengan hostname yang dapat di-resolve oleh Rocket.Chat. Bagian berikutnya menangani hal tersebut. MONGO_OPLOG_URL menunjuk ke database local tempat oplog disimpan. Rocket.Chat modern lebih memilih change stream, tetapi pengaturan ini tidak berbahaya dan menjaga kompatibilitas dengan code path lama. depends_on menggunakan condition: service_healthy, sehingga Compose menunggu hingga MongoDB merespons ping sebelum memulai Rocket.Chat. Itulah fungsi healthcheck.

Tetapkan tag versi yang benar pada kedua image, yaitu mongo:8.0 dan rilis Rocket.Chat eksplisit seperti 8.5.1 di sini. Jangan pernah menggunakan :latest, karena hal itu dapat mengubah docker pull tanpa pengawasan menjadi upgrade yang tidak disengaja dan tidak dapat dimigrasikan. Periksa rilis Rocket.Chat stabil terbaru dan versi MongoDB yang didukungnya sebelum menetapkan versi. Rocket.Chat menerbitkan dokumen informasi yang dapat dibaca mesin untuk setiap rilis: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' mengembalikan compatibleMongoVersions: ["8.0"] untuk 8.5.1, sehingga mongo:8.0 adalah satu-satunya engine yang didukung, ditambah flag lts yang menunjukkan apakah rilis tersebut merupakan build dukungan jangka panjang yang layak ditetapkan untuk server yang tidak ingin sering dipantau. Tidak semua proyek menerbitkan image berversi. Jika demikian, tetapkan versinya dari source: melakukan self-hosting tracker latihan openGym berarti checkout tag git tertentu dan melakukan build dari tag tersebut, bukan mengikuti branch yang terus berubah.

Inisialisasi replica set

Jalankan stack:

sudo docker compose up -d

Rocket.Chat akan langsung mengalami crash, dan Docker akan terus me-restart-nya. Hal ini diharapkan karena replica set belum ada. Buat replica set satu kali secara manual:

sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'

Hasil yang benar adalah { ok: 1 }. Dalam beberapa detik, node tunggal akan memilih dirinya sendiri sebagai primary. Konfirmasikan dengan:

sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'

Anda harus melihat PRIMARY. Detail terpenting pada seluruh halaman ini adalah argumen host: "mongodb:27017". Jika Anda menjalankan rs.initiate() tanpa daftar members, MongoDB akan mengumumkan replica set menggunakan hostname internal container, yaitu hash acak seperti a1b2c3d4e5f6. Rocket.Chat, yang terhubung dari container-nya sendiri, tidak dapat me-resolve nama tersebut. Akibatnya, driver MongoDB gagal melakukan resolusi DNS dan terus mengulang sambil mencatat MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Selalu lakukan inisialisasi dengan nama service eksplisit yang sesuai dengan MONGO_URL Anda.

Boot pertama: pantau proses startup

Setelah set berstatus primary, Rocket.Chat akan terhubung dengan benar saat restart berikutnya dan memulai migrasi pada proses pertama. Pantau log:

sudo docker compose logs -f rocketchat

Baris yang Anda tunggu adalah banner startup:

+--------------------------------------------+
        SERVER RUNNING
   Rocket.Chat Version: 8.5.1
        NodeJS Version: 22.22.3 - x64
+--------------------------------------------+

Boot pertama berlangsung lambat. Aplikasi menjalankan migrasi database dan membuat indeks, jadi tunggu satu atau dua menit sebelum memeriksa masalah. Jika log justru terus menampilkan MongoServerSelectionError: Server selection timed out after 30000 ms dengan deskripsi topologi bertipe ReplicaSetNoPrimary, replica set belum diinisialisasi. Jika log terus menampilkan getaddrinfo ENOTFOUND pada hash acak, replica set diinisialisasi dengan host yang salah. Dalam kedua kasus tersebut, kembali ke langkah sebelumnya. Setelah Anda melihat SERVER RUNNING, Rocket.Chat mendengarkan pada 127.0.0.1:3000 dan saatnya memasang hostname nyata serta TLS di depannya.

Lindungi dengan TLS

Jangan pernah mengekspos Rocket.Chat melalui HTTP biasa. Setelah masuk melalui http:// satu kali, Anda telah memberikan kata sandi admin kepada siapa pun yang dapat menyadap jalur tersebut. Hentikan TLS pada reverse proxy di server yang sama, lalu teruskan koneksi ke 127.0.0.1:3000. Ada dua hal yang penting: proxy harus meneruskan header upgrade WebSocket karena Rocket.Chat beroperasi secara real-time dan akan gagal tanpa header tersebut, serta ROOT_URL pada container harus sama persis dengan alamat HTTPS publik yang diketik pengguna.

Mulai dengan server block nginx HTTP biasa yang melakukan proxy ke aplikasi dan meneruskan header upgrade. Simpan sebagai /etc/nginx/sites-available/rocketchat, buat symlink ke dalam sites-enabled, lalu reload:

server {
    listen 80;
    server_name chat.example.com;

    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Biarkan pada port 80 untuk sementara. Block dengan listen 443 ssl; tanpa sertifikat bahkan tidak akan lolos sudo nginx -t. Reload nginx (sudo nginx -t && sudo systemctl reload nginx), lalu terbitkan sertifikat. Cara paling praktis di Ubuntu adalah Sertifikat TLS Let's Encrypt dengan Certbot dan nginx: certbot --nginx menulis ulang block di atas secara langsung dengan menambahkan listen 443 ssl;, baris ssl_certificate, dan redirect otomatis dari 80 ke 443, lalu menjadwalkan renewal untuk Anda. Jika Anda sudah menjalankan beberapa container di belakang satu proxy, Traefik dengan TLS otomatis untuk banyak aplikasi Docker adalah pilihan yang lebih rapi. Tambahkan label router dan service ke service rocketchat, lalu Traefik akan meminta dan memperbarui sertifikat untuk Anda tanpa nginx block. Apa pun pilihannya, atur ROOT_URL ke https://chat.example.com di compose.yml, lalu jalankan kembali sudo docker compose up -d agar container menerapkan perubahan tersebut. Jika Anda ingin server hanya dapat dijangkau dari jaringan internal Anda, bukan dari Internet publik, tempatkan VPN WireGuard yang di-host sendiri pada VPS di depannya dan bind proxy ke alamat tunnel.

Wizard penyiapan pertama

Buka https://chat.example.com. Rocket.Chat akan memandu Anda melalui wizard singkat. Pertama, isi akun admin, nama lengkap, nama pengguna, email, dan kata sandi yang kuat. Ini adalah satu-satunya akun yang tersedia, jadi jangan sampai kehilangan akses. Berikutnya, isi informasi organisasi dan server: nama, industri, ukuran, nama situs, dan bahasa default. Bagian ini hanya bersifat kosmetik. Isi datanya lalu lanjutkan.

Selanjutnya adalah pilihan yang paling penting: daftarkan workspace ini ke Rocket.Chat Cloud, atau biarkan tetap mandiri.

Pendaftaran mengaktifkan notifikasi push seluler melalui gateway Rocket.Chat dan marketplace add-on, tetapi membuat server memiliki hubungan dengan control plane cloud Rocket.Chat. Push yang dikirim melalui gateway juga dihitung dalam batas bulanan workspace Anda. Mode mandiri membuat server sepenuhnya privat dan bebas dependensi. Namun, aplikasi resmi iOS dan Android tidak lagi menerima notifikasi push karena dokumentasi Rocket.Chat menyatakan bahwa aplikasi tersebut hanya berfungsi dengan cloud gateway-nya. Gateway juga tidak akan berjalan pada workspace yang tidak terdaftar.

Solusinya adalah menggunakan build aplikasi seluler berlabel Anda sendiri. Nonaktifkan gateway pada pengaturan Push, masukkan sertifikat APNs dan kredensial Firebase Cloud Messaging milik Anda, lalu minta pengguna menginstal aplikasi Anda, bukan aplikasi resmi. Pilih mode mandiri jika privasi adalah tujuan utama, pengguna Anda terutama menggunakan aplikasi web, atau Anda siap menyediakan aplikasi seluler sendiri. Pilih pendaftaran jika push pada aplikasi resmi merupakan kebutuhan mutlak. Anda dapat mengubah pilihan ini nanti melalui Admin.

Perketat sebelum mengundang siapa pun

Rocket.Chat secara default mengaktifkan open registration. Registration Form diatur ke Public, sehingga siapa pun yang menemukan URL dapat membuat akun. Pada hostname publik, ini menjadi celah akses terbuka. Buka Admin → Settings → Accounts → Registration dan atur Registration Form ke Disabled agar akun dibuat secara manual atau melalui invite link, atau ke Secret URL. Saat berada di sana, nonaktifkan Allow Anonymous Read dan Allow Anonymous Write, kecuali Anda memang menginginkan channel publik yang hanya dapat dibaca. Jika membuat setiap akun secara manual terasa merepotkan dan ini bukan satu-satunya service yang digunakan tim untuk login, arahkan login OAuth Rocket.Chat ke server Authentik SSO yang di-host sendiri, sehingga proses penambahan dan penghapusan anggota ditangani sekali di satu tempat, bukan satu per satu pada setiap aplikasi.

Tentukan juga lokasi penyimpanan upload. Secara default, penyimpanan File Upload menggunakan GridFS, yang menyimpan setiap gambar dan attachment langsung di dalam MongoDB. Cara ini sederhana, tetapi database dan setiap mongodump yang Anda buat akan terus membesar seiring orang menempelkan screenshot. Di Admin → Settings → File Upload, Anda dapat mengganti penyimpanan ke filesystem lokal atau bucket yang kompatibel dengan S3, lalu menetapkan ukuran file maksimum yang wajar. Jika tim Anda bertukar seluruh pustaka foto, bukan sekadar screenshot sesekali, file tersebut sebaiknya disimpan di server foto khusus, bukan di database chat. Perbandingan PhotoPrism dan Immich membahas biaya RAM masing-masing serta perintah backup yang diperlukan. Untuk tim kecil, GridFS sudah memadai. Namun, pahami bahwa ukuran backup akan terus bertambah.

Pencadangan dengan mongodump

Seluruh data Anda berada di volume mongodb_data. Jangan menyalin volume begitu saja dari database yang sedang berjalan. Buat dump yang konsisten dengan mongodump dan alirkan hasilnya ke file pada host:

sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gz

Arsip gzip tunggal tersebut berisi seluruh workspace Anda: pengguna, channel, pesan, pengaturan, serta file jika upload masih disimpan di GridFS. Jika Anda memindahkan upload ke filesystem atau S3, cadangkan penyimpanan tersebut secara terpisah. Untuk memulihkan data ke stack baru, inisialisasi replica set terlebih dahulu, kemudian jalankan:

sudo docker compose exec -T mongodb mongorestore --archive --gzip --drop < rocketchat-2026-07-15.archive.gz

Salin arsip tersebut ke luar server, misalnya ke object storage atau server lain. Simpan di lokasi apa pun yang tidak ikut kehilangan backup jika VPS mati. Jalankan dump dari cron setiap malam. Backup yang belum pernah dipulihkan hanyalah harapan, bukan backup. Uji pemulihan satu kali pada VPS sementara agar Anda mengetahui bahwa prosesnya berhasil sebelum benar-benar diperlukan.

Upgrade: pin tag, baca catatan rilis, dan ikuti matriks MongoDB

Dua aturan membuat proses upgrade tetap sederhana. Pertama, upgrade Rocket.Chat satu versi mayor setiap kali. Rocket.Chat menjalankan migrasi skema saat boot, dan dokumentasi upgrade Rocket.Chat menyatakan bahwa pembaruan harus dilakukan secara berurutan di antara versi mayor. Dokumentasi tersebut memperingatkan bahwa melewati versi mayor dapat menyebabkan masalah kompatibilitas serius. Jangan berasumsi bahwa software akan mencegahnya: dokumentasinya tidak menjamin bahwa lompatan langsung dari 6.x ke 8.x akan ditolak dengan aman, dan migrasi yang gagal di tengah proses akan meninggalkan lock yang terpasang sehingga perlu diperbaiki secara manual. Ubah tag image ke rilis terbaru dari versi mayor berikutnya, baca catatan rilis tersebut untuk mengetahui perubahan yang dapat memutus kompatibilitas, jalankan docker compose up -d, lalu pantau log sampai migrasi selesai sebelum melanjutkan. Kedua, ikuti matriks dukungan MongoDB. Setiap rilis Rocket.Chat mendukung rangkaian versi MongoDB tertentu, dan curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions memberi tahu Anda versi yang sesuai. Saat mengupgrade MongoDB, misalnya dari 7.0 ke 8.0, lakukan satu versi mayor setiap kali dan atur feature-compatibility version setelah setiap lompatan. Pada MongoDB 8.0, perintah tersebut memerlukan confirm: true secara eksplisit. Jika tidak, perintah akan gagal dan menampilkan pesan yang meminta Anda menjalankannya kembali dengan flag konfirmasi:

sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'

Buat mongodump sebelum setiap upgrade kedua komponen. Itulah seluruh perlindungan yang diperlukan.

Mode kegagalan, dengan string yang tepat

Rocket.Chat terus melakukan restart-loop tepat setelah docker compose up, dan docker compose logs rocketchat terisi dengan MongoServerSelectionError. MongoDB berjalan, tetapi driver tidak dapat memilih primary, dan string yang tepat menunjukkan kesalahan yang terjadi. Server selection timed out after 30000 ms dengan tipe topologi ReplicaSetNoPrimary berarti Anda belum pernah menjalankan rs.initiate(); set tersebut belum memiliki konfigurasi. getaddrinfo ENOTFOUND yang diikuti hash acak berarti Anda melakukan inisialisasi tanpa host: "mongodb:27017" eksplisit, sehingga MongoDB mengiklankan hostname container yang tidak dapat di-resolve. Lakukan diagnosis dengan sudo docker compose exec mongodb mongosh --eval 'rs.status()': jika muncul error MongoServerError: no replset config has been received, inisialisasikan set tersebut; jika terlihat member yang name-nya berupa hash acak, lakukan inisialisasi ulang menggunakan nama service.

Antarmuka web terbuka, tetapi proses login terus berputar dan tidak pernah selesai. Buka console browser dan Anda akan melihat WebSocket connection to 'wss://chat.example.com/websocket' failed. Hampir selalu penyebabnya adalah ketidaksesuaian ROOT_URL atau proxy yang tidak meneruskan header upgrade. Pastikan ROOT_URL sama persis dengan alamat publik, termasuk https://, dan blok location nginx Anda menetapkan Upgrade serta Connection "upgrade" dengan proxy_http_version 1.1. Setelah mengubah salah satunya, jalankan kembali docker compose up -d.

Sebuah container terus berhenti dan docker compose ps menunjukkan Restarting. docker compose logs terhenti di tengah baris, dan sudo dmesg | tail menunjukkan Out of memory: Killed process 12345 (mongod) dari oom-killer; kode keluar adalah 137. RAM server habis. Solusi yang sebenarnya adalah menggunakan VPS yang lebih besar, minimal 4 GB. Sebagai solusi sementara, tambahkan swap dan batasi cache MongoDB dengan --wiredTigerCacheSizeGB di dalam command-nya. Tetapkan nilainya di bawah default, bukan di atasnya. Contohnya, gunakan 1 pada server 4 GB (default 1.5) atau 0.3 pada server 2 GB (default sekitar 0.5). Namun, swap hanya menunda OOM berikutnya saat server menerima beban nyata:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

docker compose up gagal dengan Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Port 3000 sudah digunakan oleh proses lain. Penyebabnya sering kali adalah container Rocket.Chat sebelumnya yang tidak berhenti dengan bersih atau aplikasi lain. Cari proses tersebut dengan sudo ss -ltnp | grep :3000, hentikan proses atau container itu, atau ubah sisi host pada pemetaan ke 127.0.0.1:3001:3000 dan sesuaikan proxy_pass pada proxy Anda.

FAQ

Apakah Rocket.Chat benar-benar memerlukan replica set MongoDB?

Ya, bahkan untuk satu server dengan satu node database. Rocket.Chat mengirimkan pesan secara real time menggunakan change stream MongoDB. Fitur ini hanya tersedia pada replica set, sehingga mongod standalone tidak dapat membukanya. Anda tidak memerlukan beberapa mesin. Jalankan satu container MongoDB dengan --replSet rs0, lalu inisialisasi set yang terdiri dari satu anggota menggunakan rs.initiate(). Jika langkah ini dilewati, driver tidak pernah menemukan primary. Akibatnya, Rocket.Chat terus melakukan restart loop dengan MongoServerSelectionError: Server selection timed out dan tidak pernah menyelesaikan proses boot.

Berapa banyak RAM yang diperlukan Rocket.Chat yang di-self-host?

Siapkan 4 GB sebagai minimum praktis dan 8 GB untuk tim yang aktif. Proses Node milik Rocket.Chat menggunakan sekitar 1 hingga 1,5 GB. Cache WiredTiger default MongoDB berukuran setengah dari total RAM dikurangi 1 GB. Ukuran ini dihitung seolah-olah tidak ada proses lain yang berjalan di server. Pada server dengan RAM 2 GB, cache tersebut, heap Node, dan overhead mongod saling berebut memori. OOM killer akan menghentikan mongod saat ada beban nyata. Log akan menampilkan Killed dan exit code 137. RAM 2 GB hanya cukup untuk mengevaluasi software dengan beberapa pengguna uji.

Bagaimana cara menempatkan Rocket.Chat di balik HTTPS?

Jalankan reverse proxy pada VPS yang sama untuk melakukan TLS termination dan meneruskan koneksi ke 127.0.0.1:3000. Atur ROOT_URL pada container ke alamat publik https:// Anda. Proxy harus meneruskan header WebSocket upgrade. Jika tidak, proses login akan berhenti. Certbot dengan nginx adalah konfigurasi paling sederhana untuk satu aplikasi. Traefik lebih praktis jika Anda menjalankan beberapa container di balik satu proxy dan menginginkan pengelolaan sertifikat otomatis.

Bagaimana cara mencadangkan Rocket.Chat yang di-self-host?

Buat dump database yang konsisten menggunakan mongodump, bukan dengan menyalin volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Arsip tersebut berisi pengguna, channel, pesan, dan pengaturan. Arsip juga berisi file yang diunggah jika penyimpanan tetap menggunakan GridFS. Salin arsip ke luar server. Otomatiskan pencadangan setiap malam dengan cron. Lakukan uji mongorestore pada server sementara agar Anda mengetahui bahwa proses pemulihan benar-benar berfungsi.

Bagaimana cara memutakhirkan Rocket.Chat tanpa merusak MongoDB?

Mutakhirkan Rocket.Chat satu versi mayor setiap kali. Rocket.Chat menjalankan migrasi saat boot. Dokumentasinya memperingatkan bahwa melewati versi mayor dapat menyebabkan masalah kompatibilitas serius dan tidak menjamin proses akan berhenti untuk mencegahnya. Baca catatan setiap rilis sebelum mengubah tag image yang dipin. Periksa versi MongoDB yang didukung oleh rilis target Anda menggunakan curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions. Saat memutakhirkan MongoDB, lakukan satu versi mayor setiap kali. Setelah setiap lompatan versi, atur setFeatureCompatibilityVersion menggunakan confirm: true. Selalu buat mongodump terlebih dahulu.

#rocket-chat #docker #docker-compose #mongodb #self-hosting #tls