How to Self-Host Syncthing on Proxmox LXC — File Sync Guide 2026

If you're paying for Dropbox, Google Drive, or iCloud just to keep files in sync between your machines, Syncthing is the self-hosted alternative you should know about. It syncs files continuously between devices using a peer-to-peer protocol — no central server required, nothing leaves your network unless you want it to, and you own every byte. Here's how I'd deploy it on a Proxmox LXC container for a clean, reliable setup that doesn't eat into your main storage.

What Is Syncthing and Why Run It on Proxmox?

Syncthing is an open-source continuous file synchronization program. Unlike rsync, which you trigger manually, Syncthing watches folders and propagates changes in near real-time across any number of devices you pair together. It uses the Block Exchange Protocol (BEP) over TLS, so all transfers between devices are encrypted in transit even when syncing over the public internet.

What makes it a natural fit for a Proxmox homelab is that you don't need Syncthing to run on every machine simultaneously — you just need it somewhere on your network that's always on, acting as a persistent relay node for your laptop or phone. Your documents folder on your work laptop syncs to the Proxmox LXC the moment you save a file, and your home desktop picks up those changes the moment it comes online. The always-on LXC container is what makes the whole mesh work reliably.

The case for LXC specifically (over a VM or Docker): Syncthing is a single Go binary with minimal dependencies. It doesn't need a full virtual machine, doesn't benefit from Docker networking overhead, and an LXC container brings it online in a couple hundred milliseconds. Per the complete Proxmox LXC self-hosting guide, LXC is the right tool for single-service, nearly stateless workloads like this one — you get strong resource isolation, process namespace separation, and near-zero overhead.

One important caveat upfront: Syncthing is not a backup solution. It syncs changes, including deletions and overwrites. If you delete a file on your laptop, Syncthing will delete it on every connected device. For actual point-in-time backups, pair Syncthing with Proxmox Backup Server or a separate backup strategy. For the sync use case — keeping files consistent and current across devices — it's excellent.

Prerequisites

You'll need a running Proxmox VE 8.x host, root access to the shell, and a network interface configured on your Proxmox node (the default vmbr0 bridge works fine). The LXC container itself is tiny — it idles at under 300 MB RAM and a handful of CPU cycles. The disk space you actually need depends entirely on what you plan to sync, not on Syncthing itself.

I recommend putting your synced data on a bind-mounted directory from the Proxmox host's storage rather than inside the container's root disk. This design means you can delete, rebuild, or upgrade the Syncthing LXC container without touching your data. The container becomes stateless except for its config, which you can back up separately. It's the same pattern I use for every persistent-data service in my homelab.

If you're not already running a reverse proxy, the Traefik section later in this guide is optional — you can access Syncthing's web UI directly by IP. But if you want HTTPS access from outside your LAN, the Traefik reverse proxy on Proxmox LXC guide has everything you need to set that up first.

Step 1 — Create the LXC Container

Log into your Proxmox web UI and navigate to Datacenter → your node → Local storage → CT Templates. Download the latest Ubuntu 22.04 LTS or Debian 12 template if you don't already have it. Then open a root shell on your Proxmox host and run:

pct create 110 local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst   --hostname syncthing   --cores 1   --memory 512   --swap 512   --net0 name=eth0,bridge=vmbr0,ip=dhcp   --storage local-lvm   --rootfs local-lvm:8   --unprivileged 1   --features nesting=1   --start 1

This creates an unprivileged container (CT ID 110 — change to whatever fits your numbering scheme) with 512 MB RAM, 1 core, and an 8 GB root filesystem. That's well above what Syncthing needs. The --unprivileged 1 flag is a security best practice for any container that handles user data.

Now create the data directory on the Proxmox host and add it as a bind mount into the container. This is where your synced files will actually live, separate from the container's root disk:

# Create the directory on the Proxmox host (adjust path to your storage layout)
mkdir -p /mnt/syncthing-data

# Add the bind mount to the container config (replace 110 with your CT ID)
pct set 110 -mp0 /mnt/syncthing-data,mp=/data

# Restart to apply the mount
pct restart 110

Grab the container's IP so you can connect to the web UI later:

pct exec 110 -- ip addr show eth0 | grep "inet "

Step 2 — Install Syncthing from the Official Repository

