# LocalSend needs port 53317 open, a router without AP isolation, and you to update it yourself

> LocalSend moves files and messages between nearby devices over the local network with no central server, using a REST API and HTTPS. The transport is the easy part; the two settings that actually break a transfer are a firewall rule and an AP isolation flag most routers leave off by default.

**localsend/localsend** — LocalSend transfers files and messages between nearby devices over the local network without a central server.

- Repository: https://github.com/localsend/localsend
- Website: https://localsend.org
- Stars: 92,990 · Forks: 5,197
- Language: Dart
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/localsend-localsend

## Port 53317 on TCP and UDP, and the router flag that breaks transfers more often

LocalSend talks to nearby devices over the local network using a REST API with HTTPS encryption, with no third-party server and no internet connection involved. Discovery and transfer both go through one port, and the setup section is a two-row table: incoming traffic on TCP and UDP port 53317 must be allowed, outgoing traffic on TCP and UDP may use any port. On Linux that is a handful of commands:

```bash
sudo ufw allow 53317
sudo firewall-cmd --permanent --add-port=53317/tcp
sudo firewall-cmd --permanent --add-port=53317/udp
sudo firewall-cmd --reload
```

The second requirement is the one that catches people, and it is not a firewall at all. AP isolation has to be disabled on your router. It is usually off by default, but some routers enable it, particularly on guest networks, and the effect is that two devices on the same wireless network cannot see each other at all.

The consequence for a user is a transfer that fails in a way that looks like a broken app rather than a network policy. Both devices are on the same network, the app is running on both, and nothing is wrong with either installation, because the router is refusing to bridge the two clients. If discovery finds nothing, check guest network membership and AP isolation before anything else, because no amount of firewall work on the hosts will fix it.

## There is no auto-update, so the app store is the update path

The project recommends downloading from an app store or a package manager for one reason, stated plainly: the app does not have an auto-update. There is no update check to rely on and no silent upgrade.

That turns the distribution table into a maintenance decision rather than a list of links. Windows is covered by Winget, Scoop and Chocolatey, plus an EXE installer, a portable ZIP and a DMG. macOS has the App Store and Homebrew. Linux has Flathub, Nixpkgs, Snap, the AUR, and standalone TAR, DEB and AppImage artifacts. Android has the Play Store, F-Droid and an APK, and iOS and Fire OS have their stores. Only the store and package-manager routes give you an upgrade path; an EXE, a ZIP or an AppImage is a version you will be stuck on until you replace it by hand.

The platform floors make this sharper, because they do not fall at the same version. Android needs 7.0, and v1.17.0 was the last release to support Android 5 and 6. iOS needs 13.0, and v1.17.0 was the last to support iOS 12. Windows needs 10, and v1.15.4 was the last to support Windows 7. macOS needs 11 Big Sur, with OpenCore Legacy Patcher 2.0.2 named for older hardware. So a household with a recent phone and an old laptop is running two app versions years apart, and the repository does not document a minimum version one device must have to send to another. Current releases are v1.18.2, v1.18.1 and v1.18.0, from August 2026.

## Portable Mode is a settings.json sitting next to the executable

Introduced in v1.13.0, Portable Mode is the mechanism for running LocalSend from a USB stick or any location you control. You create a file named `settings.json` in the same directory as the executable, and that file can be empty. The app picks it up from there.

The whole feature is that one file and its location, which is worth stating plainly because it means the mode has no registry entry, no environment variable and no flag. For a USB stick that is exactly right: the executable and its configuration travel together, and there is nothing to install on the machine you plug into.

The consequence is that the mode is keyed on file position rather than on intent. Move the executable somewhere else without moving `settings.json` and the app simply starts with its defaults, with no error to tell you the portable configuration was left behind. The README does not document which settings the file can contain, so a reader who wants to change anything beyond enabling the mode has to find it elsewhere. Treat the file as a marker, keep it beside the binary, and do not expect it to carry configuration you have not seen documented.

## Dart for the app, Rust for the crypto and the CLI, and a dev profile tuned for speed

The primary language is Dart, and the Flutter side is visible in `pubspec.yaml`, `pubspec.lock` and `.fvmrc`. But the repository also contains a Cargo workspace, and `Cargo.toml` is not incidental. Its members are `cli`, `packages/core`, `packages/localsend_isolates/rust` and `server`, which is where the command line interface and the server component come from.

Two entries in that file are worth reading before you build anything. The dev profile sets `debug = "line-tables-only"`, with a comment noting that full debuginfo dominates the size of the target directory while line tables keep backtraces usable. And two crypto crates are pinned to `opt-level = 2` even in dev, because RSA key generation is bignum-heavy and takes roughly ten times longer when left unoptimized.

