How to Deploy copyparty on a VPS

copysudo apt-get update && sudo apt-get -y upgrade
sudo apt-get install -y curl openssl ufw dnsutils

copyadduser deploy
usermod -aG sudo deploy

copysudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable

#Install Docker

copyparty is installed with Docker Compose. If Docker isn't on the server yet, the convenience script installs Docker Engine and the Compose plugin (the Docker and Compose on Ubuntu guide covers the details):

copycommand -v docker >/dev/null || curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
sudo docker compose version

The group change applies on your next login; until then the commands below use sudo docker.

#Install copyparty

Create the project directory and the folder to share, and generate the admin password into a .env file that Compose reads automatically. The container runs as user ID 1000, so that user must own the share. The [ -f .env ] guard keeps the step safe to re-run, so a second pass never silently changes the password under you. Set your hostname first (this guide uses files.example.com; replace it with yours):

copymkdir -p ~/copyparty/share && cd ~/copyparty
sudo chown 1000:1000 share
DOMAIN=files.example.com
[ -f .env ] || printf 'CP_PASS=%s\nDOMAIN=%s\n' "$(openssl rand -hex 12)" "$DOMAIN" > .env
grep -c CP_PASS .env

Now the Compose file. It runs the official ac image (the variant with the common optional features included) with the tag pinned, so an upgrade is a deliberate edit and not a surprise. The two arguments after the image are the whole configuration: -a defines the admin account, and -v /w::A,admin shares the folder with that account alone, with full access. Caddy gets its hostname from the same .env:

copycd ~/copyparty
cat > docker-compose.yml <<'EOF'
services:
  copyparty:
    image: copyparty/ac:1.20.25
    restart: unless-stopped
    user: "1000:1000"
    ports: ["127.0.0.1:3923:3923"]
    volumes: ["./share:/w"]
    command: ["-a", "admin:${CP_PASS}", "-v", "/w::A,admin"]
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    environment:
      DOMAIN: ${DOMAIN}
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro", "caddy_data:/data"]
    depends_on: [copyparty]
volumes:
  caddy_data:
EOF
cat > Caddyfile <<'EOF'
{$DOMAIN} {
    reverse_proxy copyparty:3923
}
EOF

Start it and wait for the web UI to answer:

copycd ~/copyparty
sudo docker compose up -d
for i in $(seq 1 30); do
  code=$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:3923/)
  [ "$code" != "000" ] && break
  sleep 2
done
echo "copyparty answered HTTP $code"
sudo docker compose ps

An HTTP 200 here is the login page, not your files: the share itself is refused to anyone who isn't logged in, as the upload test below shows. Show the admin password once so you can log in:

copygrep CP_PASS ~/copyparty/.env

#HTTPS + domain

Create an A record for your file server's hostname (say files.example.com) pointing at the server's public IP, and confirm it resolves before Caddy tries to get a certificate:

copydig +short files.example.com

Caddy is already running from the previous step. It requests the certificate as soon as the name resolves, and renews it on its own (see Automatic HTTPS with Caddy for how that works). Check that HTTPS is up and the login still protects the share:

copy. ~/copyparty/.env
sleep 15
curl -s -o /dev/null -w 'HTTPS status %{http_code}, certificate check %{ssl_verify_result}\n' \
  "https://$DOMAIN/"

A ssl_verify_result of 0 means the certificate verified. Open https://files.example.com in a browser and confirm the padlock.

#First login and hardening

Open the site and log in as admin with the password from .env. Then:

1. Upload a file from the browser to confirm writes work, and check it lands in ~/copyparty/share on the server.
2. Keep the single-account setup until you need more. To add people, add further -a user:password arguments and extra -v lines to the command in the Compose file, each with only the permissions that person needs (r read, w upload, A everything). Edit, then sudo docker compose up -d.
3. Keep the share's permissions narrow. Never give a public, anonymous account write access on an internet-facing server: open uploads get abused within days.
4. The .env file holds the password in plain text. Keep it readable only by you (chmod 600 ~/copyparty/.env).

