Syncthing Docker: Persistent Volumes, Ports, Permissions, and Safe Remote Access

A reliable Syncthing container needs persistent configuration and data mounts, matching host permissions, discovery and transfer ports, and a web interface that is not exposed without authentication.

The container is disposable; the device identity, database, and synchronized folders are not. Design the mounts before pairing another device.

Table of contents

• Separate configuration from synchronized data
• Run a Compose service
• Match UID, GID, and filesystem permissions
• Configure networking and remote access
• Upgrade and monitor safely
• How this fits the rest of the stack
• FAQ

Separate configuration from synchronized data

Mount the image’s documented configuration path to durable storage so the device certificate, identity, index, and settings survive replacement. Mount each synchronized host directory explicitly. If either path remains inside the writable container layer, recreating the container can create a new device or lose unsynchronized data.

Back up configuration and critical data independently. Synchronization propagates deletions and corruption; it is not a versioned backup by itself. Enable file versioning where appropriate and test recovery from an offline backup.

Run a Compose service

services:
  syncthing:
    image: syncthing/syncthing:latest
    container_name: syncthing
    restart: unless-stopped
    ports:
      - '8384:8384'
      - '22000:22000/tcp'
      - '22000:22000/udp'
      - '21027:21027/udp'
    volumes:
      - /srv/syncthing/config:/var/syncthing/config
      - /srv/sync:/var/syncthing/data

Confirm mount paths and environment variables against the selected image because community images use different layouts. Pin a tested version for important installations and review release notes before upgrading rather than treating latest as a maintenance plan.

Match UID, GID, and filesystem permissions

The process inside the container writes as a numeric UID and GID. Ensure mounted host directories are owned or ACL-enabled for those IDs. Matching a username is irrelevant when the numbers differ. Avoid chmod 777; it grants broad access and still may not fix parent-directory or network-filesystem rules.

docker exec syncthing id
stat -c '%u:%g %a %n' /srv/sync
docker logs syncthing

On SELinux systems, apply the documented volume label. On network storage, confirm locking, permissions, and consistency behavior before trusting large sync sets.

Configure networking and remote access

Port 8384 serves the management GUI, 22000 handles sync traffic, and 21027 supports local discovery in common configurations. Host networking can simplify discovery but broadens network exposure. Published ports provide clearer boundaries but may require explicit discovery addresses.

Set a strong GUI password and TLS, bind management to a trusted interface, or place it behind an authenticated private proxy. Do not publish the admin interface directly to the internet merely because the port mapping works. Restrict firewall rules to intended networks.

Upgrade and monitor safely

1. Confirm all folders are healthy and fully synced
2. Back up configuration and device identity
3. Pull the tested image version
4. Recreate the container without deleting mounts
5. Verify device ID, folders, and permissions
6. Check logs and health endpoint
7. Retain the prior image for rollback

Monitor out-of-sync bytes, scan errors, connection state, disk space, and container restarts. A green container status does not mean every folder is synchronized. Alert on the application state, not only the process.

Plan for conflicts and partial connectivity before the first large sync. Decide which folders are send-only, receive-only, or bidirectional, and document which device is authoritative. Ignore patterns belong in version-controlled operational documentation even if the live file remains beside the data. For large initial transfers, verify free space on both sides and avoid introducing millions of files without watching index memory and scan duration. Database and media directories may not be safe to copy while applications are writing them; synchronize application-aware backups instead of live internal files. If remote discovery is disabled for privacy, configure explicit device addresses and verify relay expectations. Rotate GUI and API credentials after an exposure, review connected device IDs, and remove devices that no longer belong to the trust group. Encryption protects transport, but an approved peer still receives the folder content, so device approval is the core security boundary.

How this fits the rest of the stack

Self-hosted synchronization consumes storage, bandwidth, and operational time. The RunxBuild hosting calculator helps compare those line items, and the RunxBuild dashboard keeps managed service deployment and logs in one place.

Useful related references:

• Installation of Docker in Ubuntu: Step-by-Step for 22.04 and 24.04
• How to Install Docker on Ubuntu: 2026 Guide (22.04 and 24.04)
• Deploy a Docker Container for Free
• Docker services on RunxBuild

FAQ

What must be persistent in a Syncthing container?

Persist the documented configuration path and every synchronized data directory. The configuration contains device identity and index state.

Which ports does Syncthing use?

Common defaults are 8384 for the GUI, 22000 TCP and UDP for transfers, and 21027 UDP for local discovery.

Why can the container not write to my folder?

The container process UID or GID does not have permission on the host mount. Compare numeric identities and use ownership or ACLs.

Is Syncthing a backup?

Not by itself. It propagates changes and deletions. Keep independent versioned backups and test restore.

Should I expose the GUI publicly?

No. Protect it with authentication and TLS and restrict it to a trusted network or private proxy.