
FerriShare is a simple, self-hostable and open-source
filesharing application with builtin end-to-end-encryption
#), which is never sent to the server

[!WARNING]
While I have taken great care to correctly deploy the cryptographic primitives used in this project, I am not an expert in cryptography and this project has not been independently audited.I cannot guarantee that the implementation or design of the system is secure.
You can review the cryptographic architectural notes provided further below, or directly examine the code responsible for encrypting and decrypting files.If you spot any issues, please let me know in the project's issue tracker.
FerriShare must be run behind a reverse proxy. There are two major reasons for this:
localhost.Commonly used reverse-proxies include Traefik, Caddy and nginx.
In the instructions presented below we will be using a very simple Traefik setup.
The repository provides prebuilt Docker images on GitHub's Container Registry for the following architectures:
- amd64 a.k.a. x86_64 for Intel and AMD processors
- arm64 a.k.a. 64-bit ARMv8 for modern ARM servers or SBCs (e.g. Raspberry Pis)
- arm/v7 a.k.a. 32-bit ARMv7 for older ARM processors (e.g. older Raspberry Pis)
If your architecture is not on the list, you'll have to build the image yourself.
cd into it.mkdir ferrishare; cd ferrisharedocker-compose.yml into said folderlocalhost.
The compose-file is commented to help you better understand how to adapt it to your needs.docker compose pulldocker compose run --rm -it ferrishare --init./data-subdirectory../data/user_templates will only be created if they do not already exist.docker compose up to launch the app in the foregrounddocker compose up -d to run the containers in the backgroundRefer to the building locally from source instructions provided further down.
FerriShare is built as a traditional Multi-Page Application (MPA) where templating is performed fully on the backend. In that sense there is no real separation of frontend and backend, they're intertwined. JavaScript is only served where required, specifically the upload and download endpoints as that's where the client-side encryption takes place.
| Path | Purpose |
|---|---|
| src/ | Rust sources for the backend |
| templates/ | HTML and JS template sources for the frontend |
| migrations/ | Schema files for the application's SQLite database |
| font/ | The project's latin and icon fonts -- check the folder's README for details |
| favicon/ | The project's favicon -- check the folder's README for details |
| readme/ | Screenshots and images for the README |
| Cargo.toml, Cargo.lock | Rust project files defining dependencies and build behavior for the backend |
| package.json, package-lock.json | npm project files used to setup the Tailwind CLI |
| main.tw.css, tailwind.config.js | Main stylesheet and Tailwind config used to generate the CSS bundle |
| Dockerfile | Protable build and packaging instructions (using multi-stage builds) |
| docker-compose.yml | Example application setup with Traefik, useful for developement or as a quick start |
window.crypto.subtle.generateKey(...), which uses a strong CSPRNG.0, and the filedata, using IV 1.The instructions for building FerriShare with Docker are almost the same as the normal installation and configuration instructions above, but with two main differences:
- Instead of creating an empty folder, grab a copy of the source code. You have two options:
- Go to the releases page, download the Source code archive for the release you want to run, extract it and cd into it.
- Clone the repository and cd into it. Important: This repository uses Git LFS to store large binary assets. Make sure Git LFS is setup and installed on your machine before cloning.
- Invoke docker compose build instead of docker compose pull.
- This causes docker compose to build the ferrishare-image locally from the repository sources instead of pulling them from the online registry.
The provided Dockerfile uses multi-stage builds to both cache stages of the build-process and ensure the final image is as slim as possible. It uses cargo-chef to cache downloads and builds of all Rust dependencies, significantly speeding up subsequent builds of the application. The actual Dockerfile is properly commented, check it out to understand the full build process.
Don't want to use Docker? No problem.
You will need a Linux box, as all the instructions are written for a Linux machine. MacOS and Windows have not been tested, although the former might work.
cd into it.cd into it. Important: This repository uses Git LFS to store large binary assets. Make sure Git LFS is setup and installed on your machine before cloning.npm installnpm run build:twnpm run dev:twcargo build --releasecargo run --release -- --init (that -- in the middle is not a typo)./data-subdirectory../data/user_templates will only be created if they do not already exist.cargo run --release to launch the app in the foregroundproxy-depth of 0, otherwise FerriShare will refuse your HTTP requests.Note that resources served on the /static/-endpoint are served with an infinite cache policy.
During local development, you may want to disable browser caching to ensure your changes are always reflected in the browser.
Installation is fully documented in this README.
Configuration is documented in FerriShare itself through its interactive configuration wizard that can be invoked with the --init-flag.
The source code itself is properly documented, but the docs aren't hosted online.
If you'd like to browse the module-level documentation you can clone the repository and invoke cargo doc --no-deps --open, assuming Rust is setup on your system.
FerriShare is released under the terms of the MIT License. Contributions are welcome!
Where does the name come from?
It's a simple portmanteau of 'Ferris', the Rust mascot, and 'share' from 'Fileshare'.
$ claude mcp add ferrishare \
-- python -m otcore.mcp_server <graph>