Day-to-day operations

Reference for a Floe instance that is already running under Docker Compose: the commands you will reach for, what a restart costs, how to update, what the server logs, and which endpoint to monitor.

The short version

docker compose pull and docker compose up -d update the instance. Every restart forgets the room codes people are waiting on, so pick a quiet moment. Point a monitor at /health, and expect the server’s log to be nearly empty.

Common commands

Terminal

docker compose logs -f                  # tail logs for all services
docker compose ps                       # check container status and health
docker compose down                     # stop and remove the stack
docker compose restart server           # restart only the signaling server

Every service in the compose file is set to restart: unless-stopped. The server, the client, and coturn come back by themselves after a crash, and when the host starts again after a reboot. They stay down only after docker compose stop or docker compose down. Docker does not restart a server that is only unhealthy.

Restarting the server is not free. Every room and room code lives in that process’s memory, so a restart forgets every room code, and a CLI or Floe Desktop sender still waiting for its receiver stops and has to start again. There is no draining and no warning. Pick a quiet moment.

What a restart does to each person using the instance:

Who	What a restart does
A sender in the web app, waiting for the other person	It reconnects on its own within a few seconds and keeps its link.
A sender in the CLI or Floe Desktop, waiting for the other person	It stops, and has to start again with a new code.
Two people whose transfer is already running	Nothing: file data never passes through the server. A transfer that was still connecting may need another try.
The owner of a request link that waits for a sender	The link comes back on its own: a Floe Desktop that is still open reconnects and makes the same link again.
A sender who opens a link that was used, or that ended before anyone used it	They see “Their computer is not connected right now” instead of “This link has already been used” or “This link has ended”, because the server forgot the mark.

A web client older than 1.11.0 is the exception to the third row: its transfer stops when the server tells the page that the other side has left, as a shutdown can. The client also waits on the server: Compose starts it only once the server reports healthy. If the server never gets there, you do not get a web app that cannot connect. You get no web app at all.

Update to the latest code

Terminal

docker compose pull
docker compose up -d

That pulls the image tag you run, which is latest unless FLOE_IMAGE_TAG in .env names another, and restarts on it. See Container images for the tags. Nothing is built locally, so there is no repository to keep in sync. If you pinned a version, change FLOE_IMAGE_TAG first, or the pull has nothing new to fetch. An update is a restart, with the cost described above. Pulling never changes your docker-compose.yml, though, and a setting that a release adds reaches the containers only through that file. A copy from 1.11.0 or earlier passes neither TURN_TLS nor REQUEST_REPORT_EMAIL, both new in 1.11.1, and a copy from 1.11.1 or earlier does not pass MAX_SOCKETS_PER_IP, which is newer, so setting any of them in .env does nothing. To use one, download the current file from GitHub and copy your own changes across. If you run the optional coturn relay, add its profile to both commands or Compose skips the service entirely, so a stopped relay is never restarted:

Terminal

docker compose --profile turn pull
docker compose --profile turn up -d

Setting COMPOSE_PROFILES=turn in your .env applies it to every later docker compose command. The compose file pins coturn, Floe’s optional TURN server, to coturn/coturn:4.15, so the pull refreshes that version only; see TURN relay. Changing NEXT_PUBLIC_SOCKET_URL needs only docker compose up -d, because the client reads it at runtime. See How the client finds the server. NEXT_PUBLIC_SITE_URL is the exception: it is written into the page at build time, so the published image cannot carry it. That image leaves your domain out of share previews and the sitemap rather than pointing them at somebody else’s. See Container images for what the image emits and how to build your own.

Moving to 1.11.0

Version 1.11.0 changed what a self-hosted instance needs. Go through these five points once, when you move up from an older version:

