Migrating Matomo from Synology DiskStation to a dedicated docker server

After running Matomo on a few Synology DiskStations (currently a DS1621+) since 2022, I made the move. A new server (Minisforum UM890 Pro) with a clean Docker setup, the way it should have been from the start, but hey, when things work they work right?

This post documents exactly how I did it, step by step, so you can do it too.

Why migrate?

Running Matomo on a Synology DiskStation via Docker works surprisingly well for small setups, but it comes with real limitations. The NAS is shared infrastructure, disk I/O contention with backups and file serving can cause Matomo to stall mid-tracking. The DSM container management UI is limited compared to a full Docker environment, and updates require jumping through hoops.

Moving Matomo to a dedicated server gives you proper resource allocation, easier CLI access and standard Docker Compose workflows. Let’s walk through the whole process.

Before & after

Before: Internet → Synology DSM Reverse Proxy → Matomo Container (DSM Docker) → MariaDB Container (DSM Docker)

After: Internet → Synology DSM Reverse Proxy → Matomo Container (New Server) → MariaDB Container (New Server)

Prerequisites

• New server with Docker and Docker Compose installed (Ubuntu 22.04+ recommended)
• SSH access to both the Synology NAS and the new server
• Your Synology admin credentials
• Enough disk space on the new server for your Matomo data

⚠ Do this during low-traffic hours. Between the database export and DNS propagation, you will have a brief window where tracking data may be missed.

Step 1: Export the database from DiskStation

SSH into your Synology NAS and dump the Matomo database. First find the MariaDB container name in DSM, or use docker ps:

# On the Synology NAS via SSH
ssh admin@your-nas-ip

# List running containers to find your DB container name
sudo docker ps --format "table {{.Names}}\t{{.Image}}"

Once you have the container name (e.g. matomo_db), dump the database:

# Export the Matomo database
sudo docker exec Matomo-DB \
  sh -c 'mariadb-dump \
  -u root 
  -pYOURPASSWORD \
  matomodb' 
  > /volume1/docker/matomo-backup.sql

# Verify it's not empty
wc -l /volume1/docker/matomo-backup.sql

The -p flag takes the password without a space. You can find your credentials in the Matomo config/config.ini.php file on the NAS volume.

Step 2: Copy Matomo data files

You also need to copy Matomo’s data directory, which contains custom plugins, logo overrides, and GeoIP databases. Find the volume mount path in DSM under Container Manager → your Matomo container → Volume settings. It’s typically something like /volume1/docker/matomo. I did this with SFTP, but you can use SCP or Rclone if you want.

# From your new server, pull the files
sftp admin@your-nas-ip
get -r docker/matomo /home/username/matomo-data

Step 3: Copy the database dump to the new server

# From your new server
sftp admin@your-nas-ip
get docker/matomo-backup.sql /home/user/matomo-backup.sql

Step 4 — Set up Docker compose on the new server

mkdir -p /opt/matomo/{data,db}
cd /opt/matomo

# /opt/matomo/docker-compose.yml
services:
  matomo-db:
    image: mariadb:11.4
    container_name: matomo-db
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: yourrootpassword
      MYSQL_DATABASE: matomo
      MYSQL_USER: matomo
      MYSQL_PASSWORD: yourpassword
    volumes:
      - ./db:/var/lib/mysql

  matomo:
    image: matomo:5.8.0
    container_name: matomo
    restart: always
    ports:
      - '8081:80'
    environment:
      MATOMO_DATABASE_HOST: matomo-db
      MATOMO_DATABASE_DBNAME: matomo
      MATOMO_DATABASE_USERNAME: matomo
      MATOMO_DATABASE_PASSWORD: yourpassword
    volumes:
      - ./data:/var/www/html
    depends_on:
      - matomo-db

Step 5: Start containers and restore data

# Start  them all
docker compose up -d

docker exec -i matomo-db mariadb \
  -u matomo -pYOURPASSWORD \
  matomo < /home/user/matomo-backup.sql

Copy your Matomo files into the data volume:

# Wait for the matomo container to write its initial files
sudo cp -r /home/user/matomo-data/* /opt/docker/matomo/data/

# Fix permissions
sudo chown -R www-data:www-data /opt/docker/matomo/data/

# Restart container
docker restart matomo

Step 6: Verify Matomo works

Before touching the reverse proxy, confirm Matomo is healthy by hitting it directly on port 8081:

# From your local machine
curl -I http://new-server-ip:8081

# Should return HTTP 200

Also log in to http://new-server-ip:8081 in a browser and verify your historical data is present in the dashboard.

Step 7: Update the reverse proxy

You have two reverse proxy situations to handle: removing Matomo from the Synology reverse proxy, and adding it to whatever is fronting your new server.

Remove from Synology DSM reverse proxy

Go to DSM → Control Panel → Login Portal → Advanced → Reverse Proxy. Find the rule pointing to your Matomo container and edit it so that the Destination hostname has the new IP or hostname of the new server, and the correct port. Click Save and you’re good to go.

Make sure Matomo’s config.ini.php has trusted_hosts[] = "analytics.example.com". If it doesn’t, Matomo will show a host mismatch error after the proxy switches over.

Step 9: Stop the containers on the DiskStation

With everything running smoothly on the new server, it’s time to wind down the old setup on the NAS. For now, we’ll stop the containers but not delete them yet, give it a week of stable running before you clean up completely.

Open DSM → Container Manager → Containers, select each of the Matomo containers one by one (matomo_app, matomo_db), and click Stop from the Action menu.

That’s it for now. Leave the containers and their volumes in place. If something unexpected surfaces in the next week, a config file you forgot to copy, a plugin that didn’t make it across, you still have a full working fallback right there on the NAS.

After a week, once you’re confident the migration is solid, come back and clean up properly. In Container Manager, select each stopped container and choose Delete. Then head to Container Manager → Images and remove the matomo and mariadb images. Finally, delete the old data folder (typically /volume1/docker/matomo) via File Station.

⚠ Don’t delete matomo_dump.sql from the NAS until you’re confident the new server has been running stable for a week or more.

Step 10: Post-migration checks

• Tracking pixel loads: visit https://analytics.example.com/matomo.js
• Historical data visible in Matomo dashboard
• New visits appearing in real-time report
• SSL certificate issued and auto-renewing
• Matomo cron job running on the new server
• Old containers and images removed from Synology NAS

Conclusion

Migrating Matomo off the NAS turned out to be less painful than expected, and the result is a much cleaner and faster setup. Matomo now has dedicated resources and a proper Docker Compose stack that’s easy to update and maintain.

The Synology can get back to what it does best: storing files, running backups, and not quietly throttling analytics in the background.

If you followed along and ran into anything unexpected, drop a comment below. Chances are someone else hit the same thing.

Photo by Elevate.

Share on Mastodon