Changelog

Received files are never overwritten, and Windows marks them as downloads

floe receive no longer overwrites an existing file that has the same name as an incoming one. The new file is saved with a numbered suffix before the extension (report.pdf, then report (1).pdf), the same way browsers de-duplicate downloads. The progress line shows the name actually written.
On Windows, received files are now tagged with the mark of the web (a Zone.Identifier stream), so SmartScreen and Office Protected View treat them like browser downloads when opened.
No transfer-protocol change, so this release interoperates with older CLI and browser peers in every direction.

2026-07-30

A self-hosting image fix. The CLI is unchanged.

Fixed the self-hosted web client re-encoding every image on every request instead of caching it. /app/.next was owned by root while the server runs as node, so the image cache could never be written. Pages rendered correctly throughout, which is why it went unnoticed: the only symptoms were wasted CPU on every request and an EACCES unhandled rejection in the container logs each time. This affects 1.9.0, and latest as it stood before this release.
To pick it up: docker compose pull then docker compose up -d. If you pinned FLOE_IMAGE_TAG=1.9.0, move to 1.9.1.
docker-compose.yml now defaults to the latest release rather than main, so a fresh install tracks releases instead of every merged commit. This could not ship in v1.9.0 itself: latest is created by the release, so a compose file inside that release could not have pointed at it. Set FLOE_IMAGE_TAG=main if you prefer to stay on main.
The CLI is identical to v1.9.0. It is republished only because the CLI and the container images share one version number, so a floe upgrade offered by Homebrew, Scoop, or winget changes nothing for you. There is no need to update it.
The smoke test that every image must pass before a tag points at it now asserts that a repeat image request is served from cache. The existing checks all passed while this was broken, since the response stayed a valid WebP with a 200 status, so nothing in it revealed the problem.
No transfer-protocol change, so v1.9.1 interoperates with older CLI and browser peers in every direction.

2026-07-30

Self-hosting without a clone, on any common hardware

Prebuilt images are published to ghcr.io/jannskiee/floe-server and ghcr.io/jannskiee/floe-client, and docker-compose.yml pulls them. A working instance is two commands: download the compose file, then docker compose up -d. No repository, no Node, no Go, nothing compiled locally. See Container Images.
Both images are published for linux/amd64 and linux/arm64, so Raspberry Pi, Oracle Ampere, AWS Graviton, and Apple silicon run exactly the same two commands. Docker selects the right architecture automatically.
A .env file is genuinely optional. Every setting has a working default.
Pin a version with FLOE_IMAGE_TAG, or pin a digest for a build that can never move.
Each architecture is built and smoke-tested on its own hardware, and a tag is published only after every architecture of both images passes, so a partly-built release is never visible. That matters because the image optimiser fails silently: when it cannot load it serves the original file rather than erroring, so a broken image would look healthy to anything that only checks whether the page loads.
The published client no longer emits canonical links, Open Graph images, or sitemap entries pointing at floe.one. A shared image cannot know which domain it will be served from, so it claims nothing rather than advertising somebody else’s site. To use your own domain, build the client with NEXT_PUBLIC_SITE_URL set.
Contributors build from source with docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build.
Both images move to Node 24, the Active LTS. The server was on Node 20, a Maintenance release.
CLI: floe version and the help text now point at floe.one/docs rather than the retired docs.floe.one, and the WebRTC stack moves to pion 4.2.18.
32-bit ARM (linux/arm/v7) is not published: Node dropped support for it and no prebuilt image-processing binaries exist.
No transfer-protocol change, so v1.9.0 interoperates with older CLI and browser peers in every direction.

2026-07-23

The 2 GB relay cap now applies to the CLI, plus honest receiver errors

floe send now enforces the same 2 GB relay session cap as the web app. Once the connection is established, the sender checks the selected route: if it runs through the TURN relay and the queued files total more than 2 GB, the transfer is blocked before any data moves, with a clear error. Direct connections keep no size limit, and a connection whose path cannot be determined is never blocked. See The 2 GB Relay Limit.
Fixed the receiver treating a sender that disconnected before the first file as a successful transfer: floe receive exited silently as if nothing was expected, and a multi-file batch interrupted between files was reported as complete. Both cases now end with a clear error describing what actually arrived.
CLI errors no longer print the full usage reference after the message. A failed transfer or an expired code now shows the one-line error alone.
No transfer-protocol change, so v1.8.0 interoperates with older CLI and browser peers in every direction.

2026-07-21

Stalled transfers now fail fast with clear errors

Fixed transfers freezing forever when the connection silently broke right after setup. The receiver now reports “connected, but no data arrived from the sender” within 30 seconds if the transfer never starts, and “transfer stalled” with exact byte progress if data stops flowing mid-file for a full minute, instead of sitting on a frozen progress bar until you press Ctrl+C. These stalls are rare, but when one happened there was no way to tell it apart from a slow transfer.
Fixed floe send waiting up to two minutes after the receiver declined the transfer or exited. It now reports “connection closed while waiting for the receiver” in about a second.
Web app: the share link now appears only once the server has confirmed your room. This closes a rare race where a receiver that followed the link extremely quickly could be mistaken for the sender and fail with a role error.
Updated the CLI’s WebRTC stack (Pion) to the current releases.
No transfer-protocol change, so v1.7.6 interoperates with older CLI and browser peers in every direction.

