# Drop is a self hosted store for DRM-free games

> Drop is an open-source game distribution platform that packs DRM-free games into a store, built as a Nuxt front end with a Rust component called torrential and a pnpm workspace holding the server, the CLI and a desktop app. It is in maintenance mode, so it is worth understanding what that means before you deploy it.

**Drop-OSS/drop** — Drop is an open-source game distribution platform.

- Repository: https://github.com/Drop-OSS/drop
- Website: https://droposs.org
- Stars: 760 · Forks: 48
- Language: Vue
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/drop-oss-drop

## A store for games without DRM

Drop is an open-source game distribution platform, similar to GameVault or Steam, and the README says it is designed to distribute and share DRM-free games quickly while remaining adaptable, good looking and quick.

That positioning matters, because it puts Drop in a specific niche. It is not a launcher for games you already own, it is a place where a collection of DRM-free titles can be served to other people, with the catalogue, the metadata and the download flow handled by the platform itself.

The interesting engineering decision is the one in the repository layout. There is a torrential directory, and the Dockerfile builds it as a separate Rust stage with a nightly toolchain. The comment above that stage explains why the image is pinned to bookworm, so the glibc in the build stage matches the runtime stage and the libarchive runtime package is named libarchive13, since trixie renames it. The Rust stage installs libarchive-dev and pkg-config so libarchive3-sys links libarchive dynamically, and protobuf-compiler is kept for parity because torrential's build.rs uses a vendored protoc.

So the download path is a native Rust component built on libarchive, sitting behind a Node application.

The project is written in Vue and TypeScript on the front end, the homepage is droposs.org, and the README badge shows an AGPL-3.0 licence with a LICENSE file at the root, though the repository licence field itself is not filled in.

## Maintenance mode is the headline, and it shapes the decision

The note at the top of the README says Drop is in maintenance mode. Maintainers will not contribute new large features, but bugs will continue to be fixed and external contributions will continue to be merged.

Read carefully, that sentence separates two different things. Bug fixes continue, which means the platform does not rot. New large features stop, which means the feature set is where it is.

The recent release tags are consistent with that. The newest ones are v0.4.0-flatpak-test-3 and v0.4.0-test-flatpak-2, both from 2026-10-20, and v0.4.0-rc-6 from two days earlier. Test and release candidate tags for a 0.4 line, with flatpak packaging in the name, tell you two things about where the work is: the project is still pre 1.0, and the current effort is in packaging formats rather than in features.

For an adopter, that is a workable but bounded proposition. The last push was on 2026-10-22, so the code is being touched, but you are adopting a platform whose scope will not grow much, and you should be comfortable with that before you point a community at it.

The version also sits below 1.0, which in this ecosystem means the interface can still move. A front end that talks to a server API is exposed to that churn in a way that a self-contained application is not.

## Three principles that decide the design

The README has a philosophy section with three numbered principles, and they are the clearest statement of the trade-offs in the project.

The first is that Drop stays adaptable. The argument is that while abstractions and interfaces can complicate the codebase, the adaptability is worth it.

The second is that Drop is secure. The reasoning is about the nature of the platform, that an instance can never be accessible without authentication, and that in line with the first principle Drop also supports a wide variety of authentication mechanisms, from username and password to SSO. That combination is unusual. Plenty of self-hosted projects treat optional authentication as a setting, and plenty of others make authentication mandatory and inflexible. The claim here is that an instance is never open, and that the mechanism of proving who you are can vary widely.

The third is that Drop is user-friendly, with a clean and simple interface and advanced features available to users who want them.

Those three pull against each other in ways the project does not spell out. Adaptability costs code complexity, which is what the first principle concedes. A wide authentication surface is a wide attack surface, which the second principle does not address. And an interface that is simple for most people and rich for experts is two interfaces, which is the third principle's cost.

Still, having the principles written down at all is a good sign for a project that will be read by anyone deciding whether to run it.

## A pnpm workspace holding five surfaces

The repository root shows what the project actually is. There is a backend directory, a cli directory, a desktop directory, a libraries directory, a packages directory, a server directory and a sites directory, plus the torrential Rust component. There is a Dockerfile, a pnpm-workspace.yaml, a pnpm-lock.yaml, a package.json, a SECURITY.md and a .dockerignore.

So this is a monorepo, and the pnpm workspace is the package manager. The root package.json is deliberately thin:

