PicoShare

Minimalist, honest, and surprisingly useful. A review for founders who just want to send a file without explaining themselves to WeTransfer.

TL;DR

• What it is: A self-hosted web app for sharing files with direct download links — no ads, no signups required from recipients, no size or type limits [README].
• Who it’s for: Founders and small teams who regularly share large files (recordings, exports, design assets, archives) and are tired of WeTransfer’s 2GB limit, expiring links, or per-month fees.
• Cost savings: WeTransfer Pro runs $12/mo. Dropbox Business starts at $15/user/mo. PicoShare self-hosted on a $5 VPS is $5/mo, unlimited files, no expiry unless you set one.
• Key strength: It does exactly one thing — generate a permanent, direct download link for any file, any size — and doesn’t try to do anything else [README].
• Key weakness: Single admin only, no multi-user support, no file preview beyond what the browser natively handles, no horizontal scaling. If you need a team file management system, this isn’t it [README].
• License: AGPL-3.0. Free to self-host, but modifications must be open-sourced if you run it as a service [README].

---

What is PicoShare

PicoShare is a single-admin, self-hosted file sharing tool written in Go. You upload a file through a simple web UI, get a direct download link, and share it with anyone. The recipient clicks the link and gets the file — no account creation, no ad interstitial, no “sign up to download faster” nag screen [README].

The project is maintained by Michael Lynch, a software engineer who writes extensively about software and freelancing. It sits at 2,855 GitHub stars with 196 forks and 43 releases — modest numbers by comparison to heavy-duty tools like Nextcloud, but meaningful for a tool this narrow in scope [GitHub].

The database is SQLite, which means the entire state of your instance lives in a single file. That’s either reassuring (simple backups, no separate database server) or a constraint (no multi-instance writes), depending on your needs. The README explicitly notes you can only run one Docker container per Litestream replication target for exactly this reason [README].

What PicoShare is not: a full cloud storage suite, a team file collaboration tool, an S3 frontend, or an image gallery. The README has an explicit section titled “PicoShare’s scope and future,” which signals the author has made deliberate decisions about what the project won’t become. That kind of restraint is rare, and in practice it means the tool stays maintainable and the UX stays coherent [README].

---

Why People Choose It

The GitHub star trajectory and forks suggest a real audience, even if no formal independent review sites have published coverage of PicoShare. The appeal is easy to reconstruct from the README’s own framing:

The WeTransfer problem. WeTransfer Free limits you to 2GB per transfer and deletes files after 7 days. Pro removes size limits and lets you keep files for a year, but at $12/month that’s $144/year for a tool that does one thing. If you’re regularly sharing 4K video exports, database dumps, or large design packages, you hit that limit constantly.

The Dropbox/Google Drive problem. These work, but the recipient needs to navigate a web interface, sometimes log in, and gets the full Dropbox/Drive chrome instead of just the file. For external clients or non-technical collaborators, the friction is real.

The “just give me a link” problem. PicoShare’s core promise is a direct download link. Not a preview page with a download button. A URL that, when opened, serves the file exactly as uploaded — no re-encoding, no resizing, no format conversion. You upload a .mov, the link downloads a .mov [README].

The data sovereignty angle. When you share files through a third-party SaaS, that file is on their servers, subject to their terms of service, and potentially accessible to their staff. For founders sharing investor decks, client contracts, or unreleased product demos, that’s a real concern — not paranoia.

---

Features

Based on the README:

Core sharing:

• Upload any file, any size, any type [README]
• Direct download link — no intermediate landing page, no ads [README]
• No re-encoding or format conversion — files are served byte-for-byte as uploaded [README]
• Simple admin UI for managing uploaded files
• Expiry controls — you can set files to expire after a given time or number of downloads (based on the project’s features section)

Infrastructure:

• Written in Go — single binary, low resource usage
• SQLite database — one file, simple backup
• Optional Litestream integration: automatic replication of the SQLite database to any S3-compatible storage (Backblaze B2, Cloudflare R2, AWS S3). If the container dies, it restores from the replica on next start [README]
• Docker and Docker Compose deployment [README]
• PS_BEHIND_PROXY environment variable for clean logging behind nginx/Caddy [README]

What it doesn’t have:

• Multiple user accounts — one admin password (PS_SHARED_SECRET) controls everything [README]
• File previews (beyond native browser handling — images and PDFs open in-browser, everything else downloads)
• Upload quotas or per-file size limits
• Analytics or download tracking beyond what you’d see in server logs
• Horizontal scaling — single instance only [README]
• REST API for programmatic uploads (would require scripting against the web UI or a custom implementation)

