Gokapi: Self-Hosted File Sharing Where Only Registered Users Can Upload
Lightweight selfhosted Firefox Send alternative without public upload. AWS S3 supported.
At a glance
- What is it?
- Gokapi is a Go-based file sharing server that replaces public upload links with expiring shares, deduplicated storage and optional S3 backends. It fits small teams that want a private Send clone, and it is a poor fit for anyone who needs anonymous public uploads.
- Who is it for?
- Adopt Gokapi if you run a small private instance for a known group of people and you already have an identity provider or are happy with local accounts. Do not adopt it if your workflow depends on anonymous public uploads, since the README states only registered users can upload.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Gokapi Solves: Expiring Shares Without a Public Inbox
Firefox Send is gone, and the hosted replacements that took its place mostly want you to trust someone else's storage. Gokapi takes the opposite position: you run the server, you hold the files, and links expire on your terms. The README describes it as a self-hosted alternative to Firefox Send that puts you in control of your file sharing, and the feature list backs that up with automatic expiration after a set number of downloads or days.
The design decision that separates Gokapi from most Send clones is stated plainly in the repository description: there is no public upload. Only registered users can upload, and user management comes with roles for permission control. That single constraint defines the audience. This is for a household, a small company, a club, or an internal team that wants to hand files to clients or colleagues without opening an anonymous drop box that anyone on the internet can fill with whatever they like.
If your use case is receiving files from strangers, the project has an answer, but a controlled one. File requests create a shareable URL that lets external parties upload files, and the README notes those uploads are visible only to the creator of that URL. So the inbound path exists, it is just scoped to a link you issued rather than a permanent open door.
How Gokapi Works: A Go Server, a Data Directory, and Optional Object Storage
Gokapi is a single Go binary that serves a web UI and a REST API from one process. The Docker example binds port 53842 and mounts two volumes: gokapi-data at /app/data and gokapi-config at /app/config. That split tells you where the state lives. Configuration is separate from stored files, which matters when you back up or move an instance.
Stored files can stay local or go to S3. The README lists AWS S3 support and S3-compatible services such as Backblaze B2, and it marks cloud storage as optional. So the default deployment is disk-backed, and object storage is something you enable rather than something the architecture assumes.
Two mechanisms sit on top of the storage layer. File deduplication means identical files use no extra space, so the same attachment uploaded by five people is stored once. Built-in encryption is listed as a feature, including end-to-end encrypted uploads. The README does not spell out the key handling in the excerpt available here, so treat the exact threat model as something to confirm in the documentation before you rely on it for sensitive material.
Access control runs through user accounts with roles, and OpenID Connect is supported for providers like Authelia or Keycloak. That means you can avoid a second password database entirely if you already run an identity provider. The REST API is there for automation, and the UI can be adjusted with custom CSS and JavaScript.
Getting Gokapi Running: One Docker Command and a Setup Wizard
The README gives a single command for a trial run. It starts the container, mounts the two volumes, publishes the port on loopback only, and sets the timezone:
docker run --rm --name gokapi -v gokapi-data:/app/data -v gokapi-config:/app/config -p 127.0.0.1:53842:53842 -e TZ=UTC docker.io/f0rc3/gokapi:latest
After that you visit http://localhost:53842/setup and follow the setup wizard. The loopback binding is worth noticing. As written, the container is not reachable from other machines until you change the port mapping or put a reverse proxy in front of it. That is a sensible default for a first look and a deliberate extra step for production.
Bare metal is also supported on Linux, macOS and Windows. The README points to the installation guide at gokapi.readthedocs.io for that path rather than listing binary download steps here. Building from source uses the standard Makefile targets shown in the repository:
git clone https://github.com/Forceu/gokapi.git cd gokapi make build make test docker build -t gokapi:local .
System requirements are modest: one core, 256 MB of RAM, and 100 MB of storage plus whatever you store. The recommended figures are two or more cores, 512 MB or more, and an SSD. Those numbers are from the README, not from measurement, and they describe the server process rather than the transfer throughput you will see.
Where Gokapi Is the Wrong Tool
The absence of public upload is the feature and the limitation at the same time. If you are building a service where anyone can submit a file without an account, Gokapi is not that service, and the file request feature does not change this. A file request URL is issued by a registered user and the resulting uploads are visible only to that creator. That is a workflow for collecting documents from known counterparties, not an anonymous intake queue.
The second constraint is operational. Expiration is central to how shares work, and the README describes it in terms of download counts and days. Once a share expires, the file is removed. Anyone who treats Gokapi as an archive rather than a transfer mechanism will lose data. There is no indication in the supplied material of a retention or legal-hold mode.
Deployment assumptions matter too. The README recommends an SSD, which is a hint that the local storage path is the expected default and that spinning disks will feel slow. If you plan to run on a cheap VPS with network-attached storage, the S3 option is the more appropriate route, and it brings its own costs and a dependency on an external service.
Finally, the licence is AGPL-3.0. For self-hosting inside an organisation this is usually unremarkable. If you intend to modify Gokapi and offer it to others over a network, the copyleft terms are the thing to read carefully. That is a description of the licence, not legal advice.
How Gokapi Differs From Nextcloud and Plain S3 Buckets
The obvious comparison is Nextcloud. Nextcloud is a general collaboration platform: file sync, calendars, contacts, document editing, a large app ecosystem, and a correspondingly large operational footprint. Gokapi does one job. You upload a file, you get a link, the link expires. There is no desktop sync client in the feature list, no document editing, no groupware. Choosing between them is mostly a question of whether you want a platform or a utility.
The other comparison is a raw S3 bucket with presigned URLs. That approach is cheaper in software terms because there is no software, but you give up the parts of Gokapi that are actually work: user accounts with roles, download-count expiration, deduplication, a web UI, and the REST API. Presigned URLs also expire on a timer you set, not on a number of downloads, and there is no file request concept. Gokapi sits between the two, wrapping object storage in an application that non-technical users can operate.
Compared with the hosted Send successors, the difference is custody. With Gokapi the files sit on your disk or in your S3 bucket, subject to your retention settings. That is the entire point of the project, and it is also the entire cost: you own the backups, the TLS certificate, and the uptime.
Maintenance, Releases and the AGPL-3.0 Question
The release cadence visible in the repository is steady rather than frantic. v2.2.2, v2.2.3 and v2.2.4 arrived between late January and mid March 2026, and the last push to master is dated August 2026. Patch releases at that interval suggest active bug fixing and a maintainer who ships small changes rather than saving everything for a major version. There is no long-term support branch mentioned in the material, so upgrades are the maintenance path.
Upgrade cost is mostly about the two volumes. Because configuration and data are mounted separately, a container upgrade is a matter of pulling a new image and restarting against the same mounts. The README does not document a migration procedure or a database schema version in the excerpt available here, so check the release notes for the specific version you are jumping to before you replace a running instance.
AGPL-3.0 is the licence, and the practical implication is straightforward for the common case: running Gokapi for your own organisation does not trigger distribution obligations. Modifying it and exposing the modified version to users over a network is the scenario the licence addresses. If that is your plan, read LICENSE.md and get proper advice rather than relying on a summary.
Who Should Run Gokapi
Run it if you have a defined group of users and a need to hand files outward with automatic expiry. The user management and role system means you can give accounts to the people who need them and keep everyone else out. The file request feature covers inbound transfers from clients or partners without turning your server into an open drop. OpenID Connect support means you can plug it into Authelia or Keycloak and avoid managing another credential store.
Do not run it if you need anonymous uploads, if you need long-term archival storage, or if you are looking for a collaboration suite. The README is explicit that only registered users can upload, and the expiration model is designed to delete things. Those are not gaps to work around; they are the shape of the product.
Before you commit, verify three things in the documentation rather than in this article. First, how end-to-end encrypted uploads handle keys, since the README lists the feature without describing the mechanism. Second, which S3-compatible providers are actually tested, because the README names AWS S3 and Backblaze B2 as examples and compatibility claims vary by provider. Third, the upgrade procedure between minor versions, since the release history shows frequent small releases and the material here does not describe a migration path.
Editorial conclusion
Adopt Gokapi if you run a small private instance for a known group of people and you already have an identity provider or are happy with local accounts. Do not adopt it if your workflow depends on anonymous public uploads, since the README states only registered users can upload. Before committing, verify the download and expiry accounting in the documentation, check that your S3 provider is on the supported list, and confirm the AGPL-3.0 obligations against how you intend to expose the service.
Community notes