Enter the container and install Syncthing from the official APT repository. Using the official repo (rather than the Ubuntu/Debian default package) ensures you get the current stable release. The Ubuntu default package can lag several minor versions behind, which matters for performance improvements and security patches:

pct enter 110

# Update and install prerequisites
apt-get update && apt-get install -y curl apt-transport-https gnupg2

# Add the Syncthing GPG key
curl -s https://syncthing.net/release-key.gpg   | gpg --dearmor   | tee /usr/share/keyrings/syncthing-archive-keyring.gpg > /dev/null

# Add the official stable repository
echo "deb [signed-by=/usr/share/keyrings/syncthing-archive-keyring.gpg]   https://apt.syncthing.net/ syncthing stable"   | tee /etc/apt/sources.list.d/syncthing.list

# Install
apt-get update && apt-get install -y syncthing

# Verify
syncthing --version

The package ships with a systemd service template, which is exactly what you want for a homelab service that should restart automatically. You won't be starting Syncthing manually.

Step 3 — Configure Syncthing as a System Service

Syncthing runs as a user process. The cleanest setup is to run it under a dedicated system user so it's isolated from other services and has predictable file permissions on the data directory:

# Create a dedicated system user
useradd --system --home /var/lib/syncthing --create-home syncthing

# Give it ownership of the bind-mounted data directory
chown syncthing:syncthing /data

# Enable and start the systemd service
systemctl enable syncthing@syncthing.service
systemctl start syncthing@syncthing.service

# Confirm it's running
systemctl status syncthing@syncthing.service

By default, Syncthing's web GUI binds to 127.0.0.1:8384 — which means it's only reachable from inside the container. To access it from your browser on your LAN, you need it listening on all interfaces. The config file is generated on first run, so stop the service and do a one-time generation pass:

systemctl stop syncthing@syncthing.service

# Generate the default config
su - syncthing -s /bin/bash -c   "syncthing generate --config=/var/lib/syncthing/.config/syncthing"

# Open the config
nano /var/lib/syncthing/.config/syncthing/config.xml

Find the <gui> element and update the address:

<gui enabled="true" tls="false">
    <address>0.0.0.0:8384</address>
    <!-- rest of gui settings -->
</gui>

Restart the service and exit the container:

systemctl start syncthing@syncthing.service
exit

Step 4 — Initial Configuration via the Web UI

Open http://<container-ip>:8384 in your browser. Syncthing will show a banner prompting you to set a GUI admin password — do this immediately. This is a local web UI with file system access; anyone who can reach it on port 8384 can read and write your sync folders, so treating it like any other privileged service is non-negotiable.

The first configuration task is moving the default sync folder off the container's root disk. Syncthing creates a folder at ~/Sync (the syncthing user's home, which is /var/lib/syncthing/Sync). Click the pencil icon on the "Default Folder", change the Folder Path to /data/sync, and save. Syncthing will rescan and create the directory. This is the folder you'll share with other devices.

Next, check Actions → Settings → Connections. The default port for device-to-device sync traffic is 22000/TCP+UDP. If you want to sync from outside your LAN (say, from a laptop on a coffee shop Wi-Fi), you'll need to forward port 22000 on your router to the LXC container's IP. For LAN-only use, this isn't necessary — Syncthing discovers devices on your local network automatically via local broadcast.

Step 5 — Add a Device and Sync Your First Folder

