# Gokapi: a self-hosted Firefox Send replacement where only registered users can upload

> Gokapi is a Go file-sharing server that expires links by download count or age, keeps uploads behind user accounts, and can push file data to S3 or Backblaze B2. Here is how the Docker setup works, what the encryption and deduplication actually cover, and where the design will frustrate you.

**Forceu/Gokapi** — Lightweight selfhosted Firefox Send alternative without public upload. AWS S3 supported.

- Repository: https://github.com/Forceu/Gokapi
- Stars: 2,891 · Forks: 153
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/forceu-gokapi

## The problem Gokapi solves: expiring links without an open upload form

Firefox Send let anyone drop a file and hand out a link that died after a set number of downloads. Mozilla shut it down in 2020, and most replacements that appeared afterwards either require an account with a third party or expose a public upload endpoint that anyone who finds the URL can abuse. Gokapi takes the second problem seriously: the README states that only registered users can upload. A stranger who discovers your instance cannot fill your disk.

The intended operator is someone running a small server for a team, a family, or a client-facing workflow. The README lists user management with roles and OpenID Connect support for identity providers such as Authelia or Keycloak, which points at the same audience: an organisation that already has a login system and wants file sharing to sit behind it. The system requirements are modest, with a stated minimum of 1 CPU core, 256 MB of RAM and 100 MB of storage plus whatever you store in files, so a small VPS is enough. If you were hoping for a public drop box, this is the wrong project by design.

## How Gokapi handles expiry, deduplication and encryption

The mechanism is a single Go binary backed by a local database and a file store. The dependency list in go.mod shows modernc.org/sqlite for the database, the AWS SDK for Go for S3, redigo plus miniredis for Redis-backed caching or sessions, and secure-io/sio-go, which is the library behind the encryption layer. That combination tells you the shape of the system: metadata lives in SQLite, file bytes live either on local disk or in an S3-compatible bucket, and encryption is applied at the file level rather than by relying on the storage provider.

Expiry is tracked per share. The README describes shares being removed automatically after a set number of downloads or days, so the counter and the deadline are attributes of the share record rather than a cron job that scans the filesystem. Deduplication works on identical files, which the README says use no extra space. That is a content-addressable store in effect: the same bytes uploaded twice resolve to one stored object, and each share is a pointer with its own expiry rules. It also means deleting one share does not necessarily free the bytes if another share still references the same content.

End-to-end encrypted uploads are the part worth reading carefully. The README lists built-in encryption including end-to-end encrypted uploads, and sio-go is an authenticated encryption stream library. The trade-off is standard: if the key never reaches the server, the server cannot help you recover a file, and a lost key means a lost file. The README does not document a key escrow or recovery path, so treat the client-side key as the only copy. Custom CSS and JavaScript are also supported, which is a real surface: an operator who pastes third-party JavaScript into the UI is running it in the same origin as the session.

## Installing Gokapi with Docker and finishing the setup wizard

The README gives a one-line Docker invocation. It mounts two volumes, one for data and one for config, and publishes the service on port 53842 bound to localhost. The environment variable TZ sets the timezone used for date-based expiry, which matters if you schedule shares to end on a calendar day.

```bash
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 the container starts, the README says to visit http://localhost:53842/setup and follow the setup wizard. The wizard is where the admin account is created and where you choose storage behaviour, so the first real use is not uploading a file, it is completing that page. The repository also ships a docker-compose.yaml that uses the image f0rc3/gokapi:latest, mounts ./gokapi-data and ./gokapi-config as relative paths, and reads an env file at ./.env, which is the more practical form for a long-running instance.

```yaml
services:
  gokapi:
    image: f0rc3/gokapi:latest
    container_name: gokapi
    ports:
      - "127.0.0.1:53842:53842"
    volumes:
      - ./gokapi-data:/app/data
      - ./gokapi-config:/app/config
    restart: always
    env_file:
      - "./.env"