Pass the Host header through your proxy. This matters only when the CLI or Floe Desktop reaches the server through a reverse proxy on a hostname that is not exactly your CLIENT_URL, as on the two-hostname layout. From 1.11.0 the server checks the origin of every WebSocket, and it lets those two clients in by comparing their Origin with the hostname in Host. A proxy that rewrites Host to its upstream address gets them refused with a 403. Browsers on your CLIENT_URL, a one-domain deployment, and a server reached without a proxy are not affected.
Take the current docker-compose.yml. Pulling images never changes your copy. One from before v1.11.0 passes neither POLICY_FILE nor MAX_FAILED_CODE_RESOLVES to the server, so setting them in .env does nothing. Download the one on GitHub and copy your own changes across. You need it before you turn on request links, which stay off until you do.
Keep the client and the server on one version. The page a request-link sender opens is part of the web client, so a 1.11.0 server behind an older client hands out links to a page that does not exist. Compose picks both images with FLOE_IMAGE_TAG; if you pinned 1.10.11, move it to 1.12.0 or the newest tag in Container images. See Keep the client and server on one version.
Know the new failed-lookup setting. Each address gets 10 failed room-code lookups in 60 seconds, and the new optional MAX_FAILED_CODE_RESOLVES changes that number. A lookup that finds a code costs nothing, but once an address has spent its 10, every lookup from it answers 429 until the misses age out. Raise it only if many people behind one address mistype codes. See Configuration.
Expect IPv6 clients to share limits by /64. Every per-address limit now counts an IPv6 client by its /64 instead of its single address, so everyone inside one /64 shares one budget, as everyone behind one IPv4 address always has. If a whole office or campus sits in one /64, raise MAX_CONNECTIONS_PER_IP and the other limits to fit.

One change needs nothing from you. From 1.11.0 the server turns a third network away from a room once devices on two networks have started connecting through it. An older server lets a device from any network into a free place. See A room holds exactly two people. The Changelog lists everything else that changed in v1.11.0.

What an older web app shows

The web app at floe.one always runs the newest code, and it is the one the rest of these docs describe. A web app you host changes only when you pull a newer image. Until then its pages show the wording of the version they run, and this table lists each place where that differs.

Update the web image to 1.12.0 before Floe Desktop 1.1 reaches your users. The Microsoft Store updates Floe Desktop on its own, so it cannot be timed to happen together, and a web image moves only when you pull it, and never while FLOE_IMAGE_TAG names an older version. From then on, an older image can open no request link Floe Desktop makes. The first rows of the table say what breaks.

