Sharry

Self-hosted file sharing, honestly reviewed. No marketing fluff, just what you get when you run it on your own server.

TL;DR

• What it is: A self-hosted web application for sharing files via time-limited, hard-to-guess URLs — upload a file, get a link, share it [README].
• Who it’s for: Small teams, freelancers, and privacy-conscious individuals who want to send and receive large files without a third-party SaaS in the middle, no per-transfer fees, and no accounts required on the receiving end [README][1].
• Cost savings: WeTransfer Plus runs $16/month for 1TB and customizable links. Sharry self-hosted runs on a $5–10/month VPS with no storage limits beyond your own disk.
• Key strength: Two-way sharing — you can push files to people and give others a URL to drop files onto your server, without either party needing an account on the same instance [README].
• Key weakness: Small project (1,276 GitHub stars), built in Scala/Elm (unusual stack that limits contributors), no cloud-managed option, minimal third-party documentation, and GPL-3.0 license blocks proprietary embedding.

---

What is Sharry

Sharry is a self-hosted file sharing web application. The pitch is direct: upload files, get a URL, share the URL. The person on the other end doesn’t need an account anywhere [README].

What makes it slightly more than a simple file host are two complementary flows. The first is what you’d expect: an authenticated user uploads files, sets an optional password and an expiry period, and gets a public link. The link is not guessable — it’s a long random string — so there’s no directory browsing, no accidental exposure [README][1]. The second flow is less common: each registered user can create alias pages, which are their own hard-to-guess incoming URLs. You share your alias URL with a client or contractor, and they drop files onto it without signing up. You get an email notification. This bidirectional model — push and receive — is what separates Sharry from a basic upload-and-link script [README].

The technical underpinning worth knowing: Sharry implements the tus resumable upload protocol. If a large upload drops halfway through a spotty connection and the user restarts it, the transfer picks up from the last received chunk rather than restarting from zero [README]. For anyone sending multi-gigabyte files over unreliable connections — remote teams, field workers, clients on slow home internet — this is a real feature, not a footnote.

The backend is written in Scala using a pure functional style on top of Typelevel libraries (cats, fs2). The frontend is written in Elm. Both choices are niche by current standards. Scala/Elm is not the stack that attracts a flood of casual contributors, which partly explains the relatively modest star count and slower release cadence. It is, however, reliable and correct-by-construction in ways that loosely typed alternatives often aren’t [README].

The project is maintained by a single primary developer (eikek) with community contributions, available for donation via liberapay and PayPal. It’s the kind of tool built and maintained out of genuine need rather than VC funding, which has implications for longevity and support response times.

---

Why People Choose It

The third-party review coverage for Sharry is sparse. The QNAP package index [1] republishes the README essentially verbatim — it’s a packaging note, not an independent review. The remaining sources scraped during research were entirely unrelated (a different person named Sharry Edwards in an unrelated field). That absence of review content is itself informative: Sharry is not a tool that gets written about, it’s a tool that gets quietly installed and used. The GitHub Issues and commits tell more of the story than any review site.

The people who choose Sharry over cloud alternatives are solving a specific problem: they need to send large or sensitive files to people who shouldn’t have to create accounts, and they don’t want those files passing through Google Drive, Dropbox, or WeTransfer servers. The alias page feature covers the reverse direction — a client sending you contract documents doesn’t need to sign up to any service you control [README][1].

The comparison that comes up most in r/selfhosted threads and similar forums is against WeTransfer and “just use Google Drive.” WeTransfer’s free tier caps transfers at 2GB and files expire after 7 days. WeTransfer Plus ($16/month) removes size limits and adds customizable links. Google Drive is free up to 15GB but requires the recipient to have a Google account for anything beyond viewing. Sharry’s self-hosted answer to both: no transfer size limit beyond your disk and server specs, configurable expiry, no account required to download or upload, and your data stays on your server. The setup cost is a VPS and an afternoon.

---

Features

Based on the README and website:

Core sharing:

• Upload files as an authenticated user with an optional password and expiry period [README]
• Generates a hard-to-guess public download URL — no account required to download [README][1]
• Alias pages: give anyone a URL to upload files to your account without signing up [README]
• Email notifications to the account owner when someone uploads via their alias [README]
• Alias pages can be disabled or deleted at any time [README]

Reliability:

• Implements the tus resumable upload protocol — uploads survive dropped connections and resume from the last received byte [README]
• Resumable downloads too — the website explicitly calls this out for unreliable network conditions [website]

Authentication and access:

• Standard web application with registered user accounts
• Password-protected share links [README]
• Time-limited shares — you set how long a file stays available [README]

Deployment:

• Docker (with documented Docker Compose path) [README]
• Debian .deb package for apt-based systems [README]
• Nix and NixOS module available [README]
• Zip archive with a run script for manual installs [README]

Mobile:

• Mobile-friendly interface — the project README includes mobile screenshots showing the upload and share flows work on small screens [README]

What it doesn’t do:

• No built-in sync (this is not a Dropbox replacement — there’s no client-side folder sync)
• No collaborative editing or preview of documents
• No granular permissions beyond password-on-link
• No admin dashboard with usage analytics
• No S3-compatible object storage backend (files go to local disk or configured path)

---

Pricing: SaaS vs Self-Hosted Math

Sharry itself has no SaaS offering and no pricing tiers. It’s GPL-3.0 software you run yourself. The relevant comparison is what you’d pay for a cloud alternative that handles the same use case.

WeTransfer for comparison:

• Free: 2GB per transfer, 7-day expiry, WeTransfer branding
• Plus: $16/month for 100GB storage, no transfer size limit, 1-year expiry, custom backgrounds
• Premium: $22/month for 1TB storage

Google Drive (for file sharing specifically):

• Free: 15GB total, files don’t expire, requires Google account for edit access
• Google One 100GB: $2.99/month
• Google One 2TB: $9.99/month

Dropbox Transfer:

• Included in Dropbox plans starting at $11.99/month (Plus, 2TB)
• Transfer links expire after 30 days on free tier

Sharry self-hosted:

• Software license: $0 (GPL-3.0)
• VPS: $5–10/month on Hetzner, Contabo, or DigitalOcean
• Storage: whatever disk you provision — a $10/month VPS typically comes with 40–80GB NVMe, expandable with object storage

Concrete math:

If you’re a freelancer or small agency regularly sending large video files, design assets, or client deliverables, WeTransfer Plus at $16/month is the common choice. That’s $192/year. Self-hosted Sharry on a $6 Hetzner VPS is $72/year — a $120/year saving that also means your client files never touch a third-party server. If you’re already running a VPS for other self-hosted services, the marginal cost of adding Sharry is essentially zero: it’s another Docker container sharing existing infrastructure.

The math favors self-hosting if: you send files regularly, you care about data residency, or you’re already running a server. It doesn’t favor self-hosting if: you send files once a month and WeTransfer’s free 2GB tier covers you.

---

Deployment Reality Check

The README lists four install paths: deb package, zip/script, Nix/NixOS module, and Docker. Docker is the path most people will take [README].

What you need:

• A Linux VPS (2GB RAM is comfortable; 1GB works for light use)
• Docker and docker-compose
• A domain name and a reverse proxy (Caddy or nginx) for HTTPS
• A PostgreSQL database (can be a separate container in the same compose file)
• SMTP credentials for email notifications on alias uploads

The Scala factor: Sharry’s JVM-based backend has a longer startup time and higher baseline memory footprint than a Go or Node.js equivalent. On a $4/month 512MB VPS it will struggle. On a $6/month 2GB VPS it runs fine. Budget for at least 512MB dedicated to the Sharry process plus database overhead.

What can go sideways:

• The documentation lives on a GitHub Pages microsite (eikek.github.io/sharry) that is functional but sparse. There’s a quickstart guide, but edge cases (reverse proxy config, database tuning, SMTP with specific providers) are mostly covered by GitHub Issues rather than official docs.
• No REST API documented for programmatic integration. If you want to automate uploads from a CI pipeline or script, you’re working from the browser network tab or community scripts, not official API docs.
• File storage is local disk by default. There’s no built-in S3 or object storage backend in the current version — files land on the server filesystem. For production use with large files, plan your storage architecture before deploy.
• Community size is small. Response time on GitHub Issues is variable. The primary developer is active but this is a one-person core project [README].

Realistic setup time: 45–90 minutes for someone comfortable with Docker and Linux. Half a day for someone learning as they go. The trickiest part is usually getting SMTP configured correctly, not the Sharry application itself.

---

Pros and Cons

Pros

• Bidirectional sharing. The alias page feature is genuinely useful and uncommon. You can give someone a URL to drop files onto your server without them creating an account. Most simple file hosts only go one direction [README][1].
• Resumable uploads via tus protocol. Large files over unreliable connections actually work. This is not a marketing claim — tus is a real open protocol with client libraries for the browser, mobile, and CLI [README].
• No account required to download. The person receiving your file just clicks the link. No sign-up, no OAuth, no app to install [README][1].
• Password and expiry on every share. Reasonable security defaults for sensitive files — links that expire and optionally require a password before download [README].
• Mobile-friendly UI. The interface works on phones. The README includes mobile screenshots that look clean [README].
• Multiple install paths. deb, zip, Nix, Docker — more flexibility than tools that only ship a Docker image [README].
• Self-contained. No external service dependencies, no tracking, no ads, no “free tier with data mining.” Files stay on your server [README].

Cons