The absence of a REST API is a real gap if you want to automate uploads from a CI pipeline or integrate with other tools. You’re expected to upload manually through the browser UI.

---

Pricing: SaaS vs Self-Hosted Math

PicoShare: Free software (AGPL), you pay for hosting [README].

Typical self-host cost:

• Hetzner CX11 (2GB RAM): ~$4/mo
• Contabo 4GB VPS: ~$5/mo
• Fly.io free tier: $0 (the repo includes a fly.toml, suggesting the author runs it there)
• Cloudflare R2 for Litestream backups: effectively free for a small SQLite database

WeTransfer:

• Free: 2GB limit, 7-day expiry
• Pro: $12/mo ($144/yr) — larger files, 1-year retention, custom domain

Dropbox:

• Plus: $9.99/mo — 2TB storage, but designed for sync not sharing
• Business: $15/user/mo

Google Drive/One:

• 2TB storage: $9.99/mo — again, sharing works but it’s not the primary use case

Concrete math for a typical founder:

You share 10–15 large files per month (Loom exports, design handoffs, client deliverables) and you’re on WeTransfer Pro at $12/mo. That’s $144/year. PicoShare on a $5 VPS is $60/year. The difference is $84/year, which pays for itself in the first two months.

If you’re on a team plan (Dropbox Business at $15/user for 3 users), that’s $540/year just for file sharing + sync. The comparison stops being interesting past a certain point.

The caveat: Litestream backup to R2 or B2 adds maybe $0.01/month for a small SQLite database. Storage for the actual files is local disk on your VPS — plan accordingly. A 20GB VPS disk fills up fast if you’re sharing large video files regularly.

---

Deployment Reality Check

PicoShare is genuinely one of the easier self-hosted tools to deploy. The Docker Compose setup is six lines [README]:

services:
  picoshare:
    image: mtlynch/picoshare
    environment:
      - PORT=4001
      - PS_SHARED_SECRET=dummypass
    ports:
      - 4001:4001
    command: -db /data/store.db
    volumes:
      - ./data:/data

What you actually need:

• A Linux VPS (512MB RAM is probably fine; 1GB to be comfortable)
• Docker installed
• A reverse proxy with HTTPS (Caddy is the easiest; nginx works)
• A domain or subdomain pointed at your server

What can go sideways:

• Disk space: There are no upload quotas. If a user finds your instance and uploads 50GB of junk, your VPS disk fills up. There’s no built-in quota system, so you’re relying on PS_SHARED_SECRET staying private.
• Single admin: If you want a colleague to upload files, they need the admin password. There’s no invite system, no role separation, no “read-only” or “upload-only” users.
• No multi-instance writes: If you want redundancy, you can replicate the database via Litestream, but you can only serve traffic from one instance at a time. This is fine for a small team; it’s a hard constraint if you expect high traffic [README].
• File persistence: Files live on the VPS disk. If you don’t set up Litestream or external backups, losing the VPS means losing all shared files and links. The Litestream setup in the README backs up the SQLite database (file metadata), but the actual file blobs are not included in that replication — you’d need separate disk backups or to mount external storage.

Realistic time estimate: 20–30 minutes for a technical user who has deployed Docker containers before. Under an hour including domain and HTTPS setup. For a non-technical founder following a guide: 2–3 hours, mostly spent on the reverse proxy and DNS propagation, not on PicoShare itself.

The project ships a fly.toml for Fly.io deployment, which means the author uses it on Fly.io and it works there. That’s a reasonable managed-infrastructure option if you don’t want to babysit a VPS.

---

Pros and Cons

Pros

• Does one thing well. Direct download links, no size limits, no re-encoding. The scope is explicitly constrained and that’s a feature, not a limitation [README].
• Minimal resource footprint. Go binary + SQLite. Runs on the cheapest VPS tier available. No PostgreSQL, no Redis, no background workers.
• Direct links work. The recipient clicks a URL and the file downloads. No accounts, no ads, no “install our app” prompts [README].
• Litestream integration is thoughtful. Cloud-replicated SQLite means you can kill and restart the container and it picks up exactly where it left off — no data loss, no manual restore step [README].
• Active maintenance. 43 releases, 541 commits, CircleCI integration. This isn’t abandonware [GitHub].
• Simple to reason about. One password, one database file, one process. Security surface is small. Disaster recovery is “restore the database file and restart the container.”

Cons

