Deploy Rocket.Chat with Docker & Compose

As of December 15, 2023, Rocket.Chat has ceased support for connections from cloud services and official mobile/desktop apps to workspaces running legacy versions outside our support window. Users on unsupported legacy servers are advised to upgrade to the latest Rocket.Chat version to ensure continued access to cloud, mobile, and desktop applications. Each Rocket.Chat version is supported for six months post-release.

Deploying Rocket.Chat using Docker and Docker Compose is a highly recommended deployment method for running Rocket.Chat due to its simplicity and flexibility.

In this guide, you'll learn how to:

What you will have at the end of this guide:

A running Rocket.Chat workspace.
A reverse proxy (Traefik or Nginx) handling HTTPS traffic.
A monitoring stack for your workspace

If you’re using the built in Bitnami MongoDB images, refer to this forum post to upgrade to the official MongoDB 8.2 image required for Rocket.Chat 8.0.

Prerequisites

Before you begin, ensure the following requirements are met:

System requirements: Review the System Requirements guide to confirm your environment is compatible.
Domain: A domain is required for production deployments. Ensure your domain's A record (or CNAME record) points to the public IP address of the server running Docker.
Firewall: If your server has an active firewall, you may need to whitelist specific URLs to allow communication with Rocket.Chat's cloud services (e.g., push notifications, marketplace). Refer to the Firewall Configuration documentation for the complete list of required URLs.

Step 1: Install Docker, Docker Compose, and Git

This guide is intended for Linux users. For other OS or alternative installation methods, refer to the official Docker documentation and Git documentation.

Docker, Docker Compose (Docker Compose v2) and Git are required. If you don't have them installed, you can conveniently set them up in Linux distributions with the command below:
```
curl -L https://get.docker.com | sh # Install Docker
sudo apt install git # Install Git
```
To run Docker commands without using sudo, add your current user to the Docker group.
1. Find your current username with this command:
```
whoami
```
2. Add your user to the docker group, substituting $USER with your username if needed:
```
sudo usermod -aG docker $USER
```
3. Reboot for the change to take effect:
```
sudo reboot
```

With Docker and Git in place, you are ready to fetch the Rocket.Chat configuration files.

Step 2: Clone the official Rocket.Chat configuration repository

The official rocketchat-compose repository contains all the configuration files you need to successfully deploy Rocket.Chat using Docker Compose.

Clone the repository using Git and navigate to the cloned directory:
```
git clone --depth 1 https://github.com/RocketChat/rocketchat-compose.git
cd rocketchat-compose
```
This repository includes:
1. compose.yml : The main configuration file for Docker Compose to deploy Rocket.Chat.
2. .env.example : An example enviroment file for customizing your deployment.
3. Additional configs: Other configuration files to support your deployment, such as database, Traefik (for reverse proxy and HTTPS) and monitoring tools.

Avoid editing these compose files directly. All deployment configuration can be managed through a single .env, which you’ll create in the next step.

Step 3: Configure Rocket.Chat

All deployment configurations like version, domain, reverse proxy, monitoring credentials can be controlled through variables in a .env file.

Start by copying the provided example file:
```
cp .env.example .env
```
This command creates the .env file where you can now define your deployment variables, such as the desired Rocket.Chat version and your workspace URL.
Open the file for editing:
```
nano .env
```

Work through the configuration sections below before saving. Each section covers a distinct area of your deployment.

3a. Set Rocket.Chat version

Locate the RELEASE variable and set it to exact version of Rocket.Chat you wish to deploy. A full list of available stable releases is on the Rocket.Chat releases page.

RELEASE=7.5.0

For production environments, it’s strongly recommended to specify a fixed version number (e.g., 7.5.0) instead of using latest. This prevents unexpected issues from automatic, breaking updates.

3b. Configure monitoring

The repository includes a ready-to-use observability stack: Prometheus collects metrics, Loki aggregates logs, and Grafana provides a dashboard for visualizing both. This setup allows you to visualize key metrics, track performance, and gain insights into the health of your Rocket.Chat instance.

