Sharry self-hosted file sharing with resumable uploads

Sharry's two file-sharing directions

Sharry addresses a specific operational problem: letting an authenticated user publish a file for someone outside the service. The uploader signs in, sends a file through the web interface, and can assign an optional password and an availability period. The service then generates a public URL that can be distributed by email or another channel. The receiving page is described by the README as hard to guess but open to everyone, so secrecy of the URL is part of its access model. A password, when configured, adds another condition, while the time period determines how long the download remains available.

Sharry also supports the reverse flow. A registered user can create an alias page protected by a hard-to-guess URL. Visitors can upload files through that page, optionally attach a description, while the page itself does not offer a password field or an expiration control. The alias owner can receive an email notification. Alias pages can be disabled or deleted, which gives the recipient a way to stop accepting further uploads without necessarily removing files that were already submitted.

The intended users are therefore not only file owners. Sharry also suits administrators, support teams, families, or community organizers that need a controlled upload destination. It is a self-hosted web application rather than a public hosting utility, so deploying it means owning the server, configuration, availability, and file lifecycle. The README does not document file-size limits, quotas, retention beyond the optional download period, malware scanning, or account-management commands, so those requirements need separate evaluation.

Why Sharry uses tus for uploads

The frontend sends files to the Scala backend through the tus resumable upload protocol. According to the README, this design can continue sending large files over HTTP after a connection drops. If the same file is uploaded again later, Sharry resumes from the last chunk it received instead of beginning the complete transfer from byte zero. That is a meaningful distinction from a basic form submission, where an interrupted request can lose the in-progress transfer.

Based on the repository layout, Sharry separates its interface and server concerns. The public frontend is written in Elm, while the backend uses Scala and a pure functional style built on Typelevel libraries including cats and fs2. The repository contains separate `modules/`, `docker/`, and `nix/` directories, along with `build.sbt` and Nix-related files. These entries are consistent with a multi-part project that offers more than one packaging route. They do not, by themselves, establish deployment performance or storage behavior.

The README does not expose the API routes, tus endpoint, storage backend, database configuration, or authentication implementation. It also does not say whether a partially completed upload can be removed or resumed after its link expires. Developers integrating another client should therefore avoid assuming that every tus implementation is compatible without checking the project documentation or server configuration. The stated behavior is reliable transfer resumption through tus, not a claim that every network failure or restart is handled without intervention.

Installing Sharry through its supported packaging routes

The README does not provide a self-contained command sequence, container image name, default port, or environment-variable list. Instead, it directs users to release assets and the documentation site. A first installation should therefore begin by opening the project's releases page and matching the artifact to the host's packaging model.

For Debian-based systems, the stated route is to install the provided `deb` file. The release page is the source for that package; the README does not give the local `dpkg` or `apt` command, so this review does not substitute one. After installation, administrators still need the documented service and configuration details, which are not present in the README.

For hosts that use the ZIP release, the project says to download the archive and run the script in `bin/`. The exact script name, its arguments, and the surrounding service setup are deferred to the quickstart documentation. A runner should expect more than launching an unspecified binary: the archive contains a startup mechanism whose configuration needs to be read before use.

Nix and Docker are also documented paths. The README points to a dedicated Nix page for package-manager installation and says a NixOS module is available. Its Docker instructions live under the quickstart documentation. None of those instructions are reproduced here because their commands and image settings are not established.

A first authenticated upload and download

The first practical use follows the flow described in the README. Start the installed Sharry service according to the quickstart for the selected installation route, open its web interface, and register or sign in as an authenticated user. The README does not identify the default address, setup route, or first-user command, so none can be safely inferred here.

From the authenticated interface, select a file for upload and send it to the Scala backend through the Elm web application. The client uses tus, which means the browser communicates upload progress in chunks rather than relying on one uninterrupted request. After completion, Sharry generates a public URL. Copy that URL and, if the content should stop being available at a known time, set the time period before sending it. Add a password if recipients should face that additional restriction.

The sender should confirm that the generated download page opens as expected and that its configured expiration is appropriate. The README does not document how to cancel an already shared link, extend its expiration, inspect download events, or recover a lost URL. Those operations are real adoption requirements for a file transfer service, but their absence from the README means the quickstart or application interface must be checked before committing to a workflow.

Alias pages for untrusted inbound uploads

Alias pages serve a different purpose from authenticated sharing. They let other people upload files into a particular registered user's area without requiring those visitors to authenticate. This is useful for contact channels or temporary intake pages, but it changes the security and operational assumptions.

The URL is described as hard to guess, not as an access-control system with documented identity verification. Visitors cannot set a password or validation period from the upload form. They can include a description, and the alias owner can be notified by email. Consequently, expiration and recipient authentication are not equivalent to the controls available to an authenticated uploader.

The strongest documented control is administrative: the owner can disable or delete an alias page at any time. The README does not say whether deletion removes previously uploaded files, whether the owner can reject individual uploads, how duplicate submissions are handled, or how email notifications are configured. It also does not claim that alias URLs are cryptographically unguessable. Operators who need stronger intake rules, such as sender authentication or automatic validation periods, would have to add controls outside the documented feature set.

Sharry's limits, license, and maintenance record

Sharry's clearest technical boundary is that its frontend and backend are separate parts of a self-hosted system. The README documents the Elm, Scala, cats, and fs2 choices, but it does not provide deployment instructions for storage, backup, database maintenance, encryption, logging, or monitoring. A successful installation is only the start of operating the service. Files and links also have different lifecycles: an authenticated upload can receive an availability period, while an alias submission has no expiration field in its form.

Another limitation is documentation depth in the repository itself. The README links to a separate documentation site for quickstart, Docker, and Nix instructions. Without those pages included here, exact commands, ports, environment variables, service names, and upgrade procedures remain unconfirmed. The README also does not discuss rollback, backup restoration, or migration between releases. Those omissions do not prove the features are absent, but they prevent a repository-only adoption decision from treating them as available.

Sharry is distributed under GPLv3+, identified in the repository as `GPL-3.0-or-later`. Anyone distributing the application or a modified version should review the actual `LICENSE.txt` and applicable source-distribution obligations. This is a license-identification point, not legal advice.

The repository is not archived, and its last push was on 2026-10-05. Release `v1.17.0` was also published on 2026-10-05, following `v1.16.0` from 2026-06-04. This indicates recent project activity, but the README does not document the upgrade procedure or the cost of moving an existing deployment between versions, so an upgrade test is required before replacing a working installation.

Editorial conclusion

Sharry fits operators who want to operate their own file sharing service and value resumable uploads, expiration controls, and inbound alias pages. It is less suitable for users who require a documented installation command, explicit encryption claims, or a complete recovery and upgrade runbook in the README. Before adoption, inspect the quickstart documentation for the selected Debian, ZIP, Nix, NixOS, or Docker path, then confirm how stored files, public URLs, notifications, and upgrades are managed on the intended host.

Frequently asked questions

Official sources

1. eikek/sharry on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases