Changelog

Floe ships on two version lines. vX.Y.Z releases floe.one, the floe CLI, and the server you can run yourself. desktop-vX.Y.Z releases Floe Desktop for Windows. The two never need to match, and no release so far has changed the transfer protocol, so every version of Floe sends to and receives from every other one. Each entry lists the parts it changed. Filter on the right to see only the ones you use.

DesktopCLI

2026-08-19

A killed transfer never leaves a half-written file looking finished, closing mid-transfer asks first, and Send with Floe keeps every file

A received file is now written under a temporary name ending in .part and takes its real name only once every byte has arrived. Before this, closing the window, ending the app from Task Manager, or losing power partway through left the unfinished file in your folder under its final name, looking complete. Now the worst that can remain is a .part file, which is safe to delete.
Closing the window during a transfer asks first. A new prompt offers Keep going or Close anyway, so one stray click on the close button no longer cuts a transfer off for both sides with nothing on screen.
Send with Floe on several files at once now sends all of them. Windows starts Floe once for each file you select, and files that arrived before the window finished loading used to be silently dropped, so a five-file selection could send only one. Every selected file now lands in the same window.
The file name that is shown and the one that is saved stay in step even when a name collision is only discovered as the file finishes, so Open and Show in folder always act on the file you actually received.
No transfer-protocol change, so Floe Desktop 0.2.7 transfers with browser and CLI peers in every direction.

CLISelf-hosting

2026-08-19

Received files are written under a temporary name and only renamed when complete, so a killed transfer never leaves one looking finished

floe receive now writes each file under a temporary name ending in .part and renames it to its final name only after every byte has arrived and been verified. A transfer killed outright, or a machine that loses power partway through, can no longer leave a half-written file under a finished-looking name; the worst that remains is a .part file, safe to delete. On Windows the final rename is atomic; on macOS and Linux a crash at the exact instant of completion can leave an empty placeholder beside the intact .part.
Ctrl+C removes the in-flight .part file on the way out, so a canceled receive leaves the output directory clean.
The fix is on the receiving side. A transfer is protected once the receiving end is running floe 1.10.4 or Floe Desktop 0.2.7; sending from an updated build to a peer that has not updated is unchanged.
Self-hosting: the published images are rebuilt as 1.10.4. This release only touches the receive path the CLI and desktop app share, so there is nothing you need to do; pull when convenient. If you pinned FLOE_IMAGE_TAG=1.10.3, move to 1.10.4.
The wire protocol is unchanged, so v1.10.4 still speaks to older CLI and browser peers in both directions.

Desktop

2026-08-19

Files whose names Windows cannot hold now arrive intact instead of arriving empty

A file sent from a Mac or a Linux machine can carry a name Windows has no way to store. A timestamp like backup:2026-08-19.log is the everyday case, because Windows gives the colon a special meaning. Floe used to write that file, report success, and leave you an empty file called backup, with the contents routed somewhere you would never find them. Names like what?.txt were worse still: the file could not be created at all, and the error ended the rest of the batch, so files queued behind it never arrived.
Incoming names are now adjusted before the file is written. The characters < > : " | ? * become underscores, trailing dots and spaces are removed, and a name that is a reserved device name such as NUL gets an underscore in front. The progress line and Show in folder both use the adjusted name, and two files that end up with the same adjusted name are numbered the way colliding names always have been.
A file named with a trailing space used to lose its mark of the web, the tag that makes Windows treat a received file as downloaded from the internet. The tag attached to the wrong name and the saved file kept none, so SmartScreen and Office Protected View stayed out of the way on a file a stranger sent you. Received files are now tagged correctly whatever they are called.
Control characters and text-direction marks are removed from incoming names on every platform. A text-direction mark can make photo followed by a reversed exe.png read as an image in the file list while the file on disk is a program.
Folder sends keep their structure. Each part of the path is adjusted on its own, so a folder that needed adjusting stays a folder.
No transfer-protocol change, so Floe Desktop 0.2.6 transfers with browser and CLI peers in every direction.

CLIWebSelf-hosting

2026-08-19

Received files that a system cannot store, and browser downloads that were never complete, no longer pass as finished

floe receive adjusts an incoming file name that the receiving system cannot represent, instead of writing it and reporting success. On Windows a name like backup:2026-08-19.log used to leave an empty file called backup, a file called NUL left nothing at all, and a name containing ? could not be created and ended the rest of the batch. macOS and Linux keep names exactly as sent, since all of those are valid there.
On Windows, a received file named with a trailing space used to lose its mark of the web, so SmartScreen and Office Protected View did not apply to it. That tag now attaches correctly whatever the file is called.
Control characters and text-direction marks are removed from incoming names on every platform, and the receiver refuses to write onto a device rather than discarding the contents silently.
The fix is on the receiving side. A transfer is protected once the receiving end is running floe 1.10.3 or Floe Desktop 0.2.6; sending from an updated build to a peer that has not updated is unchanged. Both surfaces ship the fix in this pair of releases.
Web app: a file that arrived incomplete is no longer offered as a finished download. The browser labeled each file with however many bytes turned up rather than the number the sender announced, so the two could never disagree and a file cut short still showed a checkmark and a working download button. It is now checked against the announced size and refused if it does not match, and a short count is no longer added to the public transfer counter.
Web app: sending a file that becomes unreadable partway through, because it was moved, renamed, or sat on a drive or cloud folder that went away, now reports the failure instead of telling both sides the file finished.
Web app: file names chosen by the sender are cleaned before they are used to name a download or an entry in a ZIP, so a name cannot describe a path or quietly drop a file from the archive.
Web app: a transfer blocked by the 2 GB relay cap now closes the connection and explains itself, instead of leaving the other side waiting with nothing on screen.
Self-hosting: the published images are rebuilt as 1.10.3 and carry the web app changes above. To pick them up: docker compose pull then docker compose up -d; if you pinned FLOE_IMAGE_TAG=1.10.2, move to 1.10.3.
The wire protocol is unchanged, so v1.10.3 still speaks to older CLI and browser peers in both directions.

Desktop

2026-08-16

Empty a staged selection in one click, and a fix for transfers that connected but never started

A Clear button now sits beside Send on the send card. It empties whatever the tab you are on is holding, the file list on Files or the box on Text, and leaves your settings, the Receive tab, your history and the files themselves alone. It appears only when there is something to clear, and steps aside for Cancel while a send is running.
Clear does not ask first. It offers Undo instead, in a bar at the bottom of the window that puts back exactly what you had staged, whitespace and all. The bar shows for about ten seconds, longer while you point at it or reach it with the keyboard.
The undo outlasts the bar. Ctrl Z still takes it once the bar has gone, and it stands until you put something new on that same tab, clear something else, or start over. Switching tabs, opening Settings or checking History only puts the bar away, and it comes back when you do. Like the app’s other shortcuts, Ctrl Z waits while the cursor is in a text box.
Start over now asks before discarding a note you have cleared, the same way it already asks about a note you typed but never sent.
Fixed transfers that connected and then moved nothing: both ends showed a healthy connection, then sat silent until a timeout blamed the other side. The very first message of a transfer could be dropped before the receiving app was listening for it. The odds turn on the round trip between the two peers, so it was rare across a network and common between two Floe apps on one machine. The fix is on the receiving side, so a transfer is protected once the receiving end is running Floe Desktop 0.2.5 or floe 1.10.2. Sending from this build to a peer that has not updated is unchanged.
Every row in History is now a single button that opens and closes the row, with one chevron in the same place on every row. The opened row carries the file names, and for a received transfer where it was saved plus a Show in folder action; every row carries Remove. Finishing a transfer no longer shifts which row is open, because a new entry goes on top and the open row used to be tracked by position.
The dashed borders on the drop area read as soft white now and brighten when you point at them. The blue is kept for the highlight that appears while you are actually dragging files over the window.
Turning off animations in Windows now stops the app’s own animations. The setting was being ignored, so the update notice, the Settings panel, tooltips, the connection dot and the new undo bar all moved anyway.
The focus outline on buttons is brighter, so it is easier to see where the keyboard is.
No transfer-protocol change, so Floe Desktop 0.2.5 transfers with browser and CLI peers in every direction.

CLISelf-hosting

2026-08-16

Fixed transfers that connected and then moved nothing

A transfer could reach the point where both ends reported a healthy connection and then never start, ending 30 seconds later with connected, but no data arrived from the sender on one side and a message blaming the receiver on the other. The very first message of a transfer could be dropped before the receiving side was listening for it, and because the network layer had already accepted that message, nothing ever resent it.
The window is microseconds wide and closes as the round trip between peers grows, so it was rare between two machines and common between two Floe processes on one machine. It has been there since the first release.
The fix is on the receiving side. A transfer is protected once the receiving end is running floe 1.10.2 or Floe Desktop 0.2.5; sending from an updated build to a peer that has not updated is unchanged. Both surfaces ship the fix in this pair of releases.
Self-hosting: the published images are rebuilt as 1.10.2 with nothing of their own changed, since this release only touches the transfer engine the CLI and the desktop app share. There is nothing you need to do; pull when convenient.
The wire protocol is unchanged, so v1.10.2 still speaks to older CLI and browser peers in both directions. That is a statement about compatibility, not about the bug above, which is fixed for whichever end is running the new build.

Desktop

2026-08-14

A cleaner update notice, and the main screen says precisely what happens to your files

The update notice is redrawn as a slim one-row frosted bar with a whisper of ice in its border. What it does is unchanged.
The main screen’s subline now promises “no uploads” instead of “no middleman”. A relayed transfer does pass through a relay, so the old word claimed too much; nothing is uploaded on any path.
No transfer-protocol change, so Floe Desktop 0.2.4 transfers with browser and CLI peers in every direction.

CLIWebSelf-hosting

2026-08-14

Failed or stalled receives clean up their partial file

floe receive no longer leaves a half-written file behind under its final name when a transfer fails or stalls. The partial is deleted, files that completed earlier in the batch are kept, and a retried transfer gets its original name back instead of a numbered one.
The protocol-incompatibility message the CLI sends across the wire is now worded from the reader’s perspective, so older versions that display it word-for-word name the correct side. No release can trigger this today (every peer speaks the same protocol).
Web app: the navbar now adapts to window width in three steps instead of two, and the Download link is visible at every size; it previously appeared only on wider windows, so the header offered no way to reach the desktop app’s download page on a phone.
Web app: floe.one and the docs now share the same four-column footer (Product, Documentation, Project, Legal), and it appears on every page of the site rather than only the homepage and the download page.
Web app: fixed the docs pages showing outdated content that a reload could not refresh; an offline cache was keeping old copies forever, and they now clear automatically on your next visit.
Self-hosting: the published images carry every web-app change above plus updated dependencies (Next.js 16.3.0 and ws 8.21.2). To pick them up: docker compose pull then docker compose up -d; if you pinned FLOE_IMAGE_TAG=1.10.0, move to 1.10.1.
No transfer-protocol change, so v1.10.1 interoperates with older CLI and browser peers in every direction.

Desktop

2026-08-13

Failed transfers clean up after themselves and speak plainly, and Start over stops losing notes

A receive that fails or is cancelled partway no longer leaves a half-written file behind under its final name. The partial is deleted, files that completed earlier in the batch are kept, and a retried transfer gets its original name back instead of a numbered one.
The Receive card now shows what is incoming (the file name and size, or the file count and total) the moment the sender is known, before the first byte arrives.
A failed receive now raises a Windows notification like a failed send always did, and cancelling a transfer no longer raises a false “send failed” one.
Transfer errors are now written for people (“The connection was lost before the transfer finished. Start it again.”) instead of surfacing the engine’s internal wording. Genuinely unknown failures still show the raw text so bug reports stay useful.
Cancelling a transfer and immediately starting another no longer lets the dead attempt interfere: its late events are ignored, it can no longer release the keep-awake lock the new transfer holds, and Cancel always reaches the transfer that is actually running.
The app now checks GitHub once a day for a newer desktop release and shows a small dismissible notice when one exists, with a matching row in Settings under About. GitHub-channel builds only: the Microsoft Store build never checks, because the Store updates it itself. Nothing downloads or installs by itself. A new Check for updates switch in Settings under Privacy turns the check off, and off means no request is made at all.
Protocol-incompatibility messages now name the remedy for the surface you are on: the desktop app points at the Microsoft Store or floe.one/download instead of the CLI’s floe update, and the message sent across the wire is worded from the reader’s perspective, so older versions that display it word-for-word name the correct side. No release can trigger this today (every peer speaks the same protocol); it prepares the messaging for any future wire change. Contributed by the project’s first external code contributor.
Fixed Start over still discarding a typed note without asking, in the two cases the 0.2.2 fix missed. Typing a new note after a send completed, and typing a note then switching to Files and sending those instead, both left text in the box that had never gone anywhere, and both were cleared with no prompt. Floe now compares the box against what the last completed send actually put on the wire, so a note only counts as sent while it is still exactly the note that went out. Tidying up after a send with the sent note still in the box is unchanged and still silent, as is starting over while a connection is being set up.
Fixed a failed transfer leaving its progress bar frozen on screen underneath the error, on both the sending and the receiving side.
Fixed Start over offering to cancel a transfer that had already failed. The stale progress bar above was also what the confirmation read, so after a failure it warned about cancelling a transfer that was already over, and that warning hid the one about the unsent note behind it.
No transfer-protocol change, so Floe Desktop 0.2.3 transfers with browser and CLI peers in every direction.

CLIWebSelf-hosting

2026-08-08

Stalled transfers now fail with a reason, and received files are never overwritten

floe send and floe receive no longer wait forever when a connection half-forms. Waiting for the peer’s offer or answer is capped at 30 seconds, establishing the connection at 30 more, with a 10 second grace for the data channel once the peers are otherwise connected. Each says which stage gave up: timed out waiting for the peer's offer, timed out establishing a connection, connected but the data channel did not open. None of this limits how long a sender waits for a receiver to arrive, which is still unbounded, so sharing a code and walking away works exactly as before.
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.
FLOE_SERVER and FLOE_WEB set the server and web addresses for every command, so a self-hosted setup no longer repeats --server on each one. An explicit flag still wins over the environment.
A trailing slash on a self-hosted server address no longer kills the transfer. --server https://example.com/ built https://example.com//api/code, which answers 404, and that 404 was swallowed into a silent fall back to public STUN, so a relayed transfer failed with nothing to explain it. Surrounding whitespace and any run of trailing slashes are now trimmed.
A receive code that has already been used says this code is no longer active; ask for a new one. It used to report an unexpected role, which described the internals rather than the situation.
Web app: session replay is gone from floe.one. Recordings masked all text and media, so file names and contents were never captured, but a recording reported the page address, and a receiver’s address carries the room link. That link is the only thing protecting a transfer. It is now stripped from error reports and breadcrumbs too.
Web app: the analytics script no longer receives the room link either. It reported the full address on page load, so a receiver opening a share link handed the room secret to a third party. It now sees the path alone.
Web app: floe.one sends a content security policy that refuses to be framed, alongside X-Content-Type-Options, Referrer-Policy, Permissions-Policy and HSTS.
Self-hosting: the published images run Node 24, the Active LTS, again. A dependency update had moved them to Node 25, which reached end of life on 2026-06-01 and will receive no further security patches.
Self-hosting: the signaling server no longer returns a stack trace when a request fails. It answers with a plain JSON error instead.
Self-hosting: the room-code word list is deduplicated and extended to 288 unique words. Thirteen words appeared twice, which made some phrases likelier than others and left only 275 distinct ones.
No transfer-protocol change, so v1.10.0 interoperates with older CLI and browser peers in every direction.

Desktop

2026-08-08

A redrawn app icon, and two things that used to fail silently

The app icon is redrawn to match the mark on floe.one: a larger bolt with rounded corners, at the proportions the website already used. The squircle keeps its depth, which the flat website favicon has no use for.
On a Store install, Windows no longer draws a coloured square behind the icon on the taskbar, in Start, in search and in Alt+Tab. The package was missing the unplated icon assets Windows looks for, so it fell back to plating the icon; 0.2.1 only changed what colour that square was. Installs from GitHub were never affected.
Fixed the app exiting without a word when it could not start. Release builds have no console, so a failure before the window appeared killed the process in silence. The one cause you can act on is a missing WebView2 runtime that Floe could not download, offline or behind a filtering proxy, and that now raises a message box naming it. Failures raised inside the window toolkit itself can still end the process quietly.
Fixed Start over throwing away a typed note without asking. Ctrl R is now ignored while the cursor is in a field, and starting over from idle asks first when a note is waiting to be sent. It stays silent while a connection is being set up, and just after a send, on purpose: Start over is the way out of a connection that will not settle. Staged files are still cleared without a prompt, since the files themselves are untouched on disk.
Corrected the encryption note in the sidebar. Floe’s data channel is secured by DTLS; the note also credited SRTP, which protects the audio and video streams that Floe never sends.
No transfer-protocol change, so Floe Desktop 0.2.2 transfers with browser and CLI peers in every direction.

