LocalSend: I installed it across my entire stack and it replaced AirDrop, but there's a tradeoff nobody mentions
LocalSend just hit 850 points on Hacker News — the highest score in today's trending. The community is euphoric. I tried it too. And I have something to say that you won't find in the posts flooding out over the next 48 hours.
Full disclosure upfront: I'm not objective here. I run a Mac with Apple Silicon, two Linux boxes on Debian and Arch, an Android, and an iPhone I basically retired but still keep around for testing. AirDrop has been baked into my workflow for years. When something threatens to replace it, I test it properly.
My thesis: LocalSend wins the philosophical argument, no contest. But there's a daily-friction tradeoff that nobody in that HN thread is actually measuring, and when you measure it, the story gets a little more complicated.
LocalSend as an open source AirDrop alternative: what it is and why it matters now
LocalSend is peer-to-peer local network file transfer — no intermediary servers, no account, no cloud. Flutter for the client, Rust for parts of the core, MIT license, active repo on GitHub. The protocol runs HTTP/HTTPS over your Wi-Fi network with device discovery via multicast DNS — basically the same thing AirDrop does under the hood, but open and cross-platform.
Why does this matter in 2026? Because the ecosystem has fragmented. I have a Mac, colleagues on Windows, Linux servers, and AirDrop only speaks Apple. Every time I need to move a file to my Linux box I have to open a browser tab, upload something to a cloud service I don't want holding that file, or set up SSH — which, let's be honest, at 11pm when you're in the middle of a debug session, you don't want to type anything.
The second reason is privacy. After I simulated the Mercor data-theft attack against my own stack (I wrote that up here), I became a lot more sensitive about what data flows through third-party services. A tool that never leaves the local network has a radically different attack surface.
Installation and first measurements on my real stack
I installed LocalSend on three machines in parallel:
- Mac M4 Pro — download from the official site, dmg, drag to Applications, done. 2 minutes.
-
Arch Linux —
yay -S localsend-bin, 90 seconds including the AUR package download. -
Debian 12 on my dev server — AppImage from GitHub releases,
chmod +x, ran it. Worked.
First real transfer: 847 MB of Next.js project assets from the Mac to the desktop Linux box. Both on the same home Wi-Fi network, router about 2.4 meters away.
# Manual measurement with time and a reference file
# On the destination machine (Linux), logging receive time
time echo "Transfer start $(date +%T)" && \
# LocalSend doesn't have a CLI yet, so I used the UI
# and timed it with this script watching the file appear
watch -n 0.1 'ls -lh ~/Downloads/assets-project.tar.gz 2>/dev/null || echo "waiting..."'
LocalSend result: 847 MB in 38 seconds → ~22 MB/s over Wi-Fi.
AirDrop comparison Mac-to-Mac (same router, same distance): the same file took 31 seconds → ~27 MB/s.
The difference is 5 MB/s. For a typical daily work file — a screenshot, a PDF, a config file — that's invisible. For a 10 GB database dump it starts to matter. But for 90% of my use cases, we're talking fractions of a second.
What I did notice: AirDrop shows up in the UI in ~1.5 seconds. LocalSend took between 3 and 8 seconds to discover devices depending on the time of day. That discovery delay is perceptible and it breaks your flow.
The tradeoff that HN's enthusiastic posts aren't mentioning
Here's the part that doesn't show up in the 850-point thread.
LocalSend depends on mDNS and on every device being on the same subnet. That sounds obvious, but in practice there are three scenarios that will break your workflow:
Scenario 1: Active VPN
When I have a client VPN running — which is 60% of my workday — LocalSend stops seeing my own devices. Multicast traffic doesn't cross the VPN tunnel. AirDrop has the same technical limitation, but in the Apple ecosystem there's a Bluetooth fallback that works without an IP network.
# Check whether mDNS is coming through with VPN active
# On Linux with avahi-daemon:
avahi-browse -all -t | grep localsend
# If nothing shows up, multicast is being blocked by the VPN interface
# See which interfaces are active and which one has the VPN:
ip route show | grep -E 'default|tun|vpn'
In my tests: with Tailscale active (which sets up a tailscale0 interface), LocalSend kept working because Tailscale doesn't filter local traffic. But with a corporate client VPN — WireGuard with aggressive split tunneling — it vanishes completely.
Scenario 2: Corporate networks with separate subnets
At a client's office, mobile devices go to a guest subnet (192.168.100.x) and work machines to another (10.10.x.x). No routing between them. AirDrop uses Bluetooth as a discovery channel that's independent of the IP network — that's why it keeps working. LocalSend has no such fallback.
Scenario 3: The headless server without a GUI
I installed LocalSend on my Debian server thinking I could receive files without opening an SSH session. The problem: LocalSend doesn't have a stable daemon mode or CLI yet. You need an active desktop session, or at minimum a virtual display with Xvfb:
# Workaround: run LocalSend headless with Xvfb
# (this is a hack, not a solution)
Xvfb :99 -screen 0 1024x768x24 &
export DISPLAY=:99
./LocalSend-1.15.0-linux-x86-64.AppImage &
# The cleaner alternative for server transfers:
# just keep using rsync or scp, let's be honest
rsync -avz --progress file.tar.gz user@server:/destination/
This is where LocalSend shows its current ceiling: it's a desktop GUI tool. Excellent at that. But if you want transfers to headless infrastructure, it's still rsync or scp.
Why I kept it installed anyway (and I'm actually using it)
With all of that said — did I keep it installed? Yes. Why?
Because those three problematic scenarios are specific contexts. 70% of my daily work happens on my home network, all devices on the same subnet, no active VPN. And in that context, LocalSend solves exactly what AirDrop can't: talking to my Linux machines.
The philosophical argument carries weight too. I work with client data. I have a Postgres instance in production that I wrote a whole post about when pgbackrest lost its maintainer (here). The idea of a dev dump passing through iCloud or Google Drive just because I have no other way to move it between devices makes me uncomfortable. LocalSend eliminates that vector entirely.
Then there's vendor lock-in. I'm an Apple Silicon user and I think the hardware is genuinely brilliant — Asahi Linux 7.0 confirmed to me that ARM is going to dominate the server space too. But depending on AirDrop for critical transfers means that if I ever migrate a client to Windows or bring on a Linux collaborator, I have to change my whole workflow. LocalSend solves that today.
The number that closed the decision for me: in the last 30 days, 34% of my transfers were Mac→Linux. AirDrop doesn't cover that case and never will. LocalSend handles it at 22 MB/s with zero intermediary servers.
Common mistakes and gotchas when installing LocalSend
Firewall blocking port 53317. LocalSend uses that port by default. On Linux with ufw:
# Open the LocalSend port only on the local network
sudo ufw allow from 192.168.0.0/16 to any port 53317
sudo ufw allow from 10.0.0.0/8 to any port 53317
# Verify it's listening
ss -tlnp | grep 53317
Generic device name. On first launch, LocalSend assigns you a random name. Change it immediately in Settings → Device Name. If you have two Linux boxes with the same generated name, the UI gets confusing fast.
Transfer mode. By default, LocalSend asks for confirmation on the receiving end. For frequent transfers between your own machines, enable "Auto-Accept" for known devices only — there's a whitelist. Don't leave it on "accept all" if you're on a shared network.
Large file previews freeze the UI. Send a 2GB video and LocalSend tries to generate a preview on the receiver before you accept. On machines with limited RAM this freezes the UI for 4-5 seconds. Disable previews in Settings → Receive → Show Preview.
FAQ: LocalSend as an open source AirDrop alternative
Does LocalSend work without internet?
Yes, completely. That's the whole point of the project. It uses only the local network — it doesn't even ping external servers to verify licenses or send metrics. You can confirm this with Wireshark in 30 seconds: all traffic stays inside the LAN.
Is it safe to use LocalSend for sensitive files?
The protocol uses TLS with locally generated self-signed certificates. There's no external CA verification, which means there's technically a MITM risk within the same network. For my use case — a controlled home network — I accept that. On a corporate network with unknown users around me, I'd think twice. The certificate is generated on first launch and you can manually verify the fingerprint between devices.
Does it work between Windows and Mac without extra configuration?
Yes, that's the simplest use case. Same Wi-Fi network, both apps installed, automatic discovery in seconds. That's where LocalSend shines with zero friction. The subnet problem only shows up in more complex environments.
What if devices are on different networks?
It doesn't work natively. You need a VPN that puts both devices on the same virtual network — Tailscale is the cleanest option for this. With Tailscale active, LocalSend runs over the mesh network as if it were LAN. It's extra setup, but once it's configured, it just works.
Does it have a CLI for automating transfers?
Not yet, not in a stable form. There are open issues in the repo requesting a CLI or headless mode, but as of this post none of it exists in production. For automation I'm still on rsync/scp. If the CLI lands, it changes the picture significantly for server use cases.
Does LocalSend completely replace AirDrop in an Apple ecosystem?
No. AirDrop has Bluetooth as a fallback, OS-level UI integration (right-click → share), and marginally faster speeds between nearby Macs. If you live 100% in Apple, there's no compelling reason to switch. If you have even one non-Apple device in the flow, LocalSend justifies the install.
Open source wins the argument, not always the friction
I mentioned earlier that I care a lot about what happens to my data when I use third-party tools. That concern grew when I started auditing services I'd been taking for granted — the Microsoft-OpenAI deal analysis made me review my own API consumption patterns (I wrote that up here), and the GoDaddy domain hijacking story sent me auditing every exposed surface in my own infra (I simulated it here). LocalSend fits that same logic: less surface area, less delegated trust.
My final position: LocalSend is installed on all my machines and I use it daily for the Mac→Linux case, which was the gap AirDrop was never going to fill. The VPN and subnet tradeoff is real — don't romanticize it — but it's a tradeoff I understand and can manage.
What I don't buy is the unqualified enthusiasm in the HN thread. "AirDrop killer" is a headline that scores points on HN, not a description of reality for someone running a corporate VPN half the workday. The tool is good. The hype is excessive. You can hold both of those things at the same time.
If you install it, configure the port in your firewall, change the device name, and disable previews. Three minutes of setup that save you the most common gotchas.
Using it in a corporate environment with separate subnets? Tell me how you solved it — genuinely curious whether there's a workaround that's not in the repo yet.
This article was originally published on juanchi.dev
Top comments (0)