Where	What these docs describe	What an older version shows
Sending through a request link: a request link from Floe Desktop 1.1 or later, which holds a link key	The page reads the link, checks the computer that made it, and sends.	Version 1.11.7 or earlier: the link is dead in a browser. The page reads “This link looks incomplete”, asks the server nothing, and Floe Desktop shows nothing. Before 1.11.0 the address answers 404.
floe send: `floe send --link-only` into a browser	The page proves the link key, and the files arrive.	Version 1.11.7 or earlier: the page has no proof to give. After about 16 seconds `floe send` says `Couldn't confirm the receiver. They may need to run floe update, or open the link in a browser.`, though the browser is what is old. The page says “The sender stopped the transfer.”, or on 1.10.0 and 1.9.1 “Could not connect. Ask the sender to enable “Network Relay” and try again.”
Receiving files: a share link from `floe` 1.12 or later or Floe Desktop 1.1 or later, which holds a link key	The page checks that the sender holds the link key before it accepts a file.	Version 1.11.7 or earlier: the files arrive with a matching SHA-256 and the link key unread. Nothing breaks, nothing is checked, and the person cannot tell.
Sending files: the link the Send page makes	The link holds a link key: `?s=8262e1b4#k=<link key>&room=<room id>`.	Version 1.11.7 or earlier: the link has no link key, `?s=8262e1b4#room=<room id>`, so no receiver can check it.
Sending through a request link: a drop that stops after they accepted, with nothing saved	No line says what was saved, because part of a file may have gone.	Version 1.11.7 or earlier: a line reads “Nothing was sent.”, under “You stopped this drop.” too.
Troubleshooting: “Open in your browser” on a request link	The card says to open the link in current Chrome or Edge on a computer.	Version 1.11.0 only: the card says “Open Floe in Chrome or Safari for the best experience.” instead. Open the link in current Chrome or Edge on a computer all the same.
Troubleshooting: a browser opens the link after the sender left	The page says “The sender is not connected”.	No message there: the page stays on “Waiting for the sender to start”.
Troubleshooting: the “Link Invalid” card	The card reads “This link is incomplete, already in use, or locked to the networks that first used it.”	The card reads “This link is either expired, already in use, or does not exist.” The causes are the same.
Troubleshooting: nobody is on the sending side of the link	The second step of the card reads “The sender is not connected”.	Never this line. The page shows “Waiting for the sender to start” for as long as it stays open.
Troubleshooting: a sender in the browser came back on a new network	The status line reads “Reconnecting to your link” for about a minute, then a red banner says the link stopped working.	Nothing: the page keeps its last status line, and nobody who opens its link reaches it anymore.
Troubleshooting: “Too many refreshes. Reconnecting”	The page retries by itself, and the banner goes away once a retry gets through.	Version 1.11.0 only: the red banner stays on screen after a retry has worked. Version 1.10.11 or earlier: the page does not retry at all, so wait a minute and then reload it once.
Troubleshooting: the receiving page could not connect	“Connection failed. Ask the sender to try again. If they turned the relay off, ask them to leave it on.”	“Could not connect. Ask the sender to enable “Network Relay” and try again.” It means the same.
Troubleshooting: the sending page, with Network relay fallback unchecked	“Connection failed. This link was made with Network relay fallback off. Reload the page, add the files again, leave it on, and share the new link.”	“Connection failed. Enable “Network Relay” to connect across restrictive networks.” It means the same checkbox.
Troubleshooting: “This link stopped working” on the sending page	About a minute of “Reconnecting to your link”, then a red banner: “This link stopped working. Reload the page, add the files again, and share the new link.”	Neither message. The page keeps its last status line and its link, and nobody who opens that link reaches it.
Troubleshooting: a relayed transfer over 2 GB	The receiving page is told “Transfer blocked: relay connections are capped at 2 GB. Ask the sender to send 2 GB or less, or to try a network that allows a direct connection.”	Versions 1.10.8 to 1.11.0: a sender’s page sends “remove files” where this says “send 2 GB or less”, and its own notice says “Remove files to proceed”.
Troubleshooting: the transfer ended before every file arrived	An amber line under the file list, such as “Received 1 of 3 files. The transfer ended before the rest arrived.”	Not this line. The page shows a green check and a count such as “1 file received” instead, as if the transfer had finished.
Troubleshooting: the connection failed before any file moved, on the receiving page	“Connection failed. Reload the page to try again. If it fails again, ask the sender for a new link.”	“Connection error:” followed by a technical message. Part of that message can come from the other device, so do not act on what it says.
Troubleshooting: the connection failed before any file moved, on the sending page	“Connection failed. Ask the other device to open the link again. If it fails again, reload the page, add the files again, and share the new link.”	“Connection error:” followed by a technical message, as on the receiving page.
Troubleshooting: the page reloads by itself after the web app is updated	A tab with a transfer under way, or a file not yet saved, is not reloaded; it reloads the next time it needs a part of the new version.	Version 1.11.1 or earlier: the page reloads at once, and a transfer running in that tab ends.
File checks: the SHA-256 check in the browser	The Send page works out each file’s SHA-256, and a receiving page checks it and shows a green check mark when every file matched.	Version 1.10.11 or earlier: neither page works out or checks a SHA-256, so files are checked by size only, and the check mark is green all the same.
File checks: a transfer where every file’s SHA-256 matched	A green check mark in front of “3 files received” on the receiving page, and beside “All Files Sent!” on the Send page. With a file checked by size only, the check mark is gray.	Version 1.11.3 or earlier: the line “SHA-256 matched” under “3 files received” or “All Files Sent!”, and a green check mark either way.
Sending files: the status changes after “All Files Sent!”	The file rows keep their check marks, and the progress row still reads “Sent 3 files”, with your own number.	The last file’s check mark turns back into a spinner when the status changes, and the progress row reads “Sending file 3 of 3…” at 100%. Every file was still sent.
Sending files: the status becomes “Connection interrupted” after every file was sent	The status has no check mark, so a green one goes with the status it was beside. The file rows and “Sent 3 files” still say every file was sent.	Versions 1.11.1 to 1.11.3: a “SHA-256 matched” line that was showing stays under the status. Version 1.11.0 or earlier: the line disappears with the status.
Sending files: the line at the foot of the card once the link exists	“Keep this tab open and in front. Closing it cancels the transfer.”	Version 1.11.1 or earlier: “Keep this tab open. Closing it cancels the transfer.” Keep the tab in front all the same.
Sending files: a link from `floe` or Floe Desktop opened in the tab that is sending	In a tab you have clicked on, your browser asks about leaving; in one you have not, the page opens the new link once the send ends.	Version 1.11.1 or earlier: the page reloads for the new link at once, and the send ends.
Sending files: a file added a second time, by the picker or by a drop	It is listed once and sent once.	Version 1.11.6 or earlier: it is listed and sent twice. Remove the extra row with its X before you create the link.
Receiving files: Download ZIP	The page reads each file a piece at a time and stores it in the archive without compression. An archive of 4 GB or more, or of more than 65,534 files, is refused with “ZIP creation failed. Try “Download All” instead.” before any file is read.	Version 1.11.1 or earlier: the page reads every file into the tab at once and compresses the archive, so zipping a large transfer can run the tab out of memory, and an archive of more than 65,535 files is saved with no message, though unzip tools find few or none of its files.
Receiving files: Download ZIP of names that differ only in letter case, such as `A.txt` and `a.txt`	The second is numbered, `a (1).txt`.	Version 1.11.1 or earlier: both go in as named, and unpacking on Windows or macOS keeps only one of them.
Sending files: Back or Forward after a header or footer link on the main page was clicked while it was still loading	The page asks before it is left while a link is out.	Version 1.11.1 or earlier: if that click came while the page was still loading, Back and Forward can leave a page that holds a link without asking.
Receiving files: the sender left after at least one file finished	An amber line under the list says how far the transfer got, such as “Received 1 of 3 files. The transfer ended before the rest arrived.”	No such line. The list keeps a green check and a count such as “1 file received”, and a progress row for the file that never finished can stay on screen.
Receiving files: the line at the foot of the card while a receive is under way or a file is unsaved	“Keep this tab open and in front. Closing it interrupts the download.”	Version 1.11.1 or earlier: “Keep this tab open. Closing it interrupts the download.” Keep the tab in front all the same.
Receiving files: a link from `floe` or Floe Desktop opened in a tab that is receiving from another such link	In a tab you have clicked on, your browser asks about leaving; in one you have not, the page opens the new link once the receive is over and every file that arrived has been saved.	Version 1.11.1 or earlier: the page reloads at once, and files not yet saved are lost. Save them before you open the new link.
Troubleshooting: Chrome or Edge has no room left for what is arriving, as in a private window	“This browser ran out of room for the files it is receiving”, with what to do about a private window.	Version 1.11.4 or earlier: “This browser ran out of memory while receiving” here too. Close the tab and open the link in a normal window all the same.
Sending through a request link: the link was opened inside another app’s built-in browser	“Open in your browser”, with “Open the link in current Chrome or Edge on a computer.”	Version 1.11.0 only: the page says “Open Floe in Chrome or Safari for the best experience.” there instead.
Sending through a request link: Hide my IP is on and the selection is over 2 GB	“Relayed drops are capped at 2 GB. Turn off Hide my IP, or send 2 GB or less.”	Version 1.11.0 only: the line ends “or remove files.”
Sending through a request link: Hide my IP is on and the page could not read the server’s relay list	“Couldn’t check for a relay. Try again, or turn off Hide my IP to send directly.”	The page says “This Floe server has no relay right now. Turn off Hide my IP to send directly.” here too.
Sending through a request link: “Relay limit”	“Relay limit”, then “This connection needs a relay, and relayed drops are capped at 2 GB. Send 2 GB or less, or try another network.”	Version 1.11.0 only: the page says “Remove files” where this says “Send 2 GB or less”.
Sending through a request link: a file name or folder path too long to send	“A file name or folder path is too long to send. Shorten it or zip it first.”	Version 1.11.1 or earlier: “A folder path is too long to send. Zip deeply nested folders first.”
Sending through a request link: their Floe stopped a relayed drop past 2 GB	“Relayed drops are capped at 2 GB”, with “Nothing was sent. Send 2 GB or less.” in place of the count when nothing was saved.	The line ends “Send under 2 GB.”
Sending through a request link: their Floe stopped a drop for a file name or path too long to save	“A file name or folder path is too long for their computer”, and after the count “Shorten it or zip it first.”	Version 1.11.1 or earlier: “A folder path is too long for their computer”, and after the count “Zip deeply nested folders first.”
Sending through a request link: Report this link on a server other than floe.one	The link starts an email to the address that server’s operator set in `REQUEST_REPORT_EMAIL`. With no address set, the page shows no report link.	The link shows on every server and starts an email to Floe’s maintainers, who cannot act on another server’s links. The variable is not read.
floe send: a receiving browser refuses a file whose description is longer than 1,000 bytes	The page tells the sender why, and `floe send` stops with `Error: A file name or folder path is too long for their computer. Shorten it or zip it first.`	The page sends no answer, so `floe send` waits 120 seconds and ends with `timed out waiting for ack`.
File checks: a browser receives	The page tells the sender once it holds every file, so the sender can show the SHA-256 matched mark, and a file the page could not keep after the last byte ends the send as a failure.	Version 1.11.1 or earlier: the page tells the sender nothing. The send ends once the data has left, without the mark, and a file the page could not keep after that is never reported.
Self-hosting overview: `/docs` on your instance	`/docs` sends the visitor’s browser on to the same page under `https://www.floe.one/docs`.	The client container fetches each docs page from `floe.mintlify.site` itself and serves it under your own domain.