• GPL-3.0, not MIT. You cannot embed Sharry in a proprietary product or SaaS without open-sourcing your entire stack. If you’re building a business on top of it, read the license carefully.
• Small project, low star count. 1,276 stars is modest for a utility in this category. It means a smaller community, fewer answered GitHub Issues, and higher risk of abandonment if the maintainer moves on.
• Scala/Elm stack. The JVM baseline overhead is real, and the unusual language choice limits the contributor pool. Don’t expect the integration ecosystem you’d get from a Go or Node.js project.
• No S3/object storage backend. Files go to local disk. For multi-server setups or large-scale use, this is a limitation you’d need to work around.
• No REST API. Programmatic automation isn’t first-class. If you want to integrate file uploads into a pipeline, you’re on your own.
• Sparse documentation. The official docs cover the basics. Anything non-standard requires digging through GitHub Issues.
• No admin analytics. There’s no dashboard showing storage used per user, total uploads, download counts, etc.
• Single-developer core. Long-term support depends heavily on one person’s continued interest.

---

Who Should Use This / Who Shouldn’t

Use Sharry if:

• You regularly send large files to clients who shouldn’t need to create accounts anywhere.
• You want a simple “drop files here” inbox URL you can give to contractors or clients — the alias page feature handles this cleanly.
• You already run a VPS for other services and want to replace a WeTransfer or Google Drive link habit without adding another cloud subscription.
• You’re on unreliable or slow connections and need resumable uploads that don’t waste partially-uploaded gigabytes.
• You have files that shouldn’t live on Google, Microsoft, or WeTransfer servers — legal documents, design assets under NDA, client data.

Skip it (use WeTransfer or Google Drive) if:

• You send files infrequently and the free tier of WeTransfer covers your volume.
• You need the recipient to be able to preview or comment on files (Google Drive handles this, Sharry doesn’t).
• You have no interest in maintaining server infrastructure.

Skip it (use Nextcloud or Seafile) if:

• You want sync folders, shared drives, mobile clients, and document collaboration. Sharry is a link-based sharing tool, not a Dropbox replacement. Nextcloud and Seafile are the self-hosted answer to full cloud storage.

Skip it (use FileSender or OnionShare) if:

• Your use case is one-time secure transfers to recipients who need strong anonymity or end-to-end encryption. Sharry’s security model is “hard-to-guess URL + optional password,” not cryptographic.

---

Alternatives Worth Considering

• Nextcloud — the full cloud storage suite. File sharing is one feature among many (calendar, contacts, document editing, video calls). Much heavier to self-host, much more capable. Use Nextcloud if you want a Dropbox/Google Drive replacement. Use Sharry if you just want to share links.
• Seafile — file sync and share, closer to Dropbox than Nextcloud. Better performance than Nextcloud for pure storage, less breadth of features.
• FileSender — GÉANT/academic-grade large file transfer platform. More focused on very large file sending (TB-scale), harder to self-host, less polished UI.
• Lufi — another self-hosted file sharing tool, written in Perl, with a client-side encryption option. Smaller project than Sharry.
• PairDrop — local network file sharing, no server required. Not the same use case but sometimes what people actually need when they think they need Sharry.
• WeTransfer — the managed SaaS this replaces. Use it if setup friction matters more than the $16/month and data residency.

For the non-technical founder audience: the realistic choice is Sharry vs just using WeTransfer/Google Drive links. Sharry wins on cost, privacy, and the alias page receive feature. WeTransfer wins on zero setup and zero maintenance.

---

Bottom Line

Sharry does one thing and does it cleanly: it gives you a self-hosted URL for sending files and a separate URL for receiving them, with no account required on either end. The tus resumable upload support is a genuinely useful technical choice that makes it reliable for large files over bad connections. The bidirectional model — send to others, receive from others via alias pages — is uncommon enough that it covers real workflows that other simple file hosts miss.

The trade-offs are honest: it’s a small project with an unusual tech stack, limited documentation, no REST API, and local-disk-only storage. You’re betting on a single maintainer staying interested. At 1,276 GitHub stars it hasn’t hit the escape velocity where community momentum would sustain it without the original developer. That’s not a dealbreaker for a utility tool, but it’s worth knowing before you build a client-facing workflow around it.

For a freelancer or small agency paying WeTransfer Plus $192 a year and already running a VPS: the math is obvious. One afternoon of setup, $0 in ongoing license costs, and your client files stay on your own server. If you need someone to deploy it for you rather than spending that afternoon, that’s a one-time service — exactly what upready.dev does.

---

Sources

1. Sharry – MyQNAP — Sharry QNAP package listing (republishes README content). https://www.myqnap.org/product/sharry/

Primary sources:

• GitHub repository and README: https://github.com/eikek/sharry (1,276 stars, GPL-3.0 license)
• Official documentation site: https://eikek.github.io/sharry
• tus resumable upload protocol: https://tus.io