copyparty

Last reviewed Aug 26, 2026 · 864 words

One Python file with no dependencies, 64 MB of RAM, and a browser upload that resumes exactly where a dropped connection left it: that is the whole copyparty pitch, and it delivers on it. It runs on port 3923 out of the box, speaks HTTP, WebDAV, FTP and TFTP from the same process, and the only real learning curve is a compact command-line grammar for volumes and permissions. Learn those two flags and you have a file server that outperforms Nextcloud at the one job of moving large files over unreliable links, for a hundredth of the resources.

Download copyparty-sfx.py from the GitHub releases and run it with any Python 3. That is the install:

python3 copyparty-sfx.py -a alice:hunter2 -v /srv/share:/:r:rw,alice

The Docker route is the same binary in a container; copyparty/ac is the image variant that includes ffmpeg for audio transcoding and thumbnails, which is the one most people want. Either way, there is no database service, no config wizard, and no first-run migration. The trade is that everything is a flag, and the --help output runs to hundreds of them.

The volume grammar is the whole configuration

Every share is a -v flag of the form -v /disk/path:/url/path:permissions. The permission letters are single characters: r for read, w for write, m for move, d for delete, g for get-only (download a file if you know the URL, no listing), and a for admin. Append ,username to scope a permission set to an account created with -a. A realistic three-share setup:

python3 copyparty-sfx.py \
  -a alice:hunter2 -a guest:dropbox \
  -v /srv/public:/pub:r \
  -v /srv/inbox:/inbox:w,guest:rw,alice \
  -v /srv/alice:/alice:rwmd,alice

That gives an anonymous read-only /pub, a write-only /inbox where guests can upload but cannot see what others uploaded, and a private full-control area for alice. The write-only inbox is the pattern that replaces "send me a WeTransfer link": a client can push a 20 GB file at you without ever getting a listing. Once the flag line grows past 5 shares, move it into a .conf file passed with -c; the syntax is the same, one option per line.

The upload engine is the reason to choose it

copyparty's browser uploader, up2k, hashes files client-side, sends them in chunks over parallel connections, and resumes a partial upload after a reload, a sleep, or a network change without re-sending finished chunks. The hashing also gives it deduplication: uploading a file the server already holds completes instantly. On a 100 Mbit link that saturates the connection where a plain HTML form upload would stall and restart. It is also why the interface looks unconventional; it is a single-page uploader with a file browser attached, not a Dropbox clone.

Turn the database on for search and media

By default copyparty serves the filesystem live with no index. Add -e2dsa and it builds a SQLite index of every file (stored in a .hist folder inside each volume), which enables search, faster dedup, and upload verification. Add -e2ts and it reads media tags, turning a music folder into a browsable library with an in-page player. Both are safe to enable; the first scan of a multi-terabyte volume takes a while, but it runs in the background and the server stays responsive.

Behind a proxy, and the protocols you get for free

Put Caddy in front for TLS with a two-line site block pointing at localhost:3923, and pass --xff-src with your proxy's address so copyparty trusts the forwarded client IP for its logs and rate limits. WebDAV is served on the same HTTP port, which means Windows Explorer, macOS Finder, and rclone can mount a share directly. --ftp 3921 adds an FTP listener for the scanner or camera that speaks nothing else; --tftp 3969 covers the network gear that is even older. Each protocol respects the same volume permissions.

It is not a sync client

Nothing on the client side watches a folder; copyparty is a server you push to and pull from. If the requirement is "keep this folder identical on 3 machines", that is Syncthing, and the copyparty vs Syncthing comparison exists because the two get confused constantly. The honest split: copyparty for sharing, receiving, and browsing; Syncthing for replication. Plenty of people run both on the same box, with copyparty exposing the folder Syncthing keeps in sync. The wider file-sync category covers the rest of that field.

What I'd do

Docker copyparty/ac on any box with 128 MB to spare, a .conf file with a read-only public share, a write-only inbox for people sending you things, and a private area per household member. -e2dsa and -e2ts on from day one. Caddy in front with --xff-src set. Keep Syncthing for the folders that must mirror, and stop paying for the transfer service whose only feature was surviving a flaky upload.