On version 1.11.0, where the “Too many refreshes. Reconnecting” banner stays after a retry has worked, the badge at the top right turning green is the sign that the page is connected again, and the X closes the banner. For a relayed transfer over 2 GB, the sending page’s own notice now says to reload the page. To see the newer wording, update the client image to the newest version: see Update to the latest code.

The server logs very little

Worth knowing before you go looking. The signaling server has no access log, no request log, and no startup banner, not even a line saying which port it bound. docker compose logs server on a healthy instance is usually empty, or holds the one line request links: on, and that is expected rather than a symptom. A server run with Node directly and no TRUSTED_PROXY_COUNT writes one line about that at startup, and so does a server given a word or a negative number for it; see the table. So does a server given half of a pair of variables, or a TURN_DOMAIN that holds more than a hostname. It never logs an accepted connection, a room, a code, a rate-limit refusal, or a request-link event, and no line is built from a client’s address. These are all the lines it can write:

Message	What it means	What to do
`request links: on` or `request links: off`	The request-link setting took effect: at startup when the policy file says on, and afterward whenever it changes. A server that starts with request links off writes neither.	Nothing. See Turn on request links.
`policy file not found, request links off`	`POLICY_FILE` is set, but no file is at that path. Written once for as long as the file stays missing.	Check the volume mount and the path.
`policy file unreadable, keeping previous policy`	The policy file is there but cannot be used, so the last good setting stays. Written once, until the file reads cleanly again.	Fix the file, or let the user `node` read it. See how the server reads it.
`MAX_CONNECTIONS_PER_IP is not a whole number of at least 1. Using the default, 30.`	A `MAX_*` variable holds something other than a whole number of at least 1. The line names the variable and the default now in use, never the value. Written once at startup for each such variable.	Fix the value, or remove it to keep the default. See Configuration.
`TRUSTED_PROXY_COUNT is not set, so the default of 1 is in use. Set it to the number of reverse proxies in front of this server, or 0 if there are none.`	The server was started without `TRUSTED_PROXY_COUNT`. Written once at startup. Compose and the Unraid template always pass a value, so it shows only on a server started another way, such as with Node directly, without the variable.	Set the variable. See Configuration.
`TRUSTED_PROXY_COUNT is not a whole number, so the default of 0 is in use. Set it to the number of reverse proxies in front of this server, or 0 if there are none.`	`TRUSTED_PROXY_COUNT` holds a negative number or a value that does not start with a number, such as a word, so the server trusts no proxy. A value that starts with a number is read up to its first other character (`1.5` is `1`) and gets no line. The line names the variable, never the value. Written once at startup.	Set the number of proxies in front of the server, or `0`. See Configuration.
`Only one of TURN_SECRET and TURN_DOMAIN is set, so the coturn relay is off. Set both, or neither.`	One variable of the pair is set and the other is empty or missing, so the server hands out no coturn entries. The line never carries a value. Written once at startup.	Set both, or neither. See `TURN_SECRET`.
`Only one of CLOUDFLARE_TURN_KEY_ID and CLOUDFLARE_TURN_KEY_API_TOKEN is set, so Cloudflare TURN is off. Set both, or neither.`	The same for the Cloudflare pair, so the server makes no Cloudflare credentials.	Set both, or neither. See `CLOUDFLARE_TURN_KEY_ID`.
`Only one of UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN is set, so the transfer counter is kept in memory and resets to 0 on restart. Set both, or neither.`	The same for the Upstash pair.	Set both, or neither. See `UPSTASH_REDIS_REST_TOKEN`.
`TURN_DOMAIN holds more than a host name, so the coturn relay is off. Set it to the host name alone, such as turn.example.com.`	`TURN_SECRET` and `TURN_DOMAIN` are both set, and `TURN_DOMAIN` holds a scheme, a port, a path or a bare IPv6 address. Without Cloudflare TURN, the server hands out the default STUN servers instead. Written once at startup, never with the value.	Set `TURN_DOMAIN` to the hostname alone.
`Refused a request with 403.`	The error handler refused one HTTP request with that status: `403` for a browser origin the server does not allow, or another status under 500.	An occasional one is some page or client sending a bad request, not a fault. If `403` lines show up each time someone uses your own web client, check `CLIENT_URL`.
`Refused a connection on /ws from Origin "..." (Host "..."): not CLIENT_URL, a floe.one origin, or this server's own host. Further refusals on /ws are not logged.`	A WebSocket came from an origin the server does not accept. Written once for `/ws` and once for `/socket.io` until the next restart, however many connections are refused.	If the `Origin` is your own server and the `Host` is not, your proxy rewrites `Host`. See Production deployment.
`Cloudflare TURN mint failed (...)`	A request to Cloudflare for relay credentials failed. The parentheses hold the reason: `status` and an HTTP status, `no-ice-servers`, an error name such as `TimeoutError`, or the word `error`. At most one line every 5 minutes.	See TURN relay.
`Upstash counter read failed (...)`	The server could not read the stats total from Upstash Redis at startup. The parentheses hold the reason, such as `status 401`, `ENOTFOUND` or `TimeoutError`. The first failed call writes one line, this one or the next, and later failures write nothing until a call succeeds.	Check `UPSTASH_REDIS_REST_URL` and `UPSTASH_REDIS_REST_TOKEN`. Common causes are a wrong token, a URL without `https://`, and a host the server cannot reach.
`Upstash counter update failed (...)`	The server could not add bytes to the stats total. Those bytes are not sent again, so a restart drops the total back to what Upstash holds.	The same checks. A read-only token can read the total but not change it: Upstash refuses its writes.
`HTTP server error:` and a stack trace	The server could not bind its port at startup and exits with code 1. A `PORT` Node refuses, such as `70000` or `3001.5`, gives `HTTP server error: RangeError [ERR_SOCKET_BAD_PORT]`. Under Compose, `PORT` is the host port and never reaches Node.	Free the port, or set `PORT` to a free whole number from 1 to 65535.
`Unhandled error (uncaughtException), server still serving:` and a stack trace	An exception nothing anticipated reached the process-level backstop. The word in parentheses can also be `unhandledRejection`. The server kept serving rather than exiting, so the transfers in progress survived.	It is worth reporting.
A stack trace on its own	A server-side error (a `5xx`) reached the error handler.	It is worth reporting.

