MatrixSeven/file-transfer-go: a self-hosted WebRTC file drop with a six-digit code

What file-transfer-go actually replaces

Most browser file transfer services work by uploading your file to someone else's disk and handing the recipient a link. file-transfer-go inverts that. The README describes the project as a point-to-point tool where data does not pass through the server, and the architecture diagram in the repository shows the server sitting only on the signaling path: sender to server over WebSocket, server to receiver over WebSocket, and a separate WebRTC P2P connection carrying the actual bytes between the two browsers.

The audience is narrow and specific. It is for someone who already has a host to run a container on and wants a transfer endpoint they control, without asking recipients to install anything or create an account. The README states plainly that registration is not required and that the server does not store files. If your recipients are already inside a corporate chat tool with file sharing, this adds a hop rather than removing one.

Signaling over WebSocket, payload over WebRTC DataChannel

The split is the whole design. The Go backend, built on go-chi and gorilla/websocket according to go.mod, holds a WebSocket connection to each participant and uses it to exchange connection metadata. The repository documentation names the ICE framework and STUN/TURN as the NAT traversal layer. Once negotiation finishes, the browsers open a WebRTC DataChannel and the file moves directly.

Two consequences follow from that. First, the server's memory footprint is small because it never buffers file content; the README mentions in-memory storage for the lightweight data it does keep. Second, the server's bandwidth is not the bottleneck, but its reachability is. A WebRTC connection between two browsers behind symmetric NATs will not form without a relay, and the README lists STUN/TURN support as a feature without documenting which servers the default deployment uses or how to point it at your own. That is the first thing to check in a real deployment.

The repository also ships STREAMING_FILE_TRANSFER.md and PROTOCOL_ANALYSIS.md at the top level, which suggests the transfer path has more detail than the README carries. Those files are where to look before you trust the resume behaviour described as 断点续传 in the feature list.

Running it with Docker Compose on port 8080

The README gives three deployment paths and marks Docker as the recommended one. The compose file in the repository defines a single service, file-transfer-go, pulling matrixseven/file-transfer-go:latest and publishing port 8080, with restart set to unless-stopped. Clone the repository and bring it up:

git clone https://github.com/MatrixSeven/file-transfer-go.git
cd file-transfer-go
docker-compose up -d

After that, the service listens on http://localhost:8080. Open it in a browser and you should see the transfer UI. If you prefer a bare container without compose, the README gives this equivalent:

docker run -d -p 8080:8080 --name file-transfer-go matrixseven/file-transfer-go:latest

The published image is multi-architecture, covering linux/amd64 and linux/arm64, so an ARM host works without a local build. To send something, select the file, let the UI generate a six-digit pickup code, and give that code to the recipient, who enters it on the same page. Text transfer and desktop sharing follow the same code-based flow. If you would rather build from source, the README documents ./build-fullstack.sh followed by ./dist/file-transfer-go, and the Dockerfile shows the two-stage build: a node:20-alpine stage produces the Next.js static export, and a golang:1.21-alpine stage compiles the server with CGO disabled and copies the frontend into internal/web/frontend.

Where the design puts you on the hook

The strongest limitation is the one the README is quietest about. Because the payload is peer to peer, transfer success depends on the two networks agreeing to a direct path. On a locked-down corporate network, or between two mobile carriers that both use symmetric NAT, the connection simply will not establish without a TURN relay. The README lists STUN/TURN as supported but does not document a default TURN server, credentials, or a configuration key for supplying your own. Until you read PROTOCOL_ANALYSIS.md or the server source, treat that as an open question rather than a solved one.

The second limitation is the pickup code itself. A six-digit code is short, and the README does not describe any expiry window, attempt limit, or rate limiting around it. The server holds connection state in memory, which means a restart drops in-flight sessions. Nothing in the README describes persistence or recovery, so a container restart during a large transfer is a lost transfer.

Finally, this is the wrong tool when you need a durable link. There is no mention of a stored file, a download URL that survives the session, or an audit trail. If a recipient might open the link tomorrow, a storage-backed service is the correct choice and this is not.

How it differs from a hosted transfer service

WeTransfer and similar services are storage products with a transfer interface. You upload, the file lands on their infrastructure, and the recipient downloads it later. That model gives you link persistence and works through any firewall that permits HTTPS, which is nearly all of them. It also means the operator holds your file, and the free tier comes with size ceilings and retention windows set by someone else.

file-transfer-go makes the opposite trade. Nothing persists, so nothing leaks from a stored copy, and there is no third party in the data path. In exchange you lose the properties that made the hosted model convenient: no link that works tomorrow, no transfer that survives a NAT that refuses direct connections, and no vendor to call when it breaks. If you want the peer-to-peer property without running anything, a desktop tool like Syncthing or a local-network app such as LocalSend occupies similar ground, though both require software on the endpoints, which is exactly what the browser-based code flow here avoids.

Maintenance, licence and what a fork costs you

The last push to main was on 2026-06-08, the same day v1.1.0 was released, and the repository is not archived. Before that, v1.0.9 landed on 2026-03-18 and v1.0.8 on 2026-03-16, so the release cadence in the recorded history is a burst in March and a single release in June. Judge that against your own tolerance rather than treating it as a promise.

Upgrade cost is low if you deploy the published image. Changing the tag in docker-compose.yml and recreating the container is the whole operation, and because the server keeps state in memory there is no schema migration to run. The risk sits on the other side: a restart terminates active sessions, so schedule upgrades when nobody is mid-transfer.

On licensing, the repository carries an MIT License at the top level. That covers the Go server and the build scripts. The frontend under chuan-next bundles Next.js, React, Tailwind CSS and Radix UI, each under its own terms, and the MIT file in this repository does not relicense them. Check the dependency licences separately if your organisation cares. None of this is legal advice.

Editorial conclusion

Adopt file-transfer-go if you want a self-hosted drop point where the payload never lands on the server and a six-digit code is the only handshake your users need. Do not adopt it if your network blocks peer connections and you cannot supply your own TURN service, because the README documents STUN/TURN support without saying what is configured by default. Before committing, verify three things: that the Docker image matrixseven/file-transfer-go:latest serves the UI on port 8080 in your environment, that a transfer completes between two devices on different networks, and that your licence review accepts the MIT terms for the bundled Next.js frontend.

Frequently asked questions

Official sources

1. License: MIT
2. MatrixSeven/file-transfer-go on GitHub
3. Project website
4. README
5. Releases