• Single admin only. No user accounts, no team sharing, no per-user permissions. The admin password is the only authentication. If multiple people need to upload, they all share the same credential [README].
• AGPL license, not MIT. If you want to embed PicoShare in your own commercial product or run it as a service for clients, the AGPL requires you to open-source your modifications. This isn’t a problem for internal use, but it limits commercial embedding [README].
• No file preview UI. Images open in-browser if the browser supports it. PDFs open if the browser supports it. Everything else just downloads. There’s no gallery view, no thumbnail grid, no document preview [README].
• No upload API. Can’t script uploads from CI/CD or automate from other tools without browser automation. You upload manually through the web UI.
• Disk management is manual. No storage quotas, no automatic cleanup of old files beyond the expiry settings you configure per-file. You’re responsible for monitoring disk usage.
• Single instance only. No horizontal scaling, no load balancing. One container, one database writer. Fine for small teams, a hard limit for anything larger [README].
• No audit trail. No download tracking, no access logs in the UI. You’d need to parse nginx/Caddy logs to see who downloaded what.

---

Who Should Use This / Who Shouldn’t

Use PicoShare if:

• You share large files with clients or collaborators regularly and you’re paying WeTransfer Pro or wasting time with Google Drive share links.
• You want a permanent, direct download URL for a file — something you can put in a Notion doc or email and know it’ll still work in six months.
• You’re comfortable deploying Docker on a VPS, or you’ll pay someone once to set it up.
• You’re the only admin, or a small team where sharing one password is acceptable.
• You care about data sovereignty — the file lives on your server, not on someone else’s.

Skip it (stay on WeTransfer) if:

• You need recipients to be able to preview files before downloading.
• You need link analytics (how many times was this downloaded, by whom).
• You need per-recipient access controls or password-protected links.
• You’ve never touched a Linux server and don’t have a technical person to help.

Skip it (use Nextcloud) if:

• You need full file sync across devices, not just sharing.
• You need multiple user accounts with different permission levels.
• You want a folder structure, versioning, and collaborative editing.

Skip it (use Zipline or Chibisafe) if:

• You need an image/file host with a gallery UI, upload API, user accounts, and statistics.
• You want a sharex-compatible upload target with API key authentication.

---

Alternatives Worth Considering

• Zipline — More feature-rich file host with API, user accounts, image gallery, statistics, and ShareX integration. More complex to deploy; more capable than PicoShare.
• Chibisafe — Similar to Zipline, gallery-oriented, multi-user, more SaaS-like UX.
• FileShelter — Similar minimalist philosophy to PicoShare, also single-binary, but with a different UI approach and upload quotas.
• Nextcloud — Full cloud storage suite. Vastly more capable, vastly more complex. Use this if you want file sync, collaborative editing, and team file management — not just sharing links.
• Lufi — End-to-end encrypted file sharing, files encrypted before upload. Use this if encryption is a requirement.
• WeTransfer Pro — $12/mo. No setup, works immediately, recipients always know what they’re getting. Worth it if you don’t want to maintain infrastructure.
• Cloudflare R2 + Workers — If you’re already in the Cloudflare ecosystem, you can build a direct file serving setup that scales and costs almost nothing for moderate usage. More engineering work, but no single point of failure.

For a non-technical founder who wants the simplest possible self-hosted file sharing, the realistic shortlist is PicoShare vs FileShelter. PicoShare has more GitHub traction and the Litestream integration is a differentiator. FileShelter has upload quotas and per-upload password protection built in.

---

Bottom line

PicoShare is the right tool for a specific, common problem: you have a file too large for email, too sensitive for a third-party SaaS, and you want a permanent direct download link without setting up a 40-container Nextcloud instance. It does that job with minimal fuss, minimal resources, and minimal ongoing maintenance. The constraints are real — single admin, no API, no gallery, no scaling — but they’re the cost of simplicity, not bugs. If you’re a solo founder or tiny team that shares maybe 20 files a month with external collaborators, this is cheaper than WeTransfer and under your control. If you need user accounts, upload automation, or a preview gallery, look at Zipline or Nextcloud instead.

---

Sources

The third-party articles provided for this review ([1]–[5]) were unrelated to PicoShare — they covered TikTok account management and SVG editor tools. No independent review coverage of PicoShare was available in the provided sources. All claims in this review are derived directly from primary sources below.

Primary sources:

• [README] GitHub repository and README — https://github.com/mtlynch/picoshare (2,855 stars, AGPL-3.0, 43 releases, 196 forks)
• [GitHub] Repository metadata, commit history, release count — https://github.com/mtlynch/picoshare
• [Demo] Live demo instance — https://demo.pico.rocks