goploader

Self-hosted ephemeral file sharing, honestly reviewed. Built for terminal users who care that the server never sees their files.

TL;DR

• What it is: Self-hosted file sharing server and companion CLI client, both written in Go. You upload a file from your terminal with a single command; the server encrypts it on arrival and returns a URL containing the decryption key — a key the server never stores [README].
• Who it’s for: Developers and sysadmins who regularly share files over the terminal and want a private, self-hosted alternative to services like WeTransfer or file.io. Non-technical founders: this is not for you.
• Cost: Free software (MIT). Running costs are a VPS, nothing else. No SaaS tier exists [README].
• Key strength: The encryption model is genuinely thoughtful — AES-encrypted on arrival, key embedded in the URL, server stores no decryption capability [README][website].
• Key weakness: The README includes an explicit warning: “This repository is maintained as is but most of the tech used for this project is now outdated. Use at your own risk.” The project has ~300 GitHub stars and no meaningful third-party review coverage. This is maintenance-mode software [README].

---

What is goploader

goploader is a two-part application: a Go server you self-host and a Go CLI client your users run locally. The premise is simple — you install the server on a VPS, point people at it, and they can share files from a terminal with a single command. What separates it from a naive file upload server is the encryption model.

When a file arrives at the server, the server creates a unique identifier and a unique AES encryption key, streams the file data through the cipher directly to disk (never loading the full file into RAM unencrypted), and then discards the key. The key is returned to the client as the second path component in the returned URL: [scheme][server]/v/(uid)/(key). Anyone with the URL can download and decrypt the file; anyone without it — including the server operator — cannot [README][website].

The project was built by a single developer (Depado) as a Go learning project, inspired by 0bin’s client-side encryption philosophy applied to file uploads. The public instance ran at gpldr.in. The GitHub repository sits at around 300 stars [README].

What you should know before going further: the README currently contains a yellow warning box that reads “This repository is maintained as is but most of the tech used for this project is now outdated. Use at your own risk.” That is the developer being honest. The Go ecosystem, the dependencies, and the surrounding infrastructure landscape have moved on since this was written. You’re looking at a project that did something clever and then stopped.

---

Why people choose it

There are no meaningful third-party reviews of goploader available. The GitHub star count (~300) suggests a small but appreciative audience of developers who wanted exactly this thing: terminal-friendly file sharing where the server operator has zero ability to read the uploaded content.

The appeal, based on the project’s own documentation and design, is architectural. Most self-hosted file sharing tools — even privacy-focused ones — store files in cleartext on disk, trusting filesystem permissions and access controls to protect them. goploader flips that: even if someone gains read access to the server’s storage directory, the files are encrypted with a key that was only ever returned to the uploader via the URL. The server logs the uploader’s IP for legal reasons but never the decryption key [website].

For developers who share sensitive output — config dumps, log files, build artifacts, database exports — this is a meaningfully different threat model than “trust your VPS provider.”

The curl compatibility is also practical. You don’t need the goploader client to use the service; a standard multipart POST works:

curl -F "[email protected]" https://your-instance.com/upload

This is explicitly by design. The project calls it “curl compliant” [README][website]. That means any scripting environment, CI system, or colleague without the client installed can still use the service.

---

Features

Based on the README and project website documentation [README][website]:

Upload methods:

• CLI client with a single command: gpldr yourfile.txt
• Upload from stdin: pipe content directly to the client
• curl/httpie/wget compatible multipart form upload — no client required
• Clipboard integration (copies the resulting URL to clipboard via the client)
• Progress bar in the CLI client

Encryption:

• AES cipher applied as the upload streams to disk — file is never fully in RAM unencrypted [website]
• Unique encryption key generated per upload
• Key never stored on server, only returned in the URL [website]
• Configurable key length in server config [website]

Storage:

• Bolt embedded key-value store (no external database needed)
• Files stored encrypted on disk with unique identifiers
• Deletion date stored per file in the database [website]

Server features:

• Written in Go — single binary deployment
• Docker support (Docker Compose not shipped, but docker run documented) [README]
• First-run setup web interface when running in Docker
• Web upload interface in addition to CLI
• HTTPS via Let’s Encrypt + Caddy Server (on the public instance; your setup is your responsibility) [website]

Client features:

• Posix flags (pflag)
• Home directory detection for config file
• Config stored at ~/.config/goploader.conf.yml, auto-created on first run [website]

What it does not have:

• Authentication or access control on uploads
• File listing or management UI
• Expiry controls beyond a single delete date
• Any API beyond the multipart form
• Resumable uploads
• Folder or multi-file archiving
• Any webhook or notification system

---

Pricing: SaaS vs self-hosted math

goploader has no SaaS tier. There is no hosted version you can subscribe to. The only cost model is running your own instance.

What you need:

• A Linux VPS: $4–6/month (Hetzner Nanode, Contabo S, DigitalOcean Basic)
• A domain name: $10–15/year if you want a clean URL
• Storage proportional to what you share — files are kept until their deletion date

Comparison to alternatives (for context):

• WeTransfer Free: 2GB file limit, files deleted after 7 days, data passes through WeTransfer’s servers
• file.io: 100MB free, files deleted after one download, closed source
• Running goploader on a $5/mo VPS: no file size limit beyond disk space, files encrypted at rest, server you control

There is no useful “SaaS savings” math here because goploader has no commercial equivalent. The honest comparison is against other self-hosted options (see Alternatives section), not against commercial services.

---

Deployment reality check

The README documents two deployment paths: build from source and Docker.

Build from source:

git clone https://github.com/depado/goploader.git
cd goploader
go build -trimpath -ldflags '-s -w' -o goploader-server ./server/
./goploader-server

This is straightforward if you have Go installed. The binary is self-contained. No docker, no external database, no Redis — the Bolt embedded store handles persistence [README].

Docker:

make docker
docker run --rm --name=goploader -v goploader:/data -p 8080:8080 gpldr:latest

A setup web interface is available at http://127.0.0.1:8080 on first run [README]. This lowers the barrier considerably compared to editing config files.

What can go sideways:

The “outdated tech” warning in the README is real. The project uses:

• Go 1.18 (current stable is 1.22+) — likely still builds, but dependency updates have not been applied [README]
• github.com/boltdb/bolt — the original Bolt, not the maintained bbolt fork [README]
• github.com/GeertJohan/go.rice — for resource embedding, superseded by Go’s native embed package since Go 1.16 [README]

None of these are fatal for a personal deployment, but they mean you’re running dependencies that haven’t received security patches in years. For a service exposed to the internet and handling potentially sensitive files, that is worth taking seriously.

The server logs uploader IPs “for debugging purposes and legal requirements” [website]. If your use case requires not logging this, you’d need to patch the server code.

There is no documented rate limiting, abuse prevention, or upload size restriction configuration in the README. On a public-facing instance, you’d want to handle this at the reverse proxy layer (nginx or Caddy) before traffic reaches goploader.

Realistic setup time for a developer: 20–40 minutes to a working instance including DNS and TLS via Caddy. For someone unfamiliar with deploying Go services: budget 2 hours including troubleshooting.

---

Pros and cons

Pros

• Encryption model is sound. The key-in-URL design means the server operator genuinely cannot read stored files without access to URL logs [README][website]. This is a real architectural property, not marketing.
• curl compatibility. No client required to use the service. Works from any scripting context, CI environment, or remote server [README][website].
• Single binary. The server compiles to one Go binary. No runtime dependencies, no database service, no Redis. Embedded Bolt handles storage [README].
• MIT license. Do what you want with it [README].
• Streaming encryption. Files are never fully loaded into RAM unencrypted — they’re piped through the AES cipher as they arrive [website]. Reasonable for large file handling.
• Simple. The codebase is small and legible. If you need to patch something, you can.

Cons