The consequence is that contributing means building two toolchains, a Flutter one pinned by `.fvmrc` and a Rust one pinned by `rust-toolchain.toml`, and that the dev profile looks wrong until you know why. A contributor who removes the `opt-level` overrides as redundant will make the test suite about ten times slower without any visible failure, since nothing is broken, only slow. Anyone planning to run the server or the CLI needs the Rust side specifically, because that is where those entry points live.

## Windows binaries are signed, and the newest Windows build is third-party

Code signing is handled explicitly. Windows binaries are signed, and the repository carries a `CODE_SIGNING.md` with the written policy behind it, alongside a `CONTRIBUTING.md` that documents the distribution channels in detail. That is a better answer than most projects give about how a downloaded installer got there.

The exception is the newest code. A caution notice points at localsend.ob-buff.dev for an unofficial MSIX preview built from the latest commits, and states two things about it: stability is not guaranteed, and all custom code tweaks are listed on that site. Windows is also the only platform with an unofficial preview channel called out this way.

The consequence is a genuine supply chain decision sitting in the README. To run the current development commits on Windows you have to install a package built and published by somebody outside the project, carrying modifications that the project itself has catalogued but not authored. That is a reasonable thing for a project to offer, and it is not the same trust relationship as a signed release. If you are deploying LocalSend to a managed Windows fleet, take the signed EXE installer or a package manager entry and accept the version you get; if you are experimenting on one machine, the preview is a reasonable way to see changes before they ship.

## Linux needs a desktop portal package, and the right one depends on your toolkit

Linux is the only platform with a documented runtime dependency, and it is split by desktop environment rather than version. On Gnome you need `xdg-desktop-portal` and `xdg-desktop-portal-gtk`. On KDE you need `xdg-desktop-portal` and `xdg-desktop-portal-kde`. The minimum version column for Linux reads N.A. rather than naming a release.

The consequence is that a Linux install can be correct in every visible way and still not behave properly, because the portal backend is what the app uses to integrate with the desktop, and installing the wrong flavour leaves it without the integration it expects. A Gnome user who installs the KDE backend has a package that looks right and is not.

This is also the platform where the choice of channel matters most, since there are five package routes plus three raw artifacts. Flathub, Nixpkgs, Snap and the AUR all carry dependency declarations that will pull the portal package in for you, whereas the AppImage bundles what it can and cannot express that dependency. If you are on Linux and something is subtly wrong with how the app presents itself to the desktop, check which portal backend is installed before looking anywhere else.

## Conclusion

LocalSend is the right choice when you want to move a file to the phone next to you without an account, an upload or a server you have to trust, and on a network you control it works out of the box. It is the wrong choice on a guest network, behind a router with AP isolation on, or anywhere you have already been told port 53317 cannot be opened. Before you rely on it, check the platform floor for your oldest device, because Android below 7.0, iOS below 13.0 and Windows below 10 are all dropped at different past versions, and install from an app store or package manager rather than a portable archive since the app has no auto-update.

## FAQ

### Is LocalSend a safe app?

LocalSend is a free, open-source app under the Apache-2.0 licence that shares files and messages over your local network using a REST API and HTTPS encryption, with no third-party server and no internet connection required. Windows binaries are signed and the repository carries a written code signing policy.

### What is LocalSend used for?

Sending files and messages to nearby devices over the local network. The project describes it as a cross-platform app for secure communication between devices, positioned against messaging apps that depend on external servers, and the repository also carries a command line interface and a server component alongside the desktop and mobile apps.

### How do I install LocalSend on Linux?

Linux packages come through Flathub, Nixpkgs, Snap and the AUR, or as standalone TAR, DEB and AppImage artifacts. The project recommends an app store or package manager because the app has no auto-update. Linux also needs a desktop portal backend, xdg-desktop-portal-gtk on Gnome or xdg-desktop-portal-kde on KDE.

### How fast is LocalSend?

The project does not publish transfer speed figures. What it states is that transfers run over the local network with no internet connection or third-party server, and the only performance cost called out anywhere in the repository is RSA key generation, described as taking roughly ten times longer when left unoptimized.

### Can I use LocalSend without Wi-Fi?

It does not depend on Wi-Fi as such, it needs both devices on the same local network, wired or wireless. The setup requires allowing incoming TCP and UDP traffic on port 53317 and disabling AP isolation on your router, which is frequently enabled on guest networks and stops devices from discovering each other.

## Sources

- [Official documentation](https://localsend.org)
- [Official README](https://github.com/localsend/localsend#readme)
- [Project repository](https://github.com/localsend/localsend)
- [Release notes](https://github.com/localsend/localsend/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/localsend-localsend