```

Note the bind address in both examples: 127.0.0.1, not 0.0.0.0. The project ships it that way deliberately, and you are expected to put a reverse proxy in front for TLS rather than exposing the Go server directly. The Dockerfile also defines a health check that curls http://127.0.0.1:53842 every 10 seconds, so a proxy or orchestrator can tell a live instance from a hung one. If you build from source instead, the README gives the sequence: clone the repository, run make build, run make test, and optionally docker build -t gokapi:local . The go.mod file targets Go 1.26.0, so an older toolchain will not compile it.

## Where Gokapi is the wrong tool

The registered-users-only upload rule is the design, and it is also the limitation. Any workflow that depends on an unauthenticated person handing you a file will not fit. The file requests feature is the intended answer: the README describes a shareable URL that lets external parties upload files, visible only to the creator of that URL. That is a per-request grant, not an open door, and it means someone on your side has to create the request first. If you want a permanent public inbox, look elsewhere.

End-to-end encryption has the failure mode described above: no documented recovery. There is a second, quieter cost. Deduplication and per-file encryption pull in opposite directions, and the README does not explain how the two interact for encrypted uploads, so do not assume an encrypted file will deduplicate against an unencrypted copy of the same bytes. Test it on your own instance before you plan capacity around it.

The project is licensed AGPL-3.0. If you only run it for your own organisation, that is unremarkable. If you modify it and expose it to users over a network, the licence's network clause is the part your legal team needs to read. Nothing here is legal advice, and the LICENSE.md file in the repository is the authoritative text.

Finally, the README is a feature list with links out to Read the Docs for installation and usage. Details such as rollback after a failed upgrade, database migration behaviour between versions, and what happens to shares when you switch storage backends are not in the README, so those are questions for the documentation site or the issue tracker rather than something you can confirm from the repository root.

## Gokapi compared with Pingvin Share, PicoShare and Erugo

The closest comparison people search for is Pingvin Share. Both are self-hosted file-sharing servers aimed at replacing Firefox Send, and both offer expiring links. The difference that shows up first is the upload model: Gokapi restricts uploading to registered users, while the general pattern for this category of tool is to allow anyone who can reach the instance to upload. If your threat model includes a stranger filling your disk through a public endpoint, Gokapi's default is the stricter one, and you pay for it with an extra account-provisioning step.

PicoShare sits at the opposite end on scope. It is deliberately small, and the searches around it are usually about running it in Docker rather than about user roles or identity providers. Gokapi carries user management with roles, OpenID Connect, a REST API, an OpenAPI description in the repository root, and optional S3 or Backblaze B2 storage. That is more surface to configure and more surface to get wrong. Erugo is another name in the same space; the shared idea is expiring links on infrastructure you control.

The practical split is storage. Gokapi's optional S3 support means the file bytes can live in a bucket while the metadata stays in SQLite next to the binary, so the application server does not need a large disk. Tools that only write to local storage make you size the VM around the files. If your files are large or numerous, that distinction decides the deployment.

## Upgrades, the REST API and ongoing cost

The release cadence visible in the repository is steady but not fast: v2.2.2 on 2026-01-31, v2.2.3 on 2026-03-04, and v2.2.4 on 2026-03-10, with the last push to the master branch on 2026-08-27. That is a project that moves in small version bumps rather than continuous churn, which is usually good news for operators: fewer breaking changes to chase. It also means a fix you are waiting for may sit until the next release rather than landing the same week.

Upgrade cost in the Docker path is low. Pull the new tag, restart the container, and the mounted config and data volumes persist. The cost that is not visible from the README is schema migration: Gokapi uses SQLite, and the README does not document a downgrade path. Back up the volume under /app/data before you pull, because a newer binary that has migrated the database will not necessarily run under an older one.

The REST API is the other long-term cost and the other long-term benefit. An openapi.json file sits in the repository root, so the API surface is described in a machine-readable form rather than only in prose. That makes it reasonable to script uploads or integrate Gokapi into an existing pipeline instead of asking people to use the web UI. The trade-off is that API clients become another thing to test when you upgrade.

On licensing: AGPL-3.0 covers the whole project, and the README points to LICENSE.md. Running it privately and modifying it privately carries no distribution obligation. Offering a modified version to users over a network is where the network clause applies, and that is a question for your own counsel, not for a review.

## Conclusion

Adopt Gokapi if you want a private file drop where uploads are restricted to accounts you create, links expire on a download count or a date, and the storage backend can be a bucket rather than your disk. Do not adopt it if you need an anonymous public drop box, or if AGPL-3.0 obligations are a problem for the way you ship software. Before committing, verify the port binding in your own compose file, check the setup wizard at /setup completes against your chosen database and storage backend, and test what happens to an end-to-end encrypted upload when you lose the key.

## FAQ

### Is Gokapital legit?

This search question does not match the project under review. The repository examined here is Forceu/Gokapi, a self-hosted file-sharing server written in Go and licensed AGPL-3.0, and the material contains no information about anything called Gokapital.

### What is Gokapi?

Gokapi is a self-hosted file-sharing server written in Go, described in its README as an alternative to Firefox Send. It expires shares after a set number of downloads or days, restricts uploading to registered users, and can store file bytes on local disk or in S3-compatible storage such as Backblaze B2.

### What is the default port for Gokapi?

Both the README's docker run example and the repository's docker-compose.yaml publish port 53842, bound to 127.0.0.1. The setup wizard is then reached at http://localhost:53842/setup.

### Does Gokapi let anyone upload files?

No. The README states that only registered users can upload. External parties can send files through the file requests feature, where a shareable URL is created by a user and the resulting uploads are visible only to that URL's creator.

## Sources

- [Forceu/Gokapi on GitHub](https://github.com/Forceu/Gokapi)
- [Issues](https://github.com/Forceu/Gokapi/issues)
- [License: AGPL-3.0](https://github.com/Forceu/Gokapi/blob/master/LICENSE)
- [README](https://github.com/Forceu/Gokapi/blob/master/README.md)
- [Releases](https://github.com/Forceu/Gokapi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/forceu-gokapi