FastSend, browser based peer to peer file transfer

A browser that behaves like a file transfer client

FastSend is described as a peer to peer file transfer tool based on WebRTC, supporting fast directory synchronisation and file transfer, with secure and efficient file sharing through the browser. The feature list is short and each item says something about the design. Transfers are peer to peer and encrypted, which means the data path does not run through the server. Files and folders are both supported, and the folder case is the demanding one, since it depends on the modern File System Access API. The tool optimises automatically for the local area network, which is where peer to peer actually wins because the packets never leave the building. The interface is described as simple, it ships in Chinese and English, and it can be installed as a PWA, so it behaves like an app on a phone without being one. The audience is people who need to hand a directory to someone else and do not want to upload it anywhere.

Nuxt 4, with the front end and the server context separated

The stack list is WebRTC, Vue.js, Nuxt 4, Pinia, TypeScript and the modern File System API, and the directory section explains the layout in the author's own terms. The project has been migrated to the app/ directory convention that Nuxt 4 uses by default. The app/ directory holds the front end application layer, with pages, components, stores, composables, utilities, global styles and app.vue. The server/ directory holds the Nitro server interfaces and the WebSocket signalling logic, which is the part that has to exist even in a peer to peer design, since the two browsers need a way to find each other. The public/ directory holds the static assets and the PWA files, and presets/ holds the PrimeVue theme presets. The stated reason for the split is that it separates the front end application layer from the server context more clearly and matches the default scanning behaviour of Nuxt 4. The tree at the top level matches that description, with app/, server/, public/, presets/, i18n/ for the two interface languages, a nuxt.config.ts, a tailwind.config.js, a Dockerfile and a docker-compose.yaml.

Building it and running the built server

The build is yarn, and the two commands are the whole story.

# install dependencies
yarn install

# build the project
yarn build

The built output is a Nitro server, and it is started directly with node.

node .output/server/index.mjs

There is one requirement that will stop a first run, and the README marks it as important. Directory transfer and synchronisation need HTTPS and browser support, and most recent desktop browsers have it. The project's own HTTPS setup for a test environment is documented in a pinned issue and in the Nuxt deployment guide. For production the recommendation is the opposite of the test setup, namely not to deploy FastSend as an HTTPS server itself but to place it behind a reverse proxy, and the README lists four of them, Nginx, Apache httpd, Caddy and Windows IIS, with the configuration documentation for each. That is a sensible default, since a Nuxt server is not where you want to manage certificates.

One official image, and a dozen that are not

The Docker section carries a warning that is unusual to see in a README and worth quoting by substance. The image shouchenicu/fastsend is the only official image of this project on Docker Hub, and the author reports having found twelve third party images, five of which have more downloads than the official one, and the note is to check carefully and judge the risk yourself. The official image runs with a single command.

docker run -d --name fastsend -p 3000:3000 shouchenicu/fastsend:latest

Building it locally is the same shape, and the compose file is the third route.

docker build -t fastsend .
docker run -d --name fastsend -p 3000:3000 fastsend
docker-compose up -d

The compose file builds from the local context, publishes port 3000, sets NODE_ENV to production and runs the server with node server/index.mjs, and the README says to open http://localhost:3000 to use it. The image warning is a real operational hazard for a tool that moves files, since a third party image of a file transfer application is a supply chain problem by construction.

A two stage node image with a small runtime

The Dockerfile is a conventional multi-stage build on node:24-alpine. The builder stage copies the package manifest, the lockfile and the yarn configuration, enables corepack and installs with a frozen lockfile, then copies the rest of the source and runs yarn build. The runtime stage starts from the same base image and copies only the built output, the .output directory, into /app, exposes port 3000 and starts the server with node server/index.mjs. That is a small runtime with no package manager and no source in the final image, which is the right shape for something that handles file transfers. The JavaScript dependencies explain the feature set. webrtc-adapter handles the browser differences in WebRTC, qrcode produces the pairing code, crypto-js does the encryption, @isaacs/ttlcache is an in-memory cache with expiry, @vite-pwa/nuxt adds the progressive web app behaviour, and PrimeVue with its forms module provides the interface, with Pinia holding the state.

The peer to peer path is where it fails

The usage tips at the end of the README are the operational truth of the project. You should make sure the browser has WebRTC enabled, and if you are transferring folders or synchronising directories you should make sure the browser supports the modern File System API and that the transfer is over HTTPS. Transfers are fastest inside the same local area network, and the author recommends using it when the network is in good condition, because some network environments prevent P2P and WebRTC from establishing a connection properly and the transfer then fails. That is the fundamental trade of the design. A relayed transfer through a server tolerates restrictive networks and is easier to reason about operationally, while the peer to peer path is faster, private and free of a storage intermediary, and it is the part that breaks when a network blocks UDP or similar. The data path is encrypted end to end between the browsers, and the signalling server is not in the path of the file contents.

A young project with no releases yet

The version badge in the README reads 0.7.3, and the repository publishes no GitHub releases, so the published package and the public release history are separate things here. The repository is not archived and the last push was on 2026-10-13. The licence is MIT, stated in the README and the LICENSE file, which is the permissive grant you want for a tool you may deploy on an internal network. The package manifest records yarn 4.18.1 as the package manager and the Nuxt dependency at 4.6.1, with Vue at 3.5.43, Pinia at 3.0.4 and PrimeVue at 4.5.5, and the development side carries the i18n module, the SEO module, the colour mode module, @nuxt/icon, the Pinia and PrimeVue Nuxt modules, Tailwind at 3.4.19 and Prettier. There is also a set of resolutions that pin the Nuxt devtools, the Vue server renderer, rollup, serialize-javascript and sharp to specific versions, which is a sign of a project that has been bitten by transitive version drift. The author is ShouChen, and the repository is open to issues and pull requests.

Editorial conclusion

FastSend fits a person who wants to move a folder to a colleague without a third party server in the path, and it fits a team that already runs containers, since the compose file and the published image make the deployment two commands. It does not fit a workflow that depends on large transfers over the open internet, because the peer to peer path breaks on networks that block WebRTC, and it does not fit a project that needs a server mediated transfer with accounts. Verify three things before adopting it: that the browsers on both ends support the File System Access API and are on HTTPS, since directory transfer and sync need both, that the peers can establish a WebRTC connection on the network you are on, and which image you are actually pulling, because the README warns that shouchenicu/fastsend is the only official image while a dozen third party ones exist.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. ShouChenICU/FastSend on GitHub