Desktop

2026-08-02

A darker tile behind the Store icon

On a Microsoft Store install, the square Windows drew behind the Floe icon took the system accent colour, which is a bright blue on a default Windows setup. It is now the brand dark, so the tile reads as one piece with the icon. Removing that square altogether came later, in 0.2.2.
The installer and portable zip published under this tag behave exactly as 0.2.0 does. The change lives in the Store package manifest, so there is nothing to gain by downloading them.
No transfer-protocol change, so Floe Desktop 0.2.1 transfers with browser and CLI peers in every direction.

Desktop

2026-08-02

Floe Desktop arrives on the Microsoft Store

Floe Desktop is now on the Microsoft Store. Microsoft re-signs the package, so it installs with no “unknown publisher” warning and updates itself in the background. This is the recommended way to install it.
The installer and portable zip on GitHub continue in parallel and are not going away. They serve machines without Store access, and they are the fallback if a Store update ever goes wrong. Those builds are unsigned, so Windows still warns on first run.
The Show in right-click menu setting is hidden on a Store install, along with the Windows section of Settings that contains it. A packaged app’s registry writes land in a private view that File Explorer never reads, so the entry could be written but would never appear. The GitHub build still offers it.
Both builds keep their settings in the same place, so switching between them, or between the desktop app and the floe CLI, keeps your server address and preferences.
Desktop releases carry their own desktop-vX.Y.Z numbers, separate from the vX.Y.Z tags that release the CLI and the server. The two lines never need to match.
No transfer-protocol change, so Floe Desktop 0.2.0 transfers with browser and CLI peers in every direction.

Desktop

2026-08-01

Floe Desktop, the first beta

A native Windows app, and the third way to use Floe alongside the web app and the CLI. It runs the same transfer engine as the CLI, so it sends to and receives from browser peers and CLI peers with no extra setup. See Floe Desktop.
Send files, whole folders without zipping, or a typed note. Add them with the picker, by dropping them anywhere on the window, or with Ctrl V for files copied in File Explorer and for screenshots straight off the clipboard.
Receive with a room code or a share link, choose where files land, then open the file or reveal it in File Explorer. Nothing is ever overwritten, and received files are tagged as downloads so Windows applies its usual caution.
A local history of the last 50 transfers, a Windows notification when one finishes, and the machine is kept awake while a transfer is connected.
Settings cover the save folder, a Hide my IP mode that routes everything through the relay, the global-stats opt-out, the File Explorer Send with Floe entry, and a self-hosted server address with a Test button that checks the three endpoints a transfer actually needs.
The installer is per user, so there is no administrator prompt, and uninstalling leaves your settings and history in place.
Relayed transfers are capped at 2 GB per session, the same rule the web app and the CLI already apply. Direct transfers have no limit.
No transfer-protocol change, so Floe Desktop 0.1.0 transfers with browser and CLI peers in every direction.

Self-hosting

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.

Self-hostingCLI

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.

CLI

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.

CLIWeb

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.

CLIWeb

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.

CLIWebSelf-hosting

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.

CLIWeb

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.

CLI

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.

CLI

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.

WebCLISelf-hosting

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.

CLIWeb

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.

CLI

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.

CLI

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.

CLI

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).

CLI

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.

CLI

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.

CLI

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.

CLI

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.

CLIWebSelf-hosting

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.
Fixed a browser receiver bug where a Buffer view was retained across chunk boundaries instead of being copied, which could corrupt received data.
Security: updated ws, esbuild, and postcss transitive dependencies to address published advisories.

CLI

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.

CLIWeb

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 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.

WebCLISelf-hosting

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

Desktop

CLI

Self-hosting

How it works

Help

Reference