Install the Syncthing client on the device you want to sync to. Clients are available for Windows, macOS, Linux, Android, and iOS. Once installed, every Syncthing instance has a unique Device ID — a long alphanumeric string shown under Actions → Show ID in the web UI (or in the mobile app's settings).

In the Proxmox LXC's Syncthing UI, click Add Remote Device, paste the Device ID from your laptop or phone, and give it a friendly name. The remote device will display a pending connection request — accept it. Once the two nodes are paired, go to your /data/sync folder in the LXC UI, click Edit → Sharing, and add the remote device to the sharing list. Accept the folder share on the remote device.

Syncthing will now index both sides and begin syncing. The UI shows real-time transfer rates and folder state — you'll see it move from "Syncing" to "Up to Date" once the initial index completes. For a folder with many small files, this initial scan can take a few minutes; subsequent syncs of individual changed files are near-instant on a LAN. If you have a large initial dataset (tens of GB), it's worth letting it run overnight on a wired connection rather than over Wi-Fi.

Step 6 — Expose Syncthing Over HTTPS with Traefik

If you already have Traefik running on a Proxmox LXC, you can serve Syncthing's web UI over HTTPS with a Let's Encrypt certificate in under five minutes. Add a file provider configuration to your Traefik dynamic config directory:

# /etc/traefik/dynamic/syncthing.yml (on the Traefik LXC)
http:
  routers:
    syncthing:
      rule: "Host(`syncthing.yourdomain.com`)"
      entryPoints:
        - websecure
      tls:
        certResolver: letsencrypt
      service: syncthing

  services:
    syncthing:
      loadBalancer:
        servers:
          - url: "http://SYNCTHING_LXC_IP:8384"

Traefik picks up the new file without a restart, issues the Let's Encrypt cert (usually within 60 seconds), and starts routing HTTPS traffic to your Syncthing UI. Because the GUI password is already set, this is safe to expose via your domain.

One thing worth clarifying: the device-to-device sync traffic on port 22000 does not go through Traefik. That's direct BEP traffic between Syncthing nodes, already encrypted end-to-end by Syncthing's own TLS layer. Traefik only proxies the web GUI on port 8384. These are two completely independent communication paths, and you can run just the port 22000 path without any reverse proxy if you don't care about web UI access from outside your LAN.

Hardening and Operational Tips

Enable file versioning. Syncthing supports versioned file history natively, and I'd turn this on for any folder containing important documents. In the folder settings, choose File Versioning → Staggered File Versioning. Per the Syncthing docs, this keeps multiple versions of changed files using an exponential decay schedule — many versions for recent changes, fewer as files age. Set a maximum folder age and a size limit so old versions don't silently fill your disk over months. This gives you a soft recovery option for accidental overwrites, though it's not a substitute for a real backup strategy.

Add a .stignore file. Drop a .stignore file in each sync folder to exclude things you don't want syncing: .DS_Store, node_modules, .git directories, build artifacts, and large temp files. Per the Syncthing documentation, the ignore pattern syntax follows gitignore conventions, so if you already know gitignore, you know .stignore. Excluding node_modules from a development folder can cut sync index size by 90% and dramatically speed up initial scans.

Monitor disk usage. The bind-mounted /data directory grows as you add sync folders and version history accumulates. Keep an eye on host-side disk usage with df -h /mnt/syncthing-data from the Proxmox shell. If you're running Grafana + Prometheus on Proxmox, the node exporter exposes per-mountpoint disk metrics automatically — you can set a threshold alert before you run out of space.

Keep auto-accept device disabled. Syncthing has an "Auto Accept" setting that automatically pairs with any new device that presents your GUI URL. Leave it off. Requiring manual approval for new device connections means no unintended machine can quietly join your sync mesh — a meaningful safeguard if you're sharing your Tailscale or Traefik URL with people who might misconfigure their own Syncthing instance.

Hardware for a Syncthing-Ready Homelab

Syncthing is one of the lightest services you'll run on Proxmox. The LXC container idles at around 50–100 MB RAM and barely registers on CPU except during initial folder scans or large transfers. The bottleneck is almost always network and storage I/O, not compute. A single-core LXC on even a modest mini PC handles hundreds of synced folders and gigabytes of transfer without issue.

If you're building a homelab node for running services like this, the Beelink SER5 Mini PC (~$299) is a solid starting point — the Ryzen 5 5500U handles Proxmox with Syncthing, Jellyfin, Vaultwarden, and several more LXCs simultaneously. If you're watching budget more carefully, the GMKtec G3 PRO Mini PC (~$199) is capable enough for a lightweight self-hosting stack.

For storage, Syncthing's index metadata is tiny, but your actual synced data needs fast I/O. The WD_BLACK SN850X 1TB NVMe is what I'd put in the primary drive slot on a homelab node — fast enough that Syncthing's file system events don't queue up. If you're running multiple containers and VMs alongside Syncthing, maxing out RAM matters more than clock speed, and the Crucial 32GB DDR4 SODIMM (~$59) is the upgrade that makes the most visible difference on a mini PC homelab node.