A laptop at home and a workstation elsewhere are not always online together. An always-on Syncthing device can bridge that gap: one computer uploads its changes, then the other receives them later. The VPS must store the shared files; it is not simply a forwarding proxy.
This tutorial is for Ubuntu or Debian with Docker Engine and the Compose plugin already installed. If you need that foundation, start with our Docker installation guide and SSH key setup guide. The examples assume a Linux Docker host and a sudo-capable account.
1. Plan the storage and access model
For a small personal trial, a VPS with roughly two CPU cores and 2 GB RAM is a reasonable starting point, not a guaranteed sizing rule. Large file counts, initial indexing and frequent changes can require more resources. Measure your own workload before choosing a production plan.
Allow space for the full dataset, temporary transfers, retained versions and growth. A 100 GB collection should not be placed on a nearly full 100 GB disk. Do not point your first share at an entire home directory containing credentials, application databases or caches.
| Requirement | Practical choice |
|---|---|
| Modest folders and an existing server | Cloud VPS with enough local storage and headroom. |
| A large always-on copy | Storage VPS, with the data directory on the intended data disk. |
| Public file links and browser collaboration | Consider a file-sharing application such as Nextcloud instead. |
| Historical recovery after a bad deletion | Independent backups, not just another synchronised copy. |
With ordinary Syncthing folders, the receiving server holds readable files. Decide whether that meets your privacy requirements before uploading sensitive data. Syncthing also documents an untrusted-device encryption mode, currently labelled beta/testing in its documentation; that is a different design from this standard receiving device.
2. Prepare persistent directories
Connect to the VPS and check Docker first:
docker version
docker compose version
df -hTUse sudo docker throughout if your account requires it. Docker access is highly privileged; do not give untrusted users Docker-group membership just to avoid typing sudo.
The following example creates a new, dedicated directory. If /srv/syncthing already contains another installation, stop and inspect it rather than reusing it blindly:
sudo mkdir -p /srv/syncthing/data
sudo chown 1000:1000 /srv/syncthing/data
sudo chmod 750 /srv/syncthing/data
cd /srv/syncthingThe official container supports PUID and PGID; this example deliberately uses 1000 for both. Check that this ownership is appropriate for your host. It grants that numeric user access to the files. Change the directory ownership and Compose values together if you choose another dedicated identity.
On a Storage VPS, confirm findmnt -T /srv/syncthing/data resolves to the disk you intend to use. If the data disk is mounted elsewhere, use a new directory on that filesystem and change the bind mount below. Do not start a large sync onto the boot disk by accident.
3. Create the Docker Compose configuration
Use sudoedit /srv/syncthing/compose.yaml to create this file:
services:
syncthing:
image: syncthing/syncthing:latest
hostname: hye-sync
network_mode: host
environment:
PUID: "1000"
PGID: "1000"
STGUIADDRESS: "127.0.0.1:8384"
volumes:
- /srv/syncthing/data:/var/syncthing
restart: unless-stopped
logging:
driver: local
options:
max-size: "10m"
max-file: "3"This follows the official image's Linux host-network approach and persistent /var/syncthing directory, with an explicit loopback-only GUI address. There is no Docker ports: section because host networking uses the host's interfaces directly. See the project's Docker instructions.
Do not remove the GUI address setting: the image's usual GUI default is broader than this example. If port 8384 or 22000 is already occupied, resolve the conflict before starting another instance. Avoid mounting the Docker socket or unrelated host directories into this container.
Pull, record and pin the image
cd /srv/syncthing
docker compose config --quiet
docker compose pull
docker image inspect syncthing/syncthing:latest --format '{{index .RepoDigests 0}}'The last command prints an immutable image reference such as syncthing/syncthing@sha256:.... Copy the complete real value into the image: line before deploying, replacing syncthing/syncthing:latest. Do not paste the ellipsis. This gives you a recorded version to test and upgrade deliberately rather than silently changing releases on a later pull.
docker compose config --quiet
docker compose up -d
docker compose ps
docker compose logs --tail=80 syncthingIf startup fails, read the logs for ownership, path or port errors. Do not “fix” access problems with chmod 777. Check which UID owns the mounted directory and whether the backing filesystem supports the required permissions.
4. Allow sync traffic, keep administration private
Syncthing separates the file-transfer listener from the web interface. The relevant defaults are documented in its firewall guide:
- TCP 22000: direct synchronisation.
- UDP 22000: QUIC synchronisation.
- UDP 21027: local discovery; not a reason to open a public VPS firewall to the whole internet.
- TCP 8384: administration; keep it private.
If UFW is already enabled and is the firewall you manage, the public-sync example is:
sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp
sudo ufw status verboseDo not enable or reset a firewall blindly over SSH. Preserve your actual SSH access rule, and apply equivalent allowances to any upstream firewall. Restrict sync to trusted source addresses where practical; roaming devices may need a VPN or a broader listener. Check IPv4 and IPv6 policy separately.
In this host-network setup, host firewall rules apply directly to the listeners. If you later switch to bridge networking with published ports, revisit our Docker and UFW guide instead of assuming the same rules protect it.
sudo ss -lntup | grep -E ':(8384|22000)\b'Check that 8384 listens on 127.0.0.1, not 0.0.0.0 or a public IPv6 address. Verify from another machine that the VPS's public address does not expose the dashboard.
5. Open the web interface through SSH
Run this on your own computer, substituting your VPS username and address:
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:18384:127.0.0.1:8384 admin@SERVER_IPLeave that terminal running and open http://127.0.0.1:18384 in your local browser. Port 18384 avoids colliding with a local Syncthing installation's usual 8384. If SSH uses a custom port or identity file, add your usual -p or -i option.
Set a strong GUI username and password in Syncthing's GUI settings as an extra layer of protection. Do not change its listen address to make remote browsing easier. The SSH tunnel already carries this traffic over an encrypted connection. Closing the tunnel stops browser access; it does not stop background file synchronisation.
6. Pair a computer and share a test folder
Install Syncthing on your laptop or desktop using the project's download options. Open each device's interface and find its Device ID under Actions → Show ID. Verify that you are pairing the intended devices.
On a fresh installation, if a Default Folder already covers /var/syncthing/Sync, remove that unused folder entry from the VPS interface before adding the test share below. Do not delete its files. Avoid nested shares; on an existing installation, choose a separate non-overlapping directory instead.
- On the VPS, choose Add Remote Device and enter your computer's Device ID.
- On the computer, add or accept the VPS's Device ID.
- Create a new test folder on the computer with a few disposable files.
- Share that folder with the VPS.
- Accept the share on the VPS and choose
/var/syncthing/Sync/tutorial-testas its folder path. - Wait for both devices to report that the folder is up to date, then verify the files.
The VPS path is the container path: this example places the files under /srv/syncthing/data/Sync/tutorial-test on the host. Keep shared folders below the dedicated Sync directory, not at the root of /var/syncthing, which also contains application state. The official getting-started guide explains device and folder sharing.
If discovery is unreliable, edit the VPS device entry on your computer and set an explicit address such as tcp://SERVER_IP:22000. For IPv6 use brackets: tcp://[YOUR_IPV6_ADDRESS]:22000. If you disable discovery or relays for privacy, plan explicit reachable addresses rather than expecting automatic discovery to keep working.
7. Choose folder behaviour and recovery settings
For a two-way working folder, use Send & Receive. For a VPS mirror that should not publish local edits, consider Receive Only. Neither choice makes incoming deletions harmless. Avoid pressing Override Changes or Revert Local Changes without understanding which version of the files will win. Read the folder-type documentation before changing an established share.
Enable file versioning on the VPS folder, for example Simple File Versioning with a small retained-version count suited to your capacity. Versioning is configured per folder and per device. It can retain files replaced or deleted by changes arriving from another device; it does not generally archive edits made locally on that same device. See Syncthing's versioning guide.
Test recovery with a disposable file: synchronise it, edit it on your computer, wait for the VPS to receive the change, then check that the previous copy appears in the VPS's version history. Test a deletion too. The point is to verify your chosen configuration, not merely tick a checkbox.
8. Maintain and troubleshoot the service
Monitor free space, memory, sync errors and the age of your latest independent backup. A large first scan can be resource-intensive, so test a representative subset before adding a huge library. Schedule initial transfers when they will not disrupt other workloads.
- Device disconnected: verify both Device IDs, firewall paths and the configured address.
- Folder not syncing: confirm it is shared with the correct device and accepted at both ends.
- Permission denied: compare container UID/GID with the mounted path's ownership.
- Slow transfer: inspect whether the connection uses a relay, then check disks, CPU, rate limits and network capacity.
- Folder marker missing: check the underlying mount and files before recreating markers or accepting deletions.
The Syncthing FAQ explains these symptoms, including the protective role of the folder marker. For a capacity incident, use our Linux disk-full troubleshooting guide.
Before upgrades, pause changes and stop the container long enough to take a consistent backup of its persistent state and files. Store that backup outside any synced directory. Record the current image digest, review the target release's migration notes, select the new image reference, then recreate with docker compose up -d and repeat a sync test. An older image may not understand state migrated by a newer one: rollback may require restoring the matching pre-upgrade state, not just changing the tag.
Protect configuration backups because they include device identity and access material. Do not start a restored copy alongside the original instance using the same identity. Test restoration in isolation before reconnecting it to your live devices.
Choosing HYEHOST services for file sync
Cloud VPS is a good place to start for smaller working sets or an existing application server with spare capacity. For an always-on copy measured in terabytes, compare Storage VPS plans and place the dataset on the intended data disk.
Storage Box is a managed storage destination, not a Docker host. It can complement the VPS as a separate backup target through supported tools; our Rclone and Storage Box guide covers an encrypted transfer workflow. Do not call a second live sync copy a retained backup.
If you need browser file access, user accounts and collaboration rather than device-to-device sync, compare our Nextcloud VPS tutorial. Choose the tool around the way people will use their files, not simply because both products move data.
Before adding real data
- Verify the correct disk and enough spare capacity.
- Keep the GUI bound to localhost and confirm it is not public.
- Pair only trusted devices and review each folder's path.
- Test file creation, updates, deletion and version recovery.
- Keep application state out of shared folders.
- Create and restore an independent backup.
- Record the image version and an upgrade procedure.
Frequently asked questions
Do I need a VPS to use Syncthing?
No. Syncthing can synchronise directly between your own devices. An always-on VPS is useful when those devices are rarely online at the same time, because it can hold a copy for later synchronisation.
Is Syncthing a backup service?
No. Syncthing propagates file changes and deletions. File versioning can help recover some previous versions, but you should keep independent backups with retention and tested restores.
Which ports does Syncthing use?
The usual sync ports are TCP 22000 and UDP 22000 for QUIC. UDP 21027 is used for local discovery. The web interface normally uses TCP 8384; this guide keeps it on localhost and accesses it through SSH.
Can I install Syncthing on a HYEHOST Storage Box?
This tutorial requires a VPS where you can run Docker. A managed Storage Box is a separate storage service, not a general-purpose server for installing containers. It can instead hold independent backups made with supported tools.
Does a normal Syncthing VPS copy keep my files encrypted at rest?
Not automatically. Transport encryption does not make the files on a normal receiving VPS unreadable to its administrator. Use an appropriate disk-encryption or separately designed untrusted-device setup if that is a requirement.