Building a 'Local-First' Team Cloud Storage System Using Syncthing and a VPS Central Relay Server

Introduction: The Changing Landscape of Enterprise Data Storage

In the digital-first business environment, data is one of the most critical assets an organization owns. For years, public cloud storage providers have been the default choice for teams requiring collaboration and file synchronization. However, as data volumes grow exponentially, subscription costs scale linearly, and concerns over data privacy, sovereignty, and platform lock-in intensify. Relying solely on third-party public clouds exposes enterprises to vulnerabilities, including unauthorized data access, service outages, and unpredictable compliance compliance risks.

To mitigate these risks, forward-thinking technical leaders are turning to the 'Local-First' software philosophy. This paradigm ensures that data belongs primarily to the local devices of the users, enabling real-time local network performance while maintaining the capacity to sync globally. This article delivers an architectural blueprint and deployment guide for building a self-hosted, enterprise-grade Local-First Cloud Storage system utilizing Syncthing and a Virtual Private Server (VPS) operating as a centralized relay and discovery server.

Understanding the Architecture: Local-First with Syncthing

Syncthing is a continuous file synchronization program that replaces proprietary cloud sync services with an open, trustworthy, and decentralized alternative. By default, Syncthing operates on a peer-to-peer (P2P) architecture. Files are broken down into blocks, cryptographically hashed, and transferred directly between authorized devices over TLS.

However, an unmodified P2P setup presents challenges within a professional team environment. Devices are frequently behind symmetric NATs, firewalls, or corporate networks that block direct inbound connections. Furthermore, if Device A modifies a file at 2:00 PM and goes offline, and Device B boots up at 3:00 PM, they cannot synchronize because their availability windows do not overlap.

The Role of the Central VPS Relay and Discovery Server

To transform Syncthing into a highly available, robust business solution, we introduce a dedicated, low-cost VPS into the architecture. This server does not act as a traditional centralized storage bucket where data sits in plaintext. Instead, it fulfills three distinct, critical roles:

Private Discovery Server (stdiscosrv): Allows your team's devices to securely locate each other’s dynamic IP addresses using cryptographic device IDs, bypassing public discovery pools.
Private Relay Server (strelaysrv): When direct P2P connections are impossible due to strict corporate firewalls, traffic is securely tunneled through this relay. Because all traffic is end-to-end encrypted via TLS, the relay server cannot read or inspect your data.
Continuous Always-On Peer (Optional but Recommended): The VPS can also host an encrypted Syncthing node with zero-knowledge encryption (Untrusted Device feature). This node acts as a 24/7 synchronization hub, ensuring data is always propagated even when original endpoints are offline.

Step-by-Step Implementation Guide

Below is the technical roadmap required to deploy this infrastructure. We assume a standard Ubuntu LTS environment for the central VPS.

Step 1: Setting Up the Private Discovery Server

First, we isolate our discovery mechanism from the public internet to ensure privacy. Download the official Syncthing discovery server binary onto your VPS. Execute the service and configure it to listen on the standard port (typically 8443). Ensure you restrict access or use a firewall to allow traffic only from known corporate subnets or require specific API keys.

Security Note: Upon initialization, the discovery server generates a unique cryptographic certificate. Note down the device ID embedded in the console logs; your client devices will require this exact string to connect securely.

Step 2: Deploying the Private Relay Server

When NAT traversal fails, the relay server guarantees connectivity. Install the strelaysrv binary on the VPS. It is vital to run this service with specific flags to prevent unauthorized public consumption of your bandwidth. Use the -provided-by and -pools="" flags to keep the relay completely private and unlisted from the global Syncthing directory.

Step 3: Configuring the Firewall (UFW)

Securing the VPS network perimeter is mandatory. Execute the following commands to open only the necessary ports for Syncthing’s backend infrastructure:

sudo ufw allow 22/tcp
sudo ufw allow 8443/tcp
sudo ufw allow 22067/tcp
sudo ufw enable

Step 4: Client Provisioning and Configuration

With the backend infrastructure live, install the Syncthing client application across team endpoints (Windows, macOS, Linux). To complete the ecosystem, alter the default settings on every client machine:

Navigate to Actions > Settings > Connections.
Uncheck Global Discovery and Enable Relaying via public pools.
In the Global Discovery Servers field, input your custom VPS address: https://your-vps-ip:8443/?id=YOUR-DISCOVERY-ID.
In the Sync Connections field, hardcode your private relay link if direct connection fails automatically.

Evaluating the Strategy: Advantages and Operational Challenges

Before executing a migration to a local-first architecture, enterprise IT leaders must weigh the operational implications against standard public cloud setups.

Metric / Attribute	Public Cloud (SaaS)	Local-First (Syncthing + VPS)
Data Privacy	Subject to vendor privacy policies and jurisdictions.	Absolute. 100% controlled by your organization.
Sync Speed	Limited by WAN/Internet upload and download thresholds.	LAN speed (up to gigabit) for local peers; optimized WAN.
Offline Usability	Degraded. Heavy reliance on persistent internet.	Seamless. Full read/write access locally; syncs post-connection.
Cost Structure	Linear, recurring monthly per-user licensing fees.	Fixed, predictable infrastructure costs (VPS computing fees).

Key Advantages Explained

Unparalleled Performance: Because files are synchronized directly across the local network (LAN) when team members are in the same office, synchronization bypasses the internet gateway completely. Large design files, video assets, or massive compile directories sync at maximum hardware speeds.

Zero-Knowledge Hosting: By utilizing Syncthing’s Untrusted Node feature, the file blocks stored on the central VPS are fully encrypted. Even if malicious actors compromise the cloud VPS provider, they obtain nothing but unreadable cryptographic shards.

Challenges and Mitigation Strategies

Conflict Resolution: Simultaneous edits to the same file generate .sync-conflict- files. Teams should adopt strict operational workflows, use file-locking mechanisms, or combine this setup with version control tools like Git for development assets.
Backup Responsibility: Local-first synchronization is not a backup solution. Deletions propagate across nodes. It is imperative to pair this architecture with snapshots (e.g., ZFS or Btrfs file systems) on primary storage endpoints.

Conclusion

Building a local-first cloud storage ecosystem using Syncthing and a private VPS relay offers contemporary organizations the optimal blend of security, speed, and fiscal efficiency. By decentralizing the data payload while centralizing network discovery and relay functions, businesses effectively eliminate third-party data dependencies and vendor lock-in. While it demands a higher degree of initial technical oversight than a standard SaaS subscription, the dividends in performance, compliance, and long-term cost reduction make it a compelling architecture for modern, agile engineering and business teams.