```json
{
  "name": "drop",
  "private": true,
  "packageManager": "pnpm@10.33.0+sha512.10568bb4a6afb58c9eb3630da90cc9516417abebd3fabbe6739f0ae795728da1491e9db5a544c76ad8eb7570f5c4bb3d6c637b2cb41bfdcdb47fa823c8649319"
}
```

The package name is drop, the package is private, and the packageManager field pins pnpm to an exact version with its integrity hash, which means every contributor and every CI run uses the same pnpm.

The server.code-workspace file at the root suggests the server side is developed as a Visual Studio Code workspace. The sites directory suggests the front ends are separate sites within the workspace rather than a single application, and the packages and libraries directories hold shared code between them.

## The container build pins the network out before it installs

The Dockerfile is a multi stage build with a detail that is worth copying regardless of what you think of Drop.

The base stage is node:lts-bookworm-slim, with corepack enabled to provide pnpm, and then the interesting part: the source is copied in, corepack packs the pnpm version into the repository, and then the network is switched off for the rest of the build.

```dockerfile
### INSTALL DEPS ONCE
FROM base AS deps
RUN pnpm install --frozen-lockfile --ignore-scripts
```

The comments explain each step. The copy makes corepack aware of pnpm's version, COREPACK_ENABLE_DOWNLOAD_PROMPT=0 prevents the prompt to download, corepack pack sets the project up for offline use, and COREPACK_ENABLE_NETWORK=0 stops any further call out to the network. The dependency install then uses a frozen lockfile and skips scripts.

The consequence is that the dependency layer is built without network access and without running install scripts, so a compromised postinstall hook cannot reach out during the build. That is a real supply chain property, and it is applied consistently across the stages.

The build stages that follow add git so Drop can determine its git ref at build time, copy the node_modules from the deps stage, and run the postinstall and build scripts for the drop package with telemetry disabled. The version and the git ref are passed in as build arguments named BUILD_DROP_VERSION and BUILD_GIT_REF.

## Deploying it is a documentation exercise

The README is short on deployment detail, and it says so by pointing you elsewhere. The deployment section says to see the documentation on how to deploy Drop, with the quickstart linked at droposs.org/docs/admin/quickstart, and the badges link to the docs site, the forum at forum.droposs.org, a Discord server, and an Open Collective page for the project.

The contributing guidance is similarly external, with an in-depth contributing guide on developer.droposs.org that covers setting up the project, contributing code, reporting issues and translating Drop. The translation piece has its own infrastructure, with a Weblate project at translate.droposs.org and a progress widget in the README.

The docs site itself is built with Docusaurus, judging from the badge, and the project is localised, which is a reasonable expectation for a platform with a community around it.

For a self-hosted deployment, the Docker image is the entry point, and you supply the configuration through the environment. The documentation is where the details live, and the README is deliberately not the place for them.

## Conclusion

Drop suits a small group that wants to share DRM-free game libraries on its own infrastructure, since it is a complete store rather than a single download tool, with authentication, a web interface and a desktop client. It is the wrong choice if you need new features, because the project is in maintenance mode and no large features are planned, and the licence field in the repository is not filled in even though the badge shows AGPL-3.0. Before deploying, read the deployment documentation, confirm that you are comfortable with an AGPL licensed project serving a community, and expect to run the stack yourself with Docker rather than expecting a hosted service.

## FAQ

### What is Drop and what does it do?

Drop is an open-source game distribution platform, described in the README as similar to GameVault or Steam, designed to distribute and share DRM-free games quickly. It is a complete store with a web interface, a CLI, a desktop app and a Rust download component called torrential.

### Is Drop still actively developed?

The README states that Drop is in maintenance mode: maintainers will not contribute new large features, but bugs will continue to be fixed and external contributions will continue to be merged. Recent release tags are 0.4.0 release candidates and flatpak test builds, and the last push was on 2026-10-22.

### How do I deploy Drop?

The README points to the deployment documentation at droposs.org/docs/admin/quickstart. The repository includes a Dockerfile built in stages, with a Node base image, a Rust nightly stage for the torrential component, and a pnpm workspace pinning the package manager version with corepack.

## Sources

- [Drop-OSS/drop on GitHub](https://github.com/Drop-OSS/drop)
- [Issues](https://github.com/Drop-OSS/drop/issues)
- [Project website](https://droposs.org)
- [README](https://github.com/Drop-OSS/drop/blob/develop/README.md)
- [Releases](https://github.com/Drop-OSS/drop/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/drop-oss-drop