2026-07-10

Accurate progress on slow connections, and a CLI relay fix

Fixed the sender’s progress running far ahead of the receiver. The sender counted bytes handed to the connection’s send buffer rather than bytes that actually reached the other side, so on slower or relayed connections its bar raced ahead by up to 8 MB, froze for up to a minute while the buffer drained, moved to the next file before the receiver finished the previous one, and showed “All Files Sent!” while the receiver was still downloading. The sender now reports delivered bytes: both sides move together at the real network speed, the file counter stays in step, and completion means the receiver has everything.
Fixed the receiver’s progress bar barely updating since the larger transfer blocks introduced in v1.7.3. It could sit still for minutes on slow connections (and never move at all for files under 6.25 MB), which looked like a stalled transfer. It now updates at least every 1 MB regardless of block size.
Fixed floe send giving up with a “backpressure stall” error on relayed connections slower than roughly 70 KB/s. The CLI now aborts only when the connection makes no progress at all for a full minute, instead of whenever draining simply takes longer than a minute.
Web app: the connection badge tooltip and the Network Relay Fallback description now explain that direct peer-to-peer connections are the norm even across different networks such as mobile data, and that the relay is only a fallback used when a direct path cannot be established.
No transfer-protocol change, so v1.7.5 interoperates with older CLI and browser peers in every direction.

2026-07-10

Faster connection setup

Fixed connections taking 20 to 30 seconds to establish on machines running VPN or virtual machine software (Tailscale, VMware, WSL, Hyper-V). Two causes were addressed: the signaling server handed every client a redundant list of eight relay endpoints where three suffice, and the CLI probed dead auto-configuration network interfaces during setup. The server-side fix is already live and speeds up all existing versions, browser included; this release adds the CLI-side hardening so connections stay fast against any server, including self-hosted ones.
Added an advanced --iface flag to restrict the CLI to specific network interfaces by name (for example --iface Ethernet), useful for pinning a transfer to a chosen network. Most users never need it. See the flags reference.
Web app: opening a fresh share link in a tab that already had Floe open now joins the new room correctly instead of reusing the old session.
No transfer-protocol change, so v1.7.4 interoperates with older CLI and browser peers in every direction.

2026-07-09

Faster CLI transfers, and a browser-to-CLI reliability fix

floe send now sends file data in larger blocks, sized to what the connection negotiates (up to 256 KB) rather than a fixed 16 KB. On fast paths such as a local network or a direct connection, this removes most of the per-block overhead and noticeably increases throughput. Relayed or slower connections are unaffected, since their speed is set by the link rather than the block size.
Fixed browser-to-CLI transfers that could fail with a timeout when the person running floe receive took more than 15 seconds to accept the incoming files at the prompt. The browser now waits as patiently as the CLI already did.
No transfer-protocol change, so v1.7.3 interoperates with older CLI and browser peers in every direction.

2026-06-30

CLI: share links keep the room secret in the URL fragment

floe send now prints a https://floe.one/#room=<id> link. The room id sits in the URL fragment (after the #), which a browser never sends to the web server, never puts in the Referer header, and never exposes to pageview analytics. Previously it was a ?room= query parameter that could reach those places when a recipient opened the link in a browser. This brings the CLI in line with the web app.
floe receive resolves a #room= link, a legacy ?room= link, or a short code, so links shared by any version keep working.
No transfer-protocol change, so v1.7.2 interoperates with older CLI and browser peers in every direction.

2026-06-22

Reliable global-counter reporting for the CLI

Fixed CLI transfers not always being counted in the global homepage counter. The receiver’s byte-count report was sent in the background and could be cut short when the sender closed the connection and the process exited, so larger transfers (several GB and up) were frequently missed and smaller ones counted only intermittently.
The report now completes before the program exits, so a successful CLI transfer of any size contributes exactly once. The report still carries only the byte count (never file names or contents), still never blocks or slows the transfer, and opting out with --no-report or FLOE_NO_STATS=1 is unaffected.
Browser transfers were never affected by this issue.

2026-06-22

Global transfer counter with opt-out

Added a public, all-time counter of total bytes transferred across every Floe user, shown on the homepage with a rolling-number animation. The number rolls up from zero on each visit and ticks higher as transfers complete worldwide.
The counter is fed without ever touching your files. After a transfer finishes, only the receiving side reports the byte count (never file names or contents). The sender never reports. The stored value is a single anonymous total, not linked to any user, transfer, or IP address. See Security and Privacy for the full data-handling note.
The CLI receiver now contributes to the global counter. The total is viewable only in the browser; the CLI never fetches or displays it.
Both the browser receiver and the CLI receiver support opting out. Browser: uncheck “Contribute to global stats” on the receiver view (saved to your browser). CLI: pass --no-report to floe receive, or set FLOE_NO_STATS=1 in your environment for a permanent opt-out. The transfer is unaffected either way.
Self-hosters can opt in by pointing the server at a free Upstash Redis database (UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN). Without it, the counter still works but resets on restart. See Configuration.

