SyncClipboard: cross-platform clipboard sync with a history store you host

What SyncClipboard solves, and who ends up running it

Copying text on one machine and pasting it on another usually means a cloud clipboard tied to an account you do not control, or a manual paste into a chat window. SyncClipboard takes the third route: the clipboard content moves through a server that you or your team operates. The README lists three desktop platforms (Windows, macOS, Linux) and describes real-time clipboard sync plus clipboard history management and history sync. Mobile is handled differently: the README points to third-party tools rather than a first-party app, with separate sections for iOS Shortcuts, several Android options, and ClipLink on HarmonyOS Next.

The audience is narrower than "anyone who copies text." You need somewhere to put the server, or an existing WebDAV drive, or an S3-compatible bucket. If you have none of those, the desktop client's built-in server is the fallback, and the README says it is configured through the graphical interface. That is the lowest-friction path, but it makes one desktop machine the hub for the others, which is a different reliability story from a container on a host that stays up.

The sync network: server, clients, and what travels between them

Every participant in a SyncClipboard setup speaks to a server. The server can be the standalone SyncClipboard.Server, the server embedded in the desktop client, a WebDAV endpoint, or S3-compatible object storage. The README's tested WebDAV list includes Nextcloud, AList, InfiniCLOUD and aliyundrive-webdav, so the WebDAV path is not theoretical.

On the S3 side the client uses the official AWS S3 SDK and also accepts S3-compatible services. The account fields are specific: Server Address (optional for AWS, required as an endpoint for compatible services), Region, Bucket Name, Object Prefix, Force Path-Style Addressing, Access Key ID and Secret Access Key. The README says the bucket stores SyncClipboard.json and objects under file/, and recommends a dedicated prefix such as syncclipboard to isolate the data. That is the whole data model in one sentence: one JSON index plus a file/ prefix for payloads.

The desktop clients sync automatically while running in the background. The README also documents two command-line arguments: --shutdown-previous, and a family of --command-{command-name} flags. The server exposes an API with endpoints for getting the clipboard and uploading the clipboard, plus the SyncClipboard.json format and an S3 sync protocol specification. The version history matters here: v3.1.1 and later clients and servers are not compatible with earlier versions, and the README states that clients, servers and third-party clients in one sync network must be upgraded together.

Installing the server with Docker and pairing the first desktop client

The fastest server path in the README is the published container image. Credentials come from environment variables, and the data directory is mounted so the generated appsettings.json survives restarts.

docker run -d \
  --name=syncclipboard-server \
  -p 5033:5033 \
  -e SYNCCLIPBOARD_USERNAME=your_username \
  -e SYNCCLIPBOARD_PASSWORD=your_password \
  -v /data/syncclipboard-server:/app/data \
  --restart unless-stopped \
  jericx/syncclipboard-server:latest

After the first start, the README says a default appsettings.json appears in the container's /app/data directory, which is the host's /data/syncclipboard-server. Edit that file for history limits and HTTPS. Note the mapping caveat: when you change file paths in appsettings.json, you have to account for the container-to-host mapping.

If you prefer not to use Docker, the standalone server runs on ASP.NET Core 8.0 after you install the ASP.NET Core runtime.

dotnet /path/to/SyncClipboard.Server.dll --contentRoot ./

The working directory is the dll's directory and needs write permission. To move it, copy appsettings.json into the new directory and change the path after --contentRoot. On Arch Linux the AUR package syncclipboard-server installs a config at /etc/syncclipboard/appsettings.json, and the service starts with systemctl.

For the client, download the installer or archive from the releases page: names beginning with SyncClipboard_win_ for Windows, SyncClipboard_macos_ for macOS, SyncClipboard_linux_ for Linux. Windows 10 2004 is the minimum supported version. On macOS, Gatekeeper may block the app; the README's fix is to open Privacy & Security settings and click Open Anyway, and if macOS reports the app is damaged, run the quarantine removal command it prints. Some macOS features simulate keyboard input and therefore need Accessibility permission, which the app prompts for.

History is the feature to treat with suspicion

The README carries a warning above the fold: the clipboard history feature is at an early stage, and users should be prepared to lose all of that information, keeping important data somewhere other than this tool. That is unusually direct, and it should shape how you deploy SyncClipboard. Sync is the mature part; history is the part with an explicit data-loss caveat attached.