The Refused a request with line carries the status and nothing else, never the origin, the path, or any of the request’s text. Besides 403, it shows 400 for malformed JSON and 413 for a body over the size limit. A server image of version 1.11.0 or earlier never writes the MAX_* and TRUSTED_PROXY_COUNT lines, and one of version 1.11.3 or earlier never writes the TRUSTED_PROXY_COUNT line about a value that is not a whole number. One of version 1.11.7 or earlier never writes the Only one of, TURN_DOMAIN holds or Upstash counter lines, and one of version 1.10.10 to 1.11.6 given a PORT that Node refuses logs Unhandled error (uncaughtException), server still serving: instead of HTTP server error:, then exits with code 0. To confirm the server is alive, or that a restart actually landed, use the health endpoint below rather than the logs. The client container writes Next.js’s own lines when it starts. Once it is listening it also warms its picture cache, and writes one line only if that does not finish: Floe: the image warm-up did not finish; pictures are resized on first request instead. The web app works either way. When Docker stops the server, the server closes every connection and exits within 10 seconds, and logs nothing on the way out. In detail: on SIGTERM or SIGINT it closes every /ws connection with code 1001 and the reason Server shutting down, closes its Socket.IO connections, and stops accepting new ones. If something is still holding it open 10 seconds later, it exits anyway.