You can also use the same credentials from a command line. This uploads and fetches a file through the HTTPS front door, then confirms that an anonymous download of the same file is refused:

copycd ~/copyparty
. ./.env
echo "hello copyparty" > /tmp/hello.txt
curl -s -o /dev/null -w 'upload HTTP %{http_code}\n' -u "admin:$CP_PASS" \
  -T /tmp/hello.txt "https://$DOMAIN/hello.txt"
curl -s -u "admin:$CP_PASS" "https://$DOMAIN/hello.txt"
curl -s -o /dev/null -w 'anonymous download HTTP %{http_code}\n' "https://$DOMAIN/hello.txt"

#Backups

Everything copyparty serves is in the share folder, and its settings are in the Compose file and .env. There is no database to dump: the file index is rebuilt from the folder. Archive the data and the configuration. The configuration archive contains .env, and with it the admin password, so the command also restricts both archives to their owner:

copycd ~/copyparty
sudo tar czf ~/copyparty-share-$(date +%F).tar.gz share
sudo tar czf ~/copyparty-config-$(date +%F).tar.gz docker-compose.yml Caddyfile .env
sudo chmod 600 ~/copyparty-*.tar.gz
ls -lh ~/copyparty-*.tar.gz

Copy both archives off the server, to object storage, another machine, anywhere that survives this VPS dying, and run the pair from cron. For a large share, an incremental tool such as rsync or restic is a better fit than re-archiving everything nightly. To prove the archive restores, unpack it into a scratch folder and compare:

copymkdir -p /tmp/cp-restore && cd /tmp/cp-restore
sudo tar xzf ~/copyparty-share-$(date +%F).tar.gz
sudo diff -r /tmp/cp-restore/share ~/copyparty/share && echo "restore matches"
sudo rm -rf /tmp/cp-restore

On a new server, install Docker, unpack the config archive into ~/copyparty, unpack the share archive beside it, make sure user ID 1000 owns share, and run sudo docker compose up -d.

#Upgrades

Because the image tag is pinned, an upgrade is an edit. Check copyparty's release notes, take a backup (previous section), change the tag in docker-compose.yml, then pull and recreate:

copycd ~/copyparty
sudo docker compose pull
sudo docker compose up -d
sudo docker compose logs --tail 20 copyparty

copyparty is a fast-moving project with frequent releases. There is no database migration to fear, so rolling back is just putting the previous tag back. Skim the release notes for changed command-line options before you jump several versions, since your whole configuration is command-line arguments.

#Troubleshooting

Downloads return 403. That is the point: the only share requires the admin account. Log in at the web UI, or pass -u admin:PASSWORD to curl. If the correct password is rejected, check that .env still holds the one you were shown and run sudo docker compose up -d again, since the container reads it at start.

Uploads fail with "permission denied" in the logs. The share folder must be owned by user ID 1000, the user the container runs as: sudo chown -R 1000:1000 ~/copyparty/share.

Caddy never gets a certificate. Confirm dig +short files.example.com returns the server's IP and that your provider's network-level firewall, not just ufw, allows inbound 80 and 443. A blocked port 80 silently breaks the ACME challenge. Read Caddy's side with sudo docker compose logs caddy.

Large uploads stall or restart. copyparty uploads in resumable chunks, so an interrupted browser upload continues where it stopped. If it keeps failing through the proxy, test directly over an SSH tunnel to port 3923 to separate a proxy problem from a server problem.

#Verification + next steps

Not exercised in our test run: the new-user step and the DNS check against your real domain (we ran on a throwaway box with a temporary hostname); a reboot of the server, so the restart-after-reboot check below is expected behaviour from restart: unless-stopped, not something we observed.

You're done when https://files.example.com loads with a valid certificate, anonymous downloads are refused, you can log in as admin and upload and download a file, docker compose ps shows both services up after a reboot (restart: unless-stopped brings them back), and you have restored a backup into a scratch folder at least once.

From there, add per-person accounts and shares, try the WebDAV endpoint from your file manager, and set up a scheduled off-server copy of the archives. For the ranked server picks and the app's catalog details, see Best VPS for self-hosting and the copyparty entry.