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

FeatureGokapiSend
End-to-end encryptionNo (server-side optional)Yes (client-side, in-browser)
Who can uploadAdmin onlyAnyone with access to the instance
User accountsSingle admin passwordNone (anonymous uploads)
Expiry by download countYesYes
Expiry by timeYesYes
Password-protected downloadsNoYes
Max file size (default)Unlimited (configurable)2.5 GB (configurable)
API for programmatic uploadsYes (REST API)Yes
S3/cloud storage backendYes (AWS S3, Backblaze B2, etc.)No (local filesystem only)
External dependenciesNone (embedded SQLite)Redis
Language / RuntimeGo (single binary)Node.js
LicenseMITMPL-2.0
RAM usage (idle)~15 MB~80 MB
Active developmentYesCommunity-maintained fork
Mobile-friendly UIYesYes

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

MetricGokapiSend
RAM (idle)~15 MB~80 MB
RAM (under load)~30-50 MB~150-250 MB
CPU (idle)NegligibleNegligible
Disk (application)~20 MB~200 MB (Node.js + dependencies)
Additional servicesNoneRedis (~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.

Comments