• Maintenance-mode warning from the author. The developer explicitly says the tech is outdated and to use at your own risk [README]. This is not a project with active development.
• Outdated dependencies. Go 1.18, unmaintained boltdb fork, deprecated resource embedding approach — none of these are patched against recent vulnerabilities [README].
• No authentication. Anyone who can reach the upload endpoint can upload files. You’re responsible for rate limiting, abuse prevention, and access control at the infra layer [README].
• No expiry management. There’s no automated cleanup job documented in the README. Files sit until their deletion date, but managing storage over time is your problem.
• No community. ~300 GitHub stars, no recent issues or PRs, no ecosystem of plugins or guides. When something breaks, you’re reading the code [README].
• No multi-file or folder support. If you need to share a directory, you’re zipping it yourself [website].
• Key-in-URL has tradeoffs. The decryption key lives in the URL. Anyone who sees that URL in logs, referrer headers, or browser history can download and decrypt the file. The model protects against server compromise but not against URL leakage.

---

Who should use this / who shouldn’t

Use goploader if:

• You’re a developer or sysadmin who frequently shares sensitive files over the terminal and wants a self-hosted option where the server operator (including yourself) cannot trivially read stored content.
• You want something simple enough to audit yourself — the codebase is small and the encryption logic is readable.
• curl compatibility matters more to you than a polished UI or active maintenance.
• You’re deploying for personal or small team use and can handle the infra hygiene yourself.

Skip it if:

• You want something actively maintained. There are better-maintained alternatives (see below).
• Your threat model requires scrutinized, up-to-date dependencies. The outdated stack is a real concern for a service handling sensitive files.
• You’re deploying for a team that needs any kind of access management, user accounts, or upload restrictions — goploader has none of this.
• You’re a non-technical founder. This requires comfort with Go builds or Docker, reverse proxy configuration, and terminal-based file sharing.
• You need large file support at scale. There’s no chunked upload, no resumability.

---

Alternatives worth considering

• Gokapi — Actively maintained self-hosted file sharing with expiry, download limits, optional password protection, S3 support, and a web UI. Closer to a WeTransfer replacement, easier to recommend in 2026.
• PsiTransfer — Simple, no-database self-hosted file drop with configurable retention. Still maintained.
• FileShelter — Web-first self-hosted file sharing with expiry and password protection. More approachable UI for non-CLI users.
• transfer.sh — The project goploader was partly inspired by. CLI-first file sharing with optional encryption. Has seen more recent activity.
• Lufi — End-to-end encrypted file sharing where encryption happens client-side in the browser. Stronger privacy model than goploader for browser uploads.
• OnionShare — If the threat model is serious, OnionShare routes file transfers over Tor. Overkill for most cases, appropriate for some.
• Nextcloud — If you need file sharing as part of a broader collaboration suite. Much heavier to deploy but actively maintained and enterprise-grade.

For most people looking for a terminal-friendly self-hosted file sharing tool in 2026, Gokapi is the cleaner recommendation: it solves the same problem, is actively developed, and has proper access controls. goploader made architectural decisions in 2015 that were ahead of their time; the ecosystem has caught up.

---

Bottom line

goploader is a clever 2015-era project that got the encryption model right — the key-in-URL design genuinely means the server never has the ability to decrypt stored files, which is a meaningful security property. For a developer who wants that specific guarantee and is comfortable maintaining outdated Go dependencies on a personal VPS, it works. But the author has told you plainly that the tech is outdated, and there are actively maintained alternatives that have caught up to the core idea. If you’re building a personal tool-sharing setup today and the encryption model appeals to you, read the goploader source to understand how it works, then deploy Gokapi. If you specifically need goploader’s design and can accept the maintenance debt, it’s a small codebase you can fork and update yourself — the MIT license makes that straightforward.

---

Sources

1. goploader README — GitHub repository, depado/goploader. https://github.com/depado/goploader
2. goploader Documentation Website — Official project docs including features, process description, and disclaimer. https://depado.github.io/goploader/

Note: No third-party reviews of goploader were available in the source materials provided. Sources [1] and [2] are the primary project documentation. All claims in this review are grounded in the project’s own README and website.