Set Up Snapdrop for Local Wireless File Sharing

Skip the Cable, Skip the Cloud

Snapdrop is a browser-based file sharing tool that lets devices on the same local network exchange files without uploading anything to the internet. No accounts, no installation, no cloud middleman – just open a browser and drop a file.

What Snapdrop Is and How It Works

Snapdrop runs entirely in the browser using WebRTC for peer-to-peer data transfer and WebSockets for device discovery. When two devices open the same Snapdrop page while connected to the same Wi-Fi network, they appear to each other automatically. You click a device icon, choose a file, and the recipient gets a download prompt. The transfer happens directly between the two browsers – the server only handles the handshake, not the file data itself.

The public instance lives at snapdrop.net, and it works well enough for casual use. But self-hosting gives you a few real advantages: your local traffic never touches an external server at all, the service stays available even when snapdrop.net is down or slow, and you control the network entirely. For offices, home labs, or anyone sharing files regularly between devices, self-hosting is the cleaner choice.

Snapdrop is open source, maintained on GitHub under the nicholasstephan/snapdrop fork (the most actively developed version). It ships with a Node.js backend and a straightforward frontend. Docker makes deployment simple enough that you can have it running in under ten minutes if you already have Docker installed. The resource footprint is minimal – this is not an application that demands much from the host machine.

Before setting up, confirm your environment. You need Docker and Docker Compose installed on the host. The host machine should have a stable local IP address – assign it a static IP through your router’s DHCP settings if you haven’t already. Every device that will use Snapdrop needs to be on the same network subnet, which is standard for a home or office Wi-Fi setup. No port forwarding to the internet is required or recommended.

Running Snapdrop with Docker Compose

Create a directory for the project – something like /opt/snapdrop or ~/snapdrop works fine. Inside that directory, create a file named docker-compose.yml. The configuration is short. You’re defining a single service using the LinuxServer.io Snapdrop image, which is well-maintained and handles the Node.js environment internally. Set the container to restart unless stopped, map port 80 on the host to port 80 in the container (or use port 3000 if 80 is already occupied), and optionally pass your local timezone as an environment variable using TZ=America/New_York or whichever zone applies. A basic volumes block pointing to a config directory is included in the LinuxServer image for persistent settings, though Snapdrop itself doesn’t store much state.

Once the compose file is saved, run docker compose up -d from that directory. Docker pulls the image, starts the container in detached mode, and the service becomes available almost immediately. Open a browser on any device connected to the same network and navigate to the host machine’s local IP address – for example http://192.168.1.50. You should see the Snapdrop interface load with your device name displayed as a circle in the center of the screen.

To test the setup, open Snapdrop on a second device using the same URL. Both devices should see each other within a few seconds. Click the other device’s icon on one machine, select a file from the dialog that appears, and confirm. The receiving device gets a browser notification asking whether to accept. Accept it, and the file downloads directly. If the devices don’t see each other, the most likely cause is that they’re on different network segments – a guest Wi-Fi network isolated from the main LAN, for instance, will block the WebSocket discovery.

For a hostname instead of a raw IP address, add an entry to your router’s local DNS or to the /etc/hosts file on each device. Something like snapdrop.local pointing to the host IP makes the URL easier to type and remember. If you’re already running a local reverse proxy, you can route snapdrop.local through it with a proper virtual host configuration – the setup process is similar to other self-hosted services described in the guide on setting up Caddy as a reverse proxy for self-hosted services.

One friction point worth addressing: mobile browsers on iOS and Android occasionally block file downloads from local HTTP (non-HTTPS) addresses. Safari on iPhone is particularly inconsistent about this. The fix is to add a self-signed certificate to your reverse proxy and trust it on the device, or to use a tool like mkcert to generate a locally-trusted certificate. This is more setup work, but it makes the mobile experience reliable. Without it, sending files to a phone works fine while receiving from one can stall at the download step depending on browser and OS version.

Keeping It Running and Staying Updated

Snapdrop doesn’t require ongoing maintenance beyond keeping the Docker image current. Run docker compose pull followed by docker compose up -d periodically to pull any updated image versions from LinuxServer.io. The service has no database, no user accounts, and no stored files – updates are low-risk and fast. Set a reminder to check every month or two, or use a tool like Watchtower to automate image updates if you prefer a hands-off approach.

One detail that catches people off guard: Snapdrop’s device names are randomly generated per browser session and reset when you clear cookies or use a private window. You can’t permanently name a device through the interface. On a shared network with many devices, this means users occasionally send a file to the wrong peer because two devices both show something like “Teal Zebra.” The workaround is to right-click your own device icon in Snapdrop and edit the display name – that change persists in the browser’s local storage until cookies are cleared. Worth showing anyone on your network who will use it regularly.