# Reposilite: a Maven repository manager sized for 20MB of RAM

> dzikoysk/reposilite is a self-hosted repository manager for Maven-based artifacts in the JVM ecosystem, written in Kotlin and distributed as a JAR, a Docker image or a Helm chart. Its pitch is the memory footprint, and its scope is deliberately narrower than Nexus or Artifactory.

**dzikoysk/reposilite** — Lightweight and easy-to-use repository management software dedicated for the Maven-based artifacts in the JVM ecosystem 📦

- Repository: https://github.com/dzikoysk/reposilite
- Website: https://reposilite.com
- Stars: 1,896 · Forks: 238
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/dzikoysk-reposilite

## The memory number is the product claim

The positioning is explicit: a lightweight, easy-to-use repository manager for Maven-based artifacts in the JVM ecosystem, positioned as a self-hosted replacement for managers like Nexus, Archiva and Artifactory with reduced resource consumption.

The number behind that claim is given up front. For personal needs the README says to assign around 20MB of RAM and have at least Java 11 installed. The standalone launch command makes the heap explicit, which is the practical form of that number:

```bash
java -Xmx32M -jar reposilite-3.6.3.jar
```

Thirty-two megabytes of heap is the whole budget. For huge public repositories, the README says you can raise the memory limit and adjust the size of the thread pools in the configuration.

That framing explains both the appeal and the boundary. A repository manager is infrastructure that nobody notices until it is down, and the standard complaint about the incumbents is that they cost real memory to do very little. Reposilite's answer is to be a JVM process with one job, and the reason it can be that small is that it does not attempt the range of repository types the enterprise products support. The description says Maven-based artifacts in the JVM ecosystem, which is a scope statement rather than a boast.

The implementation is Kotlin on Gradle, with Javalin as the web layer among the repository topics. The repository is split into modules that mirror the product: `reposilite-backend/`, `reposilite-frontend/`, `reposilite-plugins/`, `reposilite-site/` and `reposilite-test/`. The plugins module is the interesting one for anyone who needs behaviour the core does not have, since it is where extensions live rather than being hardcoded into the server.

## Three deployment paths, and a health check that reads its own address file

There are three supported ways to run it, and the README shows a command for each.

The standalone JAR is the one above, needing only a Java runtime. The official Docker image is pulled by tag:

```bash
docker pull dzikoysk/reposilite:3.6.3
```

The official Helm chart comes from a project-run chart repository:

```bash
helm repo add reposilite https://helm.reposilite.com/
helm repo update
helm install reposilite/reposilite
```

The JAR and Docker examples pin a version rather than tracking latest, and the Docker tag uses the same number as the release. That consistency matters more than it sounds for a repository manager, since a build that resolves against one version cannot resolve against another.

The Docker image is built in two stages on Eclipse Temurin, compiling with a JDK and shipping a JRE. The data directory is a declared volume at `/app/data`, and it is where the runtime state lives.

The health check is the detail that shows how the container is meant to be operated. It does not assume a fixed port or a fixed host. Instead it reads the instance's own address out of a file inside the data directory and curls whatever it finds:

```bash
URL=$(cat /app/data/.local/reposilite.address); curl -sf $URL > /dev/null
```

The check runs every 30 seconds with a 30 second timeout, a 15 second start period and three retries, exiting 2 on failure. The instance writes its bound address into that file, so an orchestrator that changes the port does not break the health check.

## docker compose reads a .env that is checked into the repository

The compose file is small and worth reading closely, because of how it takes its configuration.

```yaml
services:
  reposilite:
    image: dzikoysk/reposilite:3.6.3
    ports:
      - ${PORT}:${PORT}
    env_file:
      - .env
    environment:
      - JAVA_OPTS=-Xmx${MEMORY} ${JAVA_COMPOSE_OPTS}
      - REPOSILITE_OPTS=--port ${PORT} ${REPOSILITE_COMPOSE_OPTS}
    volumes:
      - reposilite-data:/app/data
    restart: unless-stopped
```

Three things follow. First, the port is passed on both sides of the mapping and also on the command line, as `--port` inside `REPOSILITE_OPTS`. The application is told which port to bind rather than being discovered through the mapping, so the same value has to appear in both places and compose substitutes it in both.

Second, `JAVA_OPTS` is built as `-Xmx${MEMORY}` with an optional extra fragment, so the memory claim is expressed as an environment variable rather than baked in. A deployment that mirrors the README's 20MB guidance sets `MEMORY` accordingly.

Third, and this is the operational trap, `env_file` points at `.env`, and there is a `.env` file in the repository root alongside `.gitignore` and the Dockerfile. The compose file will read whatever is at that path. Before running this on any machine, decide whether the shipped file is what you want, and replace it with your own rather than editing variables one at a time in a file the project also ships.