Health endpoints

The signaling server exposes two status endpoints:

Endpoint	Purpose	Response
`GET /health`	Liveness check	`{ "status": "healthy", "uptime": <seconds>, "features": [...] }`
`GET /`	Status and timestamp	`{ "status": "ok", "timestamp": "..." }`

features is ["request-1"] while request links are on and [] while they are off. See HTTP API. Point a monitor at /health. It is the only one of the two that survives a one-domain deployment, where / belongs to the web client and returns a page rather than JSON. GET / on the signaling server is reachable only when you address the server directly, on :3001 or on its own subdomain. Both endpoints pass the same origin check as every other HTTP route. A monitor that sends no Origin header, as curl and most uptime services do, is answered. One that runs inside a web page on another site sends that site’s origin, and gets 403 with {"error":"Bad request"} while the server is healthy. The server image runs the same check on itself every 30 seconds, which is the health state docker compose ps shows. Each check gets 3 seconds to answer, and 3 failed checks in a row mark the server unhealthy. The client image checks itself the same way, every 30 seconds, by asking its own /api/config, so docker compose ps shows a health state for the client too. A client image of version 1.11.4 or earlier has no such check and shows none.

Request links on your server

A self-hosted server offers request links only when its policy file turns them on. The setup, the switch that needs no restart, the limits and the version rule are in Turn on request links.

Getting started

Web app

Desktop app

CLI

Help

How Floe works

Self-hosting

Reference

Changelog

Day-to-day operations

The short version

Common commands

Update to the latest code

Moving to 1.11.0

What an older web app shows

The server logs very little

Health endpoints

Request links on your server

​The short version

​Common commands

​Update to the latest code

​Moving to 1.11.0

​What an older web app shows

​The server logs very little

​Health endpoints

​Request links on your server

The short version

Common commands

Update to the latest code

Moving to 1.11.0

What an older web app shows

The server logs very little

Health endpoints

Request links on your server