You can choose to access Grafana either through a URL path (e.g., https://your-domain.com/grafana) or a subdomain (e.g., https://grafana.your-domain.com).

Grafana via a path

Grafana via a subdomain

This option is ideal for local development or single-domain setups, accessing your Grafana dashboard as a subdirectory (e.g., https://your-domain.com/grafana).

To configure this, follow these steps in the .env file:

You can use the default values for the following variables:
1. GRAFANA_DOMAIN: Leave this variable empty.
2. GRAFANA_PATH: Set this to your desired path, ensuring there is no trailing slash (e.g., /grafana).
```
GRAFANA_DOMAIN=
GRAFANA_PATH=/grafana
```
Set a strong password for the Grafana admin user by updating the GRAFANA_ADMIN_PASSWORD variable:
```
GRAFANA_ADMIN_PASSWORD=your_secure_password
```

After deployment, Grafana will be available at https://your-domain.com/grafana.

Accessing your Grafana dashboard through a dedicated subdomain is the recommended approach for production environments, as it provides a cleaner and more secure access point.

To set this up, follow these steps:

In your DNS settings, create an A record for your desired subdomain (e.g., grafana.your-domain.com) and point it to your server's public IP address.
Configure the following Grafana variables in the .env:
1. GRAFANA_DOMAIN: Set this to the subdomain for accessing the Grafana dashboard. (e.g., grafana.your-domain.com).
2. GRAFANA_PATH: Leave this variable empty.
```
GRAFANA_DOMAIN=grafana.your-domain.com
GRAFANA_PATH=
```
Set a strong password for the Grafana admin user by updating the GRAFANA_ADMIN_PASSWORD variable:
```
GRAFANA_ADMIN_PASSWORD=your_secure_password
```

After deployment, Grafana will be available at https://grafana.your-domain.com .

3c. Configure domain and reverse proxy

Your reverse proxy determines how users access your workspace and whether connections are secured with HTTPS. The repository ships with Traefik as the default and recommended reverse proxy. Nginx can also be used as an alternative for teams that already operate it or have specific infrastructure requirements. Choose one option and follow only that path.

Traefik

Nginx

Traefik integrates directly with Docker and handles TLS certificate provisioning automatically via Let's Encrypt, making it the simpler choice for most deployments.

Local deployment

If you are only testing Rocket.Chat locally on your machine and do not require external access or HTTPS, use the default values for these variables in the .env :

DOMAIN=localhost
ROOT_URL=http://localhost

Your workspace will be accessible at http://localhost:3000 once succesfully deployed.

Production deployment

Before proceeding, verify that your domain's A record (or optional CNAME record) is correctly pointed to the public IP address of the server where you are running Docker. Traefik cannot provision a certificate for a domain it cannot reach.

For a publicly accessible and secure production deployment, update the following variables in your .env file:

Field	Description	Example
DOMAIN	Your public domain. Do not include https:// or any trailing slashes.	example.com
ROOT_URL	The complete URL your users will use to access the server, including the secure protocol (https://).	https://example.com
LETSENCRYPT_ENABLED	Set to `true` to enable Traefik to automatically obtain and renew certificates.	true
LETSENCRYPT_EMAIL	Your valid email address for certificate renewal and security notifications from Let's Encrypt.	demo@email.com
TRAEFIK_PROTOCOL	Set to `https` to ensure secure connections are enforced by the proxy.	https

Here is an example of the configuration:

DOMAIN=example.com
ROOT_URL=https://example.com
LETSENCRYPT_ENABLED=true
LETSENCRYPT_EMAIL=demo@email.com
TRAEFIK_PROTOCOL=https

Once these variables are set, you can proceed to adding optional configurations as required.

With Nginx, Rocket.Chat runs locally on port 3000 and Nginx acts as the public-facing reverse proxy, handling HTTPS and forwarding traffic to the local service. This setup requires a few additional manual steps compared to Traefik.

Before proceeding, verify that your domain's A record (or optional CNAME record) is correctly pointed to the public IP address of the server where you are running Docker.

Step 1: Configure Rocket.Chat to bind to localhost

In your .env file, set the following default values to ensure Rocket.Chat runs locally so that Nginx can proxy requests to it:
```
DOMAIN=localhost
ROOT_URL=http://localhost
LETSENCRYPT_ENABLED=false
LETSENCRYPT_EMAIL=demo@email.com
TRAEFIK_PROTOCOL=http
```
Save the .env changes.

Step 2: Obtain a TLS certificate from Let's Encrypt

Use Let's Encrypt to get a free & open-source TLS certificate by following these steps:

Install Certbot, the Let's Encrypt certificate client.
For Debian-based distributions such as Debian and Ubuntu use :
```
sudo apt update
sudo apt install certbot
```
For RPM-based distributions such as Redhat and Centos, use:
```
sudo yum install yum-utils
sudo yum install certbot
```
Installation commands may vary depending on your Linux distribution and version.
Request a certificate for your domain from Let's Encrypt with this command:
```
sudo certbot certonly --standalone --email <emailaddress@email.com> -d <domain.com> -d <subdomain.com>
```
1. Replace <emailaddress@email.com> and <domain.com> with your actual email adress and domain name for Rocket.Chat.
2. If you’re configuring Grafana via subdomain, replace <subdomain.com> with the Grafana subdomain (e.g., grafana.your-domain.com), otherwise remove it.
If successful, your certificate files will be stored in /etc/letsencrypt/live/<your.domain.com>/. You will reference these paths in the Nginx configuration below.

Step 3: Install and configure Nginx

Now, link your domain to the Rocket.Chat service running locally on port 3000. Nginx will serve as the secure public entry point, handling HTTPS traffic on port 443 and directing requests to the local Rocket.Chat and Grafana services.

Install Nginx web server:
```
sudo apt-get install nginx
```

Backup the default config file for reference:

cd /etc/nginx/sites-available
sudo mv default default.reference

Create a new site configuration for Rocket.Chat:
```
sudo nano /etc/nginx/sites-available/default
```

Add your Nginx configuration to the file: The configuration you choose depends on how you configured Grafana during monitoring.

If Grafana is configured via a URL path (e.g., https://your-domain.com/grafana), paste the following into the file:

 server {
     listen 443 ssl;
     server_name <ABC.DOMAIN.COM>; 
     ssl_certificate /etc/letsencrypt/live/<ABC.DOMAIN.COM>/fullchain.pem; 
     ssl_certificate_key /etc/letsencrypt/live/<ABC.DOMAIN.COM>/privkey.pem; 
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
     ssl_prefer_server_ciphers on;
     ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
     root /usr/share/nginx/html;
     index index.html index.htm;
     # Make site accessible from http://localhost/
     server_name localhost;
     location / {
         proxy_pass http://localhost:3000/;
         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "upgrade";
         proxy_set_header Host $http_host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto http;
         proxy_set_header X-Nginx-Proxy true;
         proxy_redirect off;
     }
     # Grafana Reverse Proxy 
    location /grafana {
        proxy_pass http://localhost:5050/grafana;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https; # Crucial for secure path access
        proxy_set_header X-Nginx-Proxy true;
        proxy_redirect off;
    } 
 }
 server {
     listen 80;
     server_name <ABC.DOMAIN.COM>; 
     return 301 https://$host$request_uri;
 }

Replace <ABC.DOMAIN.COM> with your domain name.

If Grafana is configured via a subdomain (e.g., https://grafana.your-domain.com), paste the following into the file:

 server {
     listen 443 ssl;
     server_name <ABC.DOMAIN.COM>; 
     ssl_certificate /etc/letsencrypt/live/<ABC.DOMAIN.COM>/fullchain.pem; 
     ssl_certificate_key /etc/letsencrypt/live/<ABC.DOMAIN.COM>/privkey.pem; 
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
     ssl_prefer_server_ciphers on;
     ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
     root /usr/share/nginx/html;
     index index.html index.htm;
     # Make site accessible from http://localhost/
     server_name localhost;
     location / {
         proxy_pass http://localhost:3000/;
         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "upgrade";
         proxy_set_header Host $http_host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto http;
         proxy_set_header X-Nginx-Proxy true;
         proxy_redirect off;
     }
 }

server {
    listen 443 ssl;
    server_name <GRAFANA.ABC.DOMAIN.COM>; 

     ssl_certificate /etc/letsencrypt/live/<ABC.DOMAIN.COM>/fullchain.pem;
     ssl_certificate_key /etc/letsencrypt/live/<ABC.DOMAIN.COM>/privkey.pem;

    location / {
        proxy_pass http://localhost:5050/; # Note the change here (no /grafana suffix)
        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-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
 
}

server {
     listen 80;
     server_name <ABC.DOMAIN.COM>; 
     return 301 https://$host$request_uri;
 }

Replace <ABC.DOMAIN.COM> with your domain name.
Replace <GRAFANA.ABC.DOMAIN.COM> with your Grafana subdomain name.

Validate the configuration for syntax errors before continuing:
```
sudo nginx -t
```
A message saying “syntax is ok” and “test is successful” confirms the configuration is valid. Do not restart Nginx yet, you’ll do that after the Rocket.Chat deployment is running in step 4.
If you have security group restrictions, allow TCP/22 from your current IP for SSH connections and TCP/443 from the IP you plan to use for access.

3d. Optional configurations

Here are some additional configurations that are not required to launch but may be relevant depending on your infrastructure. You can add them to your .env file before launching Rocket.Chat:

External MongoDB connection: By default, the stack provisions a MongoDB container automatically. If you prefer to connect to an existing MongoDB instance such as a managed service like MongoDB Atlas or a separately hosted replica set), configure the MONGO_URL in the .env file like this:
```
MONGO_URL=mongodb://<user>:<pass>@host1:27017,host2:27017,host3:27017/<databaseName>?replicaSet=<replicaSet>&ssl=true&authSource=admin
```
For production, MongoDB must be deployed separately (non-containerized) and configured as a replica set.
Registration token: If you’ve received a registration token from our Sales team or Rocket.Chat Cloud, you can use it to automatically register your workspace upon initial startup. To do this, add the token to the .env file like this:
```
REG_TOKEN=your_token_here
```
This step is optional, as you can also register the workspace through the setup wizard UI after deployment. Once the server successfully starts and registration is complete, the token is permanently stored in the database's cloud settings and is no longer required in the .env file. For security reasons, remove the token from your .env file after the first successful deployment.

Step 4: Launch the Rocket.Chat deployment

With your .env file saved, start the deployment following the instructions that corresponds to the reverse proxy you configured in Step 3:

Traefik

Nginx

Run the following command to download the all required Docker images (Rocket.Chat, MongoDB, Traefik, etc.) and start the containers in the background:
```
docker compose -f compose.database.yml -f compose.monitoring.yml -f compose.traefik.yml -f compose.yml -f docker.yml up -d
```
Here’s a brief summary of what each file in the command does:
1. compose.yml: Starts the Rocket.Chat application.
2. compose.database.yml: Manages MongoDB, the database that Rocket.Chat relies on. It also includes NATS, an internal message broker used for communication between services.
3. compose.monitoring.yml: Enables monitoring with Prometheus (for collecting metrics), Loki (for collecting logs), and Grafana (for visualizing them in dashboards).
4. compose.traefik.yml: Manages the Traefik reverse proxy, which handles secure routing and automatic HTTPS certificate generation from Let's Encrypt.

Navigate back to the cloned Rocket.Chat directory where you have the compose files.
Download the required Docker images and start your Rocket.Chat services, explicitly omitting the Traefik configuration file (compose.traefik.yml):
```
docker compose -f compose.database.yml -f compose.monitoring.yml -f compose.yml -f docker.yml up -d
```
Here’s a brief summary of what each file in the command does:
1. compose.yml: Starts the Rocket.Chat application.
2. compose.database.yml: Manages MongoDB, the database that Rocket.Chat relies on. It also includes NATS, an internal message broker used for communication between services.
3. compose.monitoring.yml: Enables monitoring with Prometheus (for collecting metrics), Loki (for logs collection), and Grafana (for visualizing them in dashboards).
Once the containers are up, restart Nginx to begin proxying traffic to Rocket.Chat:
```
sudo systemctl restart nginx
```

You can easily customize your deployment by including only the services you need. For example, if you did not configure monitoring or Traefik , you can omit those .yml files:

docker compose -f compose.database.yml -f compose.yml up -d

To check that all services have successfully started, use this command to list all running containers:

docker ps -a

All services should show a status of Up . Some minor MongoDB services may also have a status of Exited (0).

If you encounter issues during deployment, refer to the following resources for logging and troubleshooting:

Step 5: Access your Rocket.Chat workspace

Once your Rocket.Chat instance is deployed, you can access the workspace through your web browser to begin your final configuration:

For local deployment: Go to http://localhost:3000.
For production: Navigate to the domain you configured.

On first load, a setup wizard prompts you to create your first admin user and complete the initial workspace setup. Your workspace and email will be registered to the Rocket.Chat Cloud portal during this process.

Access monitoring dashboard

You can access the Grafana dashboard via the URL corresponding to your configured access method:

Via path: https://your-domain.com/grafana
Via subdomain: https://grafana.your-domain.com

User: admin
Password: The password you set in the GRAFANA_ADMIN_PASSWORD variable in your .env file.
The GRAFANA_ADMIN_PASSWORD you set in the .env file is only applied once during the first setup of the container. To update your password later, you must change it directly within your Grafana user preferences.

For more details on how to monitor your workspace metrics and logs, refer to the Monitor Workspace Logs and Metrics guide.

Step 6: Update file storage

Rocket.Chat stores file uploads using GridFS by default. While this doesn't require extra setup, it's not ideal for production because it increases database load and reduces scalability performance. Rocket.Chat highly recommends using a dedicated object storage service such as Amazon S3, Google Cloud Storage (GCS), or MinIO. Refer to the File Uploads guide for detailed instructions on configuring your preferred file storage solution.

Next steps

Great! You’ve successfully created your Rocket.Chat workspace with Docker and logged in. Next, explore the following resources to continue using your new workspace:

User Guides: Learn the basics of your Rocket.Chat account, the types of rooms, and how to communicate with your workspace users.
Workspace Administration: Administrators and owners can set and manage various configurations.
Marketplace: Explore the available apps to enhance your workspace.

Update Rocket.Chat on Docker

Updating the Rocket.Chat image will not affect your data, as it is stored persistently in the separate MongoDB service. Before you proceed, consult the general guidelines for updating MongoDB.

To update your Rocket.Chat version:

Modify the RELEASE variable in the .env file to point to the release tag of new version:
```
RELEASE=<desired version>
```
For example, RELEASE=8.2.0 .
Run the following command to pull the new image and restart the Rocket.Chat container:
```
docker compose -f compose.yml up -d
```
Refer to the official documentation for more details on Rocket.Chat Docker images.
After a few minutes, check that the new container is running:
```
docker ps
```
You should see a new Rocket.Chat container running with the updated version tag.
Return to your workspace Subscription to verify the updated Rocket.Chat version.

Update MongoDB on Docker

If you’re using the built in Bitnami MongoDB images, refer to this forum post to upgrade to the official MongoDB 8.2 image required for Rocket.Chat 8.0.

Upgrading or downgrading your MongoDB instance may be required when moving between major Rocket.Chat releases. Your Rocket.Chat workspace stores its data in a dedicated MongoDB service. Updating the Rocket.Chat container does not modify your stored data, as long as the MongoDB volume remains intact.

This section explains how to safely change your MongoDB version for Rocket.Chat in Docker, whether you are upgrading to a newer release or downgrading to an earlier one.

Upgrade MongoDB

Downgrade MongoDB

Before you proceed, consult the general guidelines for updating Rocket.Chat.

If you are moving to a higher MongoDB version, follow the steps below:

Ensure that the MongoDB image for the target version is available on Docker Hub under mongodb-community-server. Look for an image tagged <version>-ubi8 .
Set or modify the MONGODB_VERSION variable in the .env file to point to your desired MongoDB version.
```
MONGODB_VERSION=<version>
```
For example, MONGODB_VERSION=8.2 .
Run the following command to pull the new image and restart the MongoDB container:
```
docker compose -f  compose.database.yml up -d
```
Refer to the official documentation for more details on Rocket.Chat Docker images.
After a few minutes, check that the new container is running:
```
docker ps
```
You should see a new MongoDB container running with the updated version tag.

MongoDB does not support direct binary downgrades if the data files were created by a newer version. To safely downgrade, you must first lower the Feature Compatibility Version (FCV) before changing the MongoDB image. Failing to set the FCV before switching binaries before upgrading will cause MongoDB to exit with an error and the container will repeatedly restart.

Before you proceed, ensure that the MongoDB image for the targeted version is available on Docker Hub under mongodb-community-server. Look for an image tagged <version>-ubi8 .

To downgrade your MongoDB version in Rocket.Chat, continue with these steps:

Before making any changes, create a full database backup:
```
docker exec <mongo-container_name> sh -c 'mongodump --archive' > db.dump
```
Replace <mongo-container_name> with the current name of the MongoDB container.

Enter the MongoDB container:

docker exec -it  <mongo-container_name> bash

Access the MongoDB shell:
```
mongosh
```
Once in the shell, switch to the database:
```
use rocketchat
```
Check the current Feature Compatibility Version:
```
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
```
The returned version should match your current MongoDB binary (for example, 8.2).

Set the FCV to the version you intend to downgrade to:

db.adminCommand({
  setFeatureCompatibilityVersion: "<version>",
  confirm: true
})

Confirm that the FCV now matches the target version:

db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

Exit the mongo shell and shut down the MongoDB container:
```
docker compose -f compose.database.yml down
```
Set or modify the MONGODB_VERSION variable in the .env file to point to your desired MongoDB version:
```
MONGODB_VERSION=<version>
```
For example, MONGODB_VERSION=8.0 .

Then, pull and start the database container:

docker compose -f  compose.database.yml up -d

After a few minutes, confirm that the new MongoDB container is running:
```
docker ps
```
A new MongoDB container is now running with the updated version tag.
You can also double-check the MongoDb version in the container with this command:
```
docker exec -it <mongo-container_name> mongosh --eval "db.version()"
```

Set Rocket.Chat deployment environment variable on Docker

Enviroment variables are additional settings that impacts your workspace deployment and configuration. Refer to the official documentation to learn more about Rocket.Chat deployment enviroment variables.

To set up an environment variable in Docker,

Open your compose.yml file:
```
nano compose.yml
```
Add the environment variable under the environment section of the rocketchat service. For example, to override the SMTP Host setting, add:
```
services:
  rocketchat:
    ...
    environment:
      ...
      OVERWRITE_SETTING_SMTP_Host: "my.smtp.server.com"
```
Tip: This is the same section where ROOT_URL, MONGO_URL, etc is defined.

Restart your Rocket.Chat container to apply the changes:

docker compose stop rocketchat
docker compose rm rocketchat
docker compose up -d rocketchat

For a full list of available environment variables, refer to Deployment Environment Variables.

Additional operations

Back up and restore MongoDB data on Docker

Rocket.Chat stores all workspace data in MongoDB. Follow the steps in the commands below to back up and restore your database when running in Docker.

Back up your MongoDB database on Docker

List all running Docker containers to find the name of your MongoDB service
```
docker ps -a
```
Take note of your mongo container name (e.g., rocketchat-mongodb-1 )
Run this command to dump the database into a binary file db.dump :
```
docker exec <container_name> sh -c 'mongodump --archive' > db.dump
```
When successful, you should see db.dump file in the current directory.

Restore MongoDB database backup on Docker

To restore the data, use mongorestore inside the MongoDB container, piping the data from your local db.dump file.

docker exec -i <container_name> sh -c 'mongorestore --archive' < db.dump

Export to an external database (e.g., MongoDB Atlas)

If you are migrating your data or performing an offline restore, you can use the local db.dump file directly with an external MongoDB connection string.

mongorestore --uri mongodb+srv://<user>:<password>@cluster0.w2btl.mongodb.net --archive=db.dump

Rocket.Chat Docker images

Rocket.Chat provides an official Docker image repository maintained by the Rocket.Chat team. When setting up your deployment, you specify which Rocket.Chat version to use by adding the image tag.

The base image path is: registry.rocket.chat/rocketchat/rocket.chat:<tag> .

Here are the available image tags:

Specific release tags (recommended for production): You can lock your workspace to a specific Rocket.Chat version using a fixed version tag. This is the best practice for production environments because it prevents unexpected major updates and ensures you only upgrade when you are ready to perform backups and check database compatibility. For example, registry.rocket.chat/rocketchat/rocket.chat:6.6.0 . Check out the release notes or Docker hub tags for the various Rocket.Chat releases.
Latest tag: The latest tag points to the most recent Rocket.Chat build available in the registry. This may include recent changes and is useful for testing newer versions. Using this tag for production deployments is not recommended.
Develop build: The develop tag tracks the develop branch and includes the newest, untested changes. This tag is intended for development and experimentation only and should not be used in production.

Monitoring and logging your deployment

Effective logging helps you monitor the health and status of your Rocket.Chat deployment. This section covers logging for Rocket.Chat, MongoDB, and reverse proxies like Traefik or Nginx.

To check the status and logs of your containers, follow these steps:

Use one of the following commands to view containers in your Docker environment:

docker ps        # Shows currently running containers with details like ID, status, and ports  
docker ps -a     # Lists all containers, including stopped ones  
docker compose ps  # Lists services managed by Docker Compose

These commands help you identify the containers running Rocket.Chat, MongoDB, Traefik, and related services.

Once you identify the relevant container or service, use one of the following commands to inspect logs:
```
docker compose logs -f <service_name>  # Shows realtime logs for a service managed by Docker Compose  
docker logs <container_name>       # Displays logs for the specific container  
docker logs -f <container_name>    # Shows real-time logs for a container
docker logs --tail 10 <container_name> # Displays the last 10 lines of logs  
```
- Replace <container_name> and <service_name> with the appropriate values.
- Rocket.Chat logs to stdout, so there isn't a specific log file within the container. The Docker logging system captures these stdout logs, making them accessible through the docker logs command
To inspect MongoDB’s health, run:
```
docker exec -it <mongodb_container_name> mongosh --eval "db.runCommand({ serverStatus: 1 })"
```
This command returns detailed MongoDB server status information.
Replace <mongodb_container_name> with your MongoDB container name.

If using Nginx as a reverse proxy, logs are stored inside the container at /var/log/nginx/. To view logs, run:

sudo tail -f /var/log/nginx/access.log  # Access logs  
sudo tail -f /var/log/nginx/error.log   # Error logs

Encountering issues with your deployment? See the Deployment FAQ for detailed troubleshooting assistance.

Congratulations on successfully deploying Rocket.Chat using Docker! You can now effortlessly communicate with your team members in your workspace. Visit the accessing your workspace guide to configure your workspace and onboard other team members.

Deploy with Docker &amp; Docker Compose