The data lives in a named volume, `reposilite-data`, so artifacts and configuration survive a container rebuild. That is the one piece of state you cannot afford to lose, since it is the repository itself.

## Version numbering without a v prefix, and a documented demo to try first

The releases are tagged without a leading `v`: 3.6.0 on 2026-08-11, 3.6.2 on 2026-08-15 and 3.6.3 on 2026-08-30. The Docker tags and the JAR filenames use the same numbers, which is convenient and worth knowing if you script around either.

The README also draws a line between major versions in its publications section, separating Reposilite 3.x material from 2.x, with separate documentation URLs for the older line. The 3.x thread on Reddit and a Medium piece about setting up your own Maven repository manager in five minutes are both linked, which tells you 3.x was a substantial change rather than a routine increment.

The repository is not archived, the last push was on 2026-10-11, and it is Apache-2.0 licensed. For a server component that sits between your builds and your artifacts, a permissive licence is a meaningful part of the evaluation rather than a footnote.

The fastest way to evaluate any of this is the public demo, which the README links at maven.reposilite.com alongside the official guide at reposilite.com. A hosted instance you can push a real artifact to answers the questions that a README cannot: how the web interface behaves when the repository is empty, and whether the deploy flow your build tool uses works as documented.

Support runs through a Discord channel linked from the README, and there is a dedicated support page on the project website. For a component that other people's builds depend on, knowing where the maintainer is reachable matters as much as the feature list.

## Where the narrow scope actually costs you

The case for Reposilite is strongest in a specific situation: a small team, or one developer, that needs somewhere to publish internal Maven artifacts and finds the enterprise managers too heavy to justify. A 20MB footprint on a small VPS, one JAR, no external database to administer, and a chart if you already run Kubernetes. In that context the comparison to Nexus is not close.

The case against is equally specific. Migrating to a Maven-only manager is a decision to fragment again, and the fragmentation is administrative work that does not appear in any benchmark.

Feature depth is the second limit. A repository manager that only hosts Maven artifacts cannot serve your npm, Docker or PyPI traffic, and a company standardising on one host for all of them has no path to that here. Whether the plugins module closes some of that gap is a question for the project rather than something this description answers.

A third limit is operational. A single JAR with no database is easy to start and easy to lose. The compose file gives you one named volume and a `restart: unless-stopped` policy, which is a reasonable floor and not a backup strategy. Whatever else you do, the data volume is the thing to protect.

The honest summary: this is a good fit for the self-hosted Maven repository that nobody wants to pay for and nobody wants to babysit, and a poor fit for the unified binary store that a platform team is measured on.

## Conclusion

Run Reposilite if you need a self-hosted Maven repository for your own builds or a small team and want it to fit on a modest host, since the documented footprint is about 20MB of RAM and one JAR. Confirm that Maven-based artifacts in the JVM ecosystem meet your repository requirements, since that is the project's documented scope. Verify first that the release you pin is available both as the JAR and as the Docker tag you intend to use, that your build tools point at a repository URL the instance actually serves, and whether the shipped `.env` in the repository is replaced with your own before you run docker compose, since it is read directly by the compose file.

## FAQ

### How do I run Reposilite?

The README shows three ways: launching the standalone JAR with `java -Xmx32M -jar reposilite-3.6.3.jar`, pulling the official image with `docker pull dzikoysk/reposilite:3.6.3`, or installing the official Helm chart from `https://helm.reposilite.com/`. Java 11 or later is required.

### How much memory does Reposilite need?

The README suggests around 20MB of RAM for personal needs, and the standalone launch command sets `-Xmx32M`. For huge public repositories it says you can raise the memory limit and the thread pool sizes in the configuration.

### Is there a public Reposilite instance I can try?

Yes. The README links a demo at maven.reposilite.com, along with the official guide at reposilite.com.

### What licence is Reposilite released under?

Apache-2.0, with the `LICENSE` file at the repository root.

### Which artifacts can Reposilite host?

Maven-based artifacts in the JVM ecosystem, which is how the project describes its scope and how it positions itself against Nexus, Archiva and Artifactory. The Maven, Gradle and sbt topics on the repository reflect that focus.

### How does the docker-compose setup configure ports and memory?

The compose file maps `${PORT}:${PORT}` and also passes `--port ${PORT}` through `REPOSILITE_OPTS`, and builds `JAVA_OPTS` as `-Xmx${MEMORY}` plus an optional extra fragment. It reads variables from `.env` via `env_file`, and persists state in the named volume `reposilite-data` mounted at `/app/data`.

## Sources

- [dzikoysk/reposilite on GitHub](https://github.com/dzikoysk/reposilite)
- [License: Apache-2.0](https://github.com/dzikoysk/reposilite/blob/main/LICENSE)
- [Project website](https://reposilite.com)
- [README](https://github.com/dzikoysk/reposilite/blob/main/README.md)
- [Releases](https://github.com/dzikoysk/reposilite/releases)

---

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