You just took a photo on your phone and you want it on your laptop. Or you're sitting at your desk with a PDF you need to hand off to a tablet across the room. No cable, no cloud account, no waiting for an email attachment to sync. If you've got a Proxmox VE box running on your home network already, you can solve this in about ten minutes with a small, free tool called PairDrop.
This guide walks through installing PairDrop in its own LXC container on Proxmox VE, using the community helper script that most homelabbers already rely on for quick app deployments. You don't need Docker experience, and you don't need to have built an LXC container before — every step is spelled out.
What You Will Learn
By the end of this tutorial you'll know what PairDrop actually does and why it beats emailing yourself a file for the tenth time this month. You'll build a dedicated LXC container for it on Proxmox VE, run through the install script's prompts without guessing at any of them, and find the container's IP address so you can open PairDrop from any device on your network.
You'll also learn what each part of the install command does, the errors people actually run into (mismatched networks, HTTPS-only features that silently don't work), and a short list of things worth doing before you forget about this container forever — which, if it's like most small self-hosted apps, you probably will.
What Is This Feature?
PairDrop is a browser-based file transfer tool. Think of it as a self-hosted, open-source version of Apple's AirDrop that works on literally any device with a modern browser — Android, iOS, Windows, Linux, ChromeOS, doesn't matter. You open the page on two devices connected to the same network, they see each other automatically, and you drag a file from one to the other. There's no account to create and no app to install, though it can be added to your phone's home screen as a installable web app if you set it up with HTTPS.
Under the hood it uses WebRTC, a browser technology built for direct peer-to-peer connections. WebRTC is the same tech behind in-browser video calls, and the reason it matters here is that once two devices agree on how to talk to each other, the actual file data flows directly between them rather than through the PairDrop server. The server's job is small: it just helps two browsers discover each other and negotiate that direct connection, a process called signaling.
An LXC container is the lightweight virtualization option Proxmox VE offers alongside full virtual machines. Instead of emulating an entire computer, an LXC container shares the host's Linux kernel and only isolates the processes, filesystem, and network inside it. That makes it start in a couple of seconds and use a fraction of the RAM a VM would need for the same job — which is exactly what a small Node.js app like PairDrop wants.
Why Would You Use It?
The obvious alternative is Nextcloud, Syncthing, or a USB drive. All three work, but they solve a different problem. Syncthing keeps folders in sync over time, which is overkill when you just want to send one file once. Nextcloud is a full cloud storage platform, and standing one up just to move a PDF is like renting a warehouse to mail a postcard. A USB drive works until you realize your phone doesn't have a USB-A port.
PairDrop's whole pitch is that it does one thing and gets out of your way. No accounts, no folders to configure, no sync conflicts. You open a tab, you see the other device's name (something like "Green Fox" or "Blue Turtle" — PairDrop assigns friendly device names automatically), and you drop the file.
Running it in its own LXC container instead of installing it directly on your Proxmox host, or squeezing it into an existing container, keeps things clean. If PairDrop ever needs a restart, an update, or gets removed entirely six months from now, none of that touches anything else running on your server.
Prerequisites
You'll need a working Proxmox VE host — this guide was tested against Proxmox VE 9.2, though the same steps apply to any recent 8.x or 9.x release. You'll also need:
- Root or administrator access to the Proxmox VE web interface
- A network bridge already configured (almost every install has
vmbr0set up by default) - At least 4 GB of free space on whichever storage you plan to use for the container
- Devices on the same local network you want to test file transfers between
You don't need a Proxmox subscription for any of this. The community helper script and the PairDrop Docker image are both free and open source.
Step-by-Step Tutorial
Log in to the Proxmox VE web interface, click your node in the left-hand tree, and open the >_ Shell option near the top of the resource panel. This drops you into a root shell on the Proxmox host itself, not inside any container yet.
Paste in the following command and hit enter:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/pairdrop.sh)"This pulls the PairDrop installer from the community-scripts project — the actively maintained fork of what used to be tteck's helper scripts — and runs it. You'll get a whiptail menu (the blue text-based menu Proxmox scripts commonly use) asking whether you want the Default Settings or Advanced Settings path.
For a first install, Default Settings is fine. It creates an unprivileged LXC container with 1 CPU core, 512 MB of RAM, and a 4 GB disk, running Debian 13. That's genuinely enough for PairDrop — it's a small signaling server, not something that needs to chew through CPU.
If you go Advanced instead, you'll be asked to pick a CT ID, hostname, disk size, core count, RAM, the bridge to attach to, and whether to use DHCP or a static IP. Bump the RAM to 1 GB if you'd rather not think about it again, but 512 MB has been enough in testing even with a couple of simultaneous transfers.
Once you confirm your choices, the script downloads the Debian 13 LXC template if you don't already have it cached, creates the container, installs Docker inside it, and pulls the PairDrop image. This part takes somewhere between two and five minutes depending on your internet connection — most of that time is the template and image downloads, not the actual container creation.
When it finishes, you'll see a summary with the container's ID and, usually, its IP address. If it's not shown, click on the new container in the left tree and check the Summary tab — LXC containers report their IP directly to Proxmox, unlike VMs, so you don't need to install any guest agent to see it.
Open a browser on any device on the same network and go to http://<container-ip>:3000. You should see the PairDrop interface with a random device name assigned to you. Open the same URL on a second device, and within a second or two each should show up on the other's screen. Drag a file over, accept the transfer on the receiving end, and you're done.
Commands Explained
The one command you actually typed does a lot of work behind the scenes, so it's worth knowing what each piece is doing.
| Part | What it does |
|---|---|
bash -c "$(curl ...)" | Downloads the install script's text and runs it immediately, without saving a copy to disk first. |
-fsSL | curl flags: fail silently on HTTP errors, suppress the progress meter, and follow redirects — standard for one-liner installers. |
pct list | Run this on the Proxmox host shell any time to see every container's ID, status, and name at a glance. |
pct enter <vmid> | Drops you into a root shell inside the container itself, useful if you want to run docker ps or check logs directly. |
docker ps | Run inside the container to confirm the PairDrop container is actually up and see how long it's been running. |
PairDrop's Docker image also reads a handful of environment variables if you ever need to tweak its behavior. WS_FALLBACK turns on a WebSocket fallback mode for clients stuck behind restrictive VPNs. RATE_LIMIT caps clients to 1000 requests per five minutes, which is a reasonable thing to turn on if you ever expose this beyond your LAN. RTC_CONFIG lets you point PairDrop at your own STUN/TURN servers instead of the public defaults, which matters if you want transfers to work across two different networks rather than just one.
Common Errors
"This site can't be reached" when you hit port 3000 almost always means one of two things: either the container hasn't finished starting yet (give it another 30 seconds and refresh), or your device is actually on a different subnet or VLAN than the container. Double-check both the phone and the Proxmox container are pulling an address from the same DHCP range.
Devices don't see each other even though both load the PairDrop page fine. This one trips up more people than any actual software bug. Most home routers, and pretty much all guest Wi-Fi networks, enable something called client isolation or AP isolation by default, which deliberately blocks devices on the same Wi-Fi from talking to each other. If your phone is on the guest network and your laptop is wired in, they'll never discover each other no matter how PairDrop is configured. Move both devices onto the same, non-isolated network and try again.
The copy button or "add to home screen" prompt doesn't do anything. This isn't a bug either — PairDrop deliberately disables clipboard access, PWA installation, saved pairing, and push notifications unless the page is served over HTTPS. Plain http:// access, which is what you get by default with this setup, works fine for drag-and-drop transfers but won't unlock those extras.
Troubleshooting
Start by confirming the container itself is healthy. From the Proxmox shell, run pct status <vmid> — it should say running. If it says stopped, start it with pct start <vmid> and check the Proxmox task log for why it didn't come up on its own.
If the container is running but the web page won't load, get inside it with pct enter <vmid> and run docker ps. You're looking for a container based on the PairDrop image with a status of "Up." If it's missing or restarting in a loop, pull its logs with docker logs followed by the container name shown in docker ps — nine times out of ten this points straight at the problem, whether that's a port conflict or a bad environment variable.
If everything looks healthy inside the container but you still can't reach it from another device, check the Proxmox firewall. It's off by default at the datacenter level, but if you or someone else enabled it at any point, make sure there's a rule allowing traffic to port 3000 from your local subnet.
And if two specific devices refuse to see each other while everything else works, it's worth testing whether they can ping one another at all outside of PairDrop. If they can't, this is a network configuration problem — client isolation, a misconfigured VLAN, or a firewall rule — not something PairDrop can fix from its end.
Best Practices
PairDrop has no login and no authentication by default. That's fine, even good, on a private LAN where you trust every device that can reach it. It's a bad idea to port-forward port 3000 straight to the internet, though — anyone who stumbles on the address can send files to whoever's got the page open, and vice versa. If you genuinely need access from outside your home network, put it behind a reverse proxy with HTTPS and some form of access control in front, rather than exposing the container directly.
Speaking of HTTPS: if you want the PWA install prompt, clipboard copy, and saved device pairing to actually work, you'll need to serve PairDrop behind a reverse proxy with a valid TLS certificate. A container running Nginx Proxy Manager or Traefik elsewhere on your Proxmox host can handle this without much extra work, and it's the same pattern you'd use for any other self-hosted app that wants HTTPS.
Take a quick snapshot of the container before any manual changes, especially before an update. It costs almost nothing on LXC and it means a bad update is a two-click rollback instead of a rebuild. And leave the container unprivileged — the default the script picks — since PairDrop has no legitimate reason to need root-level access to the host.
Frequently Asked Questions
Does PairDrop work between devices on different networks?
Not by default. Out of the box it's designed for same-network transfers. Cross-network transfers need a TURN server, either a self-hosted one or a public option like OpenRelay, configured through the RTC_CONFIG environment variable.
Do I need a Proxmox subscription to use this?
No. Everything here — the helper script, the LXC container, and PairDrop itself — works fine on the free, no-subscription version of Proxmox VE.
Can I run PairDrop without Docker?
Yes, it can run directly with Node.js, but the community helper script installs it via Docker inside the LXC container, and that's the path this guide follows since it's the one most people run in practice.
Is my data stored anywhere on the PairDrop server?
No. Files transfer directly between the two devices over the peer-to-peer connection. The container only handles the initial handshake between them.
How do I update PairDrop later?
Re-run the same install command against the existing container's ID. The community script detects the existing installation and offers to update it instead of creating a new one.
Conclusion
PairDrop is one of those tools that feels almost too simple once it's running — you forget how many minutes you used to lose emailing yourself files or hunting for a cable. Ten minutes of setup on a Proxmox host you're probably already running gets you a permanent, ad-free AirDrop that works across every platform in the house.
From here, the natural next step for a lot of people is putting a reverse proxy in front of it for HTTPS, or pairing it with something like Syncthing for the files you want kept in sync rather than just sent once. Either way, the container you just built will keep doing its one job quietly in the background, which is really all you can ask of it.