Gokapi vs Send: Self-Hosted File Sharing Compared
Quick Verdict
Gokapi and Send solve different problems despite both generating expiring download links. Send is the better choice when you need to share files with other people securely — it offers end-to-end encryption and lets anyone upload through a browser. Gokapi wins when you need admin-controlled file distribution — only you upload, and files expire automatically by time or download count with zero external dependencies.
Pick based on who uploads: if it’s just you, Gokapi. If other people need to send files too, Send.
Overview
Gokapi is a lightweight Go application built as a simpler alternative to Firefox Send. It focuses on one workflow: an admin uploads a file, gets a link, shares that link, and the file auto-expires after a set number of downloads or a time limit. There are no user accounts — just a single admin password. It compiles to a single binary, uses SQLite internally, and needs nothing else to run.
Send is the community-maintained fork of Mozilla’s discontinued Firefox Send. It provides end-to-end encrypted file sharing where anyone with access to the instance can upload files through a clean web UI. Files are encrypted client-side before upload, meaning even the server operator cannot read them. It requires Redis as a dependency and runs on Node.js.
The Key Differentiator: Security Model
This is where these two tools diverge fundamentally, and it should drive your decision.
Gokapi: Server-Controlled Security
Gokapi stores files on the server in plaintext (or optionally encrypted at rest with a server-side key). The admin controls everything — who gets links, when files expire, how many times they can be downloaded. Security depends entirely on the server. If someone compromises the server, they have access to every uploaded file.
This is fine when the admin is the only uploader and trust is centralized. You control the files, you control access, you control expiry.
Send: End-to-End Encryption
Send encrypts files in the browser before they ever leave the uploader’s machine. The encryption key is embedded in the URL fragment (the part after #), which is never sent to the server. The server stores only encrypted blobs it cannot decrypt.
This means:
- The server operator cannot read uploaded files
- A server breach exposes only encrypted data
- The person with the link is the only one who can decrypt the file
This is a meaningfully stronger security model for sharing sensitive files with others. If you’re sending contracts, credentials, or personal documents, Send’s architecture is superior.
Feature Comparison
| Feature | Gokapi | Send |
|---|---|---|
| End-to-end encryption | No (server-side optional) | Yes (client-side, in-browser) |
| Who can upload | Admin only | Anyone with access to the instance |
| User accounts | Single admin password | None (anonymous uploads) |
| Expiry by download count | Yes | Yes |
| Expiry by time | Yes | Yes |
| Password-protected downloads | No | Yes |
| Max file size (default) | Unlimited (configurable) | 2.5 GB (configurable) |
| API for programmatic uploads | Yes (REST API) | Yes |
| S3/cloud storage backend | Yes (AWS S3, Backblaze B2, etc.) | No (local filesystem only) |
| External dependencies | None (embedded SQLite) | Redis |
| Language / Runtime | Go (single binary) | Node.js |
| License | MIT | MPL-2.0 |
| RAM usage (idle) | ~15 MB | ~80 MB |
| Active development | Yes | Community-maintained fork |
| Mobile-friendly UI | Yes | Yes |
Docker Compose: Gokapi
Gokapi needs nothing beyond its own container. Create a docker-compose.yml:
services:
gokapi:
image: f0rc3/gokapi:v1.9.6
container_name: gokapi
restart: unless-stopped
ports:
- "127.0.0.1:53842:53842"
volumes:
- gokapi_data:/app/data
- gokapi_config:/app/config
environment:
# Bind address inside the container
- GOKAPI_PORT=53842
# Set the external URL users will access (change to your domain)
- GOKAPI_EXTERNAL_URL=https://share.example.com
# Length of the download URL IDs
- GOKAPI_LENGTH_ID=15
# Username for admin panel
- GOKAPI_USERNAME=admin
# Password for admin panel — CHANGE THIS
- GOKAPI_PASSWORD=changeme-use-a-strong-password
# Redirect URL after download link expires
- GOKAPI_REDIRECT_URL=https://example.com
# Max file size in MB (0 = unlimited)
- GOKAPI_MAX_FILESIZE=0
volumes:
gokapi_data:
gokapi_config:
Start it:
docker compose up -d
Access the admin panel at http://localhost:53842/admin. Log in with the credentials you set, upload a file, configure expiry, and share the generated link.
Docker Compose: Send
Send requires Redis for session and metadata storage. Create a docker-compose.yml:
services:
send:
image: registry.gitlab.com/timvisee/send:v3.4.23
container_name: send
restart: unless-stopped
ports:
- "127.0.0.1:1443:1443"
volumes:
- send_uploads:/uploads
environment:
# Base URL users will access (change to your domain)
- BASE_URL=https://send.example.com
# Port inside the container
- PORT=1443
# Redis connection string
- REDIS_HOST=send-redis
# Maximum file size in bytes (2.5 GB)
- MAX_FILE_SIZE=2684354560
# Maximum number of downloads before expiry
- MAX_DOWNLOADS=100
# Maximum expiry time in seconds (7 days)
- MAX_EXPIRE_SECONDS=604800
# Default download limit
- DOWNLOAD_COUNTS=1,2,5,10,25,50,100
# Default expiry time options in seconds (5min, 1hr, 1day, 7days)
- EXPIRE_TIMES_SECONDS=300,3600,86400,604800
# Maximum total uploads in bytes (10 GB)
- MAX_FILES_PER_ARCHIVE=64
depends_on:
- send-redis
send-redis:
image: redis:7.2-alpine
container_name: send-redis
restart: unless-stopped
volumes:
- send_redis_data:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 3
volumes:
send_uploads:
send_redis_data:
Start it:
docker compose up -d
Open http://localhost:1443 in a browser. The upload page is immediately available — no login required. Upload a file, set expiry options, and share the generated link.
Installation Complexity
Gokapi is simpler to deploy. One container, zero dependencies, configure via environment variables, and it works. The admin panel is available immediately. Total setup time: under five minutes.
Send requires Redis, which adds a second container and a failure point. The configuration has more options to tune, particularly around file size limits and expiry defaults. Setup is still straightforward but takes slightly longer and has more moving parts.
Winner: Gokapi, by a clear margin.
Performance and Resource Usage
| Metric | Gokapi | Send |
|---|---|---|
| RAM (idle) | ~15 MB | ~80 MB |
| RAM (under load) | ~30-50 MB | ~150-250 MB |
| CPU (idle) | Negligible | Negligible |
| Disk (application) | ~20 MB | ~200 MB (Node.js + dependencies) |
| Additional services | None | Redis (~10 MB idle) |
Gokapi is dramatically lighter. It runs comfortably on a Raspberry Pi or a $5/month VPS alongside a dozen other services. Send’s Node.js runtime and Redis dependency mean it needs more resources, though it’s still modest by modern standards.
For resource-constrained environments, Gokapi is the obvious choice.
Storage Backends
Gokapi supports S3-compatible storage backends (AWS S3, Backblaze B2, MinIO, Wasabi) out of the box. This means uploaded files can live on cheap cloud object storage rather than consuming local disk. For large file distribution or limited local storage, this is a significant advantage.
Send stores files on the local filesystem only. You can mount a network share or external drive, but there is no native cloud storage integration. Since files are encrypted client-side, this is less of a concern for security — but it limits scalability.
Community and Support
Gokapi is developed by a single maintainer with consistent releases. The GitHub repository is active, issues get responses, and documentation is thorough for its scope. Community is small but focused.
Send is a community fork of Mozilla’s Firefox Send, which was discontinued in 2020. The fork is maintained by Tim Visee and a small group of contributors. Development is slower than the original Mozilla project, but the core functionality is stable and well-tested from its Firefox Send heritage. The larger legacy community means more Stack Overflow answers and blog posts exist.
Use Cases
Choose Gokapi If…
- You are the only person who uploads files
- You want a dead-simple setup with no external dependencies
- You need S3 storage backend support for large file distribution
- You run on resource-constrained hardware (Pi, cheap VPS)
- You want admin-controlled expiry with no user-facing upload page
- You distribute files to others (software builds, documentation, temp shares) but don’t need them to send files back
- You want an API for automated uploads from scripts or CI/CD pipelines
Choose Send If…
- Other people need to send files to you or to each other
- End-to-end encryption is a requirement (legal, compliance, or personal preference)
- You want password-protected download links
- You need a clean, public-facing upload interface
- You’re sharing sensitive documents where even the server operator shouldn’t have access
- You previously used Firefox Send and want the same experience self-hosted
Final Verdict
Gokapi is the better tool for admin-controlled file distribution. If you just need to upload files and share expiring links — firmware updates, build artifacts, documents for clients — Gokapi does it with minimal resources and zero complexity. The S3 backend support is a genuine differentiator for large-scale use.
Send is the better tool for file sharing between people. The end-to-end encryption is not a gimmick — it is a fundamentally stronger security model. If you share sensitive files with clients, colleagues, or anyone who might also need to send files back to you, Send is the right choice despite the higher resource cost and Redis dependency.
For most self-hosters running a personal setup, Gokapi covers 80% of use cases with 20% of the complexity. If encryption matters to you — and for sensitive file sharing, it should — Send justifies the extra overhead.
Related
Get self-hosting tips in your inbox
Get the Docker Compose configs, hardware picks, and setup shortcuts we don't put in articles. Weekly. No spam.
Comments