2026-06-22

Protocol version negotiation

Added a wire protocol version that the sender and receiver exchange when a transfer starts. It is separate from the release version (1.6.x), so peers on different releases still transfer normally. A patch or minor difference such as v1.5.4 and v1.5.5 is never a conflict and is never blocked.
If a future release ever changes the wire format in a breaking way, the two sides now detect it before any file data moves and print a clear “your floe is too old, run floe update” message (or “ask the other side to update”) instead of failing with a confusing error or a corrupt file.
Works in every direction: CLI-to-CLI, browser-to-CLI, and CLI-to-browser. Older peers that predate this change are treated as the baseline protocol and stay fully compatible.

2026-06-21

floe update permission fix

Fixed floe update failing with “permission denied” when floe is installed in a root-owned directory such as /usr/local/bin on Linux and macOS. The updater now downloads and extracts as the current user, installs directly when the location is user-writable (for example ~/.local/bin), and automatically requests sudo only for the final atomic swap when it is not. To upgrade from an older version one time, run sudo floe update; after that plain floe update works.

2026-06-21

CLI progress bar fix

Fixed the transfer progress bar printing a new line for every percentage on narrow or Windows terminals. The bar now sizes itself to the terminal width so the line never wraps, and it updates in place on a single line per file.

2026-06-21

Installer and self-update download fix

Fixed a 404 when installing or updating floe. The install scripts (install.sh, install.ps1) and the built-in floe update requested the release archive with a leading “v” in the version (for example floe_v1.5.2_linux_arm64.tar.gz), but the published asset name omits it (floe_1.5.2_linux_arm64.tar.gz). All download paths now use the correct filename. This affected every platform and architecture, including Raspberry Pi (linux/arm64).

2026-06-17

CLI stability fix

Fixed a rare concurrent-write panic in the CLI signaling client. Rapid ICE candidate negotiation could trigger simultaneous WebSocket writes from separate goroutines; all writes are now serialized.

2026-06-17

CLI output improvement

The Sending summary line (file name and total size) now appears above the sharing box, so you can see what is being sent before the peer connects.

2026-06-17

File summary on both sides

Both the sender and the receiver now see a file count and total size before and after the transfer. Example: Sending 3 files · 11.8 MB on the sender side and Incoming 3 files · 11.8 MB on the receiver side.

2026-06-17

CLI-to-CLI transfer fix

Fixed an error reported by the CLI sender after a successful CLI-to-CLI transfer. The transfer completed correctly but the sender exited with an error code. It now exits cleanly.

2026-06-17

One-command install and self-update

floe update now works on all platforms (script installs, manual installs). It downloads, verifies, and replaces the running binary in one step.
Re-running the install script (curl -fsSL https://floe.one/install.sh | sh or irm https://floe.one/install.ps1 | iex) also upgrades an existing install in place.
If floe was installed via Homebrew, Scoop, or Winget, floe update detects this and prints the correct package manager command instead.
Security: updated ws, esbuild, and postcss transitive dependencies to address published advisories.

2026-06-16

Rich transfer summary

At the end of each transfer, the CLI now prints a boxed summary with the total data transferred, elapsed time, and average speed. Example:

  ─────────────────────────────────────────────────
  Sent   3 files (11.8 MB)
  Time   8s · avg 1.4 MB/s
  ─────────────────────────────────────────────────

The receiver summary also includes the Saved to path.

2026-06-16

Transfer reliability and browser fixes

Fixed several CLI transfer sync bugs that could cause stalled or incomplete transfers, especially in CLI-to-CLI sessions. Added cross-implementation loopback tests to prevent regressions.
Fixed a browser receiver bug where a Buffer view was retained across chunk boundaries instead of being copied, which could corrupt received data.
Fixed an issue where the in-app browser detection could steal the receiver slot from a legitimate peer, preventing the transfer from starting.
Fixed duplicate WebRTC signal handling that could break transfers after a reconnect.
Redesigned the in-app browser warning page for clarity.
Upgraded the CLI to Pion WebRTC v4 (includes Pion DTLS v3).
Performance: improved browser-to-browser transfer throughput with better backpressure tuning.

2026-06-14

Initial public release

Browser-based peer-to-peer file transfer at floe.one. No account, no installation, no file storage.
floe CLI for macOS, Linux, and Windows. Fully interoperable with the browser client.
End-to-end DTLS encryption on all transfers, direct and relayed.
Optional TURN relay fallback for peers behind strict firewalls or carrier-grade NAT (capped at 2 GB per session).
Self-hosting support via Docker Compose. See Self-Hosting.
Mintlify documentation site at docs.floe.one.

Getting Started

Web App

CLI

Self-Hosting

How It Works

Reference