The server-side history controls are two integers in appsettings.json: MaxSavedHistoryCount, where 0 means no count limit, and HistoryRetentionMinutes, where 0 means no time limit. The README notes that the two limits apply independently, so setting one to 0 does not disable the other. If you set MaxSavedHistoryCount to 1000, you get 1000 entries unless the retention window expires them first.

Two other constraints are worth planning around. HTTP is plaintext, and the README tells you to enable HTTPS or put a reverse proxy in front when deploying on a public network; when no certificate authority is available it suggests mkcert or another way to generate a self-signed certificate. And on Linux, if syncing is slow, fails, or produces garbled uploads, the README recommends installing xclip on X11 or wl-clipboard on Wayland, because SyncClipboard uses those tools to read the clipboard. That is a real dependency on the desktop environment, not a bug you can configure away.

Where SyncClipboard is the wrong tool

If you want a clipboard manager on a single machine, SyncClipboard is overbuilt. The history store lives behind a server, and the value comes from moving content between machines. A local-only tool does that job with no server, no credentials and no network.

If you want a first-party mobile app, look carefully before committing. The README does not ship one. iOS is handled through Shortcuts, Android through SyncClipboard Mobile, Sync Clipboard Flutter, an AutoJs6 script, Fcitx5-SyncClipboard or syncclipboard-xposed, and HarmonyOS Next through ClipLink. Each of those is maintained separately from the desktop client, so the upgrade story spans projects you do not control.

If every machine in your setup must stay on an older release, SyncClipboard is also the wrong tool. The v3.1.1 change is a hard break: newer clients and servers do not interoperate with older ones, and the README requires the whole sync network to move together. There is no documented compatibility mode and no documented rollback procedure for a partially upgraded network.

SyncClipboard against CopyQ and the WebDAV-only route

CopyQ is the obvious comparison, and the difference is architectural rather than cosmetic. CopyQ is a local clipboard manager: it keeps history on the machine where it runs. SyncClipboard's history is server-side, which is what makes history visible from a second machine and what makes the server a single point of failure and a single point of backup. If your machines are rarely online at the same time, CopyQ's local model keeps working; SyncClipboard's does not.

Within SyncClipboard itself there is a second choice worth naming: standalone server versus WebDAV. The standalone server gives you the appsettings.json knobs (history count, retention, HTTPS certificates, logging) and the documented HTTP API for get and upload. A WebDAV drive gives you none of those controls, because you are borrowing someone else's storage semantics; what you get instead is not running a service. The S3 route sits between them: you get object storage you may already pay for, at the cost of configuring Region, Bucket Name, Object Prefix and Force Path-Style Addressing correctly for a non-AWS endpoint. The README recommends enabling path-style addressing for compatible services, which is the setting most likely to be missed.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-09-22. Releases have been frequent: v3.1.9 on 2026-07-18, v3.2.0 on 2026-08-15, and v3.3.0-beta1 on 2026-09-19. That cadence cuts both ways. You get fixes, but you also inherit the v3.1.1 incompatibility precedent, which shows the project will break client-server compatibility when it needs to. Budget for upgrading the server and every client and third-party client in the same window.

Upgrade cost is otherwise low on the server side. The Docker image is pulled by tag, the standalone server is a dll swap plus a runtime that must be ASP.NET Core 8.0, and the AUR package is managed by pacman or paru. On the client side, Windows and macOS installers and Linux packages come from the releases page, so the cost is per-machine rather than per-service.

The project is MIT licensed, and the repository carries a LICENSES/ directory alongside the LICENSE file, which suggests bundled components may carry their own terms. MIT is permissive, but if you redistribute the desktop client or the server inside a product, read the per-component licences in that directory rather than assuming the top-level file covers everything. This is a description of what the repository contains, not legal advice.

Editorial conclusion

Adopt SyncClipboard if you control a server, a WebDAV drive or an S3 bucket and you want clipboard history that stays on infrastructure you own, with Windows, macOS and Linux desktop clients in one sync network. Do not adopt it if you need clipboard history as durable storage: the README warns that the history feature is early stage and tells you to be prepared to lose all of it, so anything important should live elsewhere. Before rolling it out, verify that every client and server in the network is at v3.1.1 or later, because the v3.1.1 change makes older clients and servers incompatible with newer ones.

Frequently asked questions

Official sources

1. Issues
2. Jeric-X/SyncClipboard on GitHub
3. License: MIT
4. README
5. Releases