I would like to request a demo
We currently have a self-hosted repository that has switched from repositoryite to RenoP. You can check it out there, but we can't provide a demo of the admin panel yet. We will implement a demo mode for RenoP in the future.
View: https://mvnc.pkg.one
RenoP system compatibility?
RenoP's system compatibility moves with the latest stable version of Golang.
Currently, we are using Golang 1.26.5, and the system compatibility is as follows: MinimumRequirements
Will RenoP provide self-hosted repositories for multiple languages similar to sonatype nexus?
We are already working on developing support.
You can view the plans for each version to see what we are working on. The documentation has not been updated in a timely manner.
What does "If you intend to use it for public hosting, RenoP currently does not support that" mean in the README?
Ah, that might have been a bit ambiguous.
What I originally meant was that if you intend to use RenoP as a public platform with open registration and artifact management—similar to Maven Central—RenoP does not support that functionality.
But don't worry, we are already gradually improving it.
Why Develop RenoP?
RenoP was started because I didn't want to keep running a heavy JVM on my lower-spec server. Even though Reposilite is already extremely lightweight, I still wanted to move away from it—the Java Runtime has honestly left me with too many negative impressions.
RenoP's design was inspired by Reposilite rather than behemoths like Sonatype Nexus or JFrog. You can still see traces of Reposilite on RenoP's homepage, even though we completely overhauled all the APIs and the UI midway through development.
RenoP was initially built in Rust. However, because I wasn't very familiar with Rust at the time, its performance was terrible: under high concurrency, it would either clog the threads or consume excessive memory. RenoP went through a first Rust iteration, a second Rust refactor, and finally a rewrite in Golang—along with multiple UI redesigns along the way. It was a pretty painful process.
RenoP's Resource Usage
I currently cannot test its resource usage in a real-world high-concurrency environment, but I can share the following data:
RenoP (Rust v1): At 1,000 concurrent requests on a single device, it took ~5% CPU and ~40 MB RAM, but all other incoming requests were blocked.
RenoP (Rust v2): At 1,000 concurrent requests on a single device, it took ~2% CPU and 500–1,400 MB RAM, with sluggish memory recovery after testing stopped.
RenoP (Golang): At 1,000 concurrent requests on a single device, it took ~0.1% CPU and ~41 MB RAM, memory dropped back down to 22 MB after testing, with a baseline idle footprint of around 18 MB RAM.
The Golang version stays so low on resource usage because it has a built-in rate limiter that returns a 429 status code to block IPs making frequent malicious requests.
Rust v2 actually has a rate limiter as well, but due to an unknown issue, it doesn't seem to work, leading to high memory consumption.
For detailed instructions on the rate limiter, you can check our documentation where everything is thoroughly described: https://renop.pkg.one/docs/api/rate-limit
I18N Support?
Yes, the RenoP frontend natively supports i18n, and we currently offer 12 languages. If you would like us to add your language, feel free to open an issue. If it receives enough votes (there is no fixed threshold), we will create the translation for you. If you prefer not to wait for the voting results, you can submit a PR directly, which will only require a quick review from our team.
The same applies to the RenoP frontend. However, please note that i18n added via PRs must be continuously maintained by the submitter or other contributors. We are only responsible for maintaining the 12 natively supported languages. If a community-maintained language goes unmaintained for over a year, it will be completely removed.
Additionally, RenoP does not currently support right-to-left (RTL) languages, as our UI is not adapted for them. If you need RTL support, you are welcome to submit a PR, though please be aware that this will be a challenging task.
RenoP exhibits abnormally high memory usage on Windows
Please check if Kaspersky is installed on your device.
We detected a bug in Kaspersky that causes the Go runtime to incorrectly load a 32MB static buffer from FIPS140.
This static buffer will not be garbage collected and may accumulate. The highest abnormal RSS I monitored was 140MB, the typical abnormal RSS was 43MB, and the normal RSS was 14MB.
I have reported this issue to the Kaspersky support team. You can temporarily alleviate this problem by exiting the Kaspersky process and then restarting Kaspersky.
We've also deployed a temporary solution in the latest RenoP that helps the Go runtime force the reclamation of unnecessary memory... once only.
Starting with f442889, we solved this problem by customizing the Golang compiler. You only need to perform an update check once and then install the update.
I would like to request a demo
We currently have a self-hosted repository that has switched from repositoryite to RenoP. You can check it out there, but we can't provide a demo of the admin panel yet. We will implement a demo mode for RenoP in the future.
View: https://mvnc.pkg.one
RenoP system compatibility?
RenoP's system compatibility moves with the latest stable version of Golang.
Currently, we are using Golang 1.26.5, and the system compatibility is as follows: MinimumRequirements
Will RenoP provide self-hosted repositories for multiple languages similar to sonatype nexus?
We are already working on developing support.
You can view the plans for each version to see what we are working on. The documentation has not been updated in a timely manner.
What does "If you intend to use it for public hosting, RenoP currently does not support that" mean in the README?
Ah, that might have been a bit ambiguous.
What I originally meant was that if you intend to use RenoP as a public platform with open registration and artifact management—similar to Maven Central—RenoP does not support that functionality.
But don't worry, we are already gradually improving it.
Why Develop RenoP?
RenoP was started because I didn't want to keep running a heavy JVM on my lower-spec server. Even though Reposilite is already extremely lightweight, I still wanted to move away from it—the Java Runtime has honestly left me with too many negative impressions.
RenoP's design was inspired by Reposilite rather than behemoths like Sonatype Nexus or JFrog. You can still see traces of Reposilite on RenoP's homepage, even though we completely overhauled all the APIs and the UI midway through development.
RenoP was initially built in Rust. However, because I wasn't very familiar with Rust at the time, its performance was terrible: under high concurrency, it would either clog the threads or consume excessive memory. RenoP went through a first Rust iteration, a second Rust refactor, and finally a rewrite in Golang—along with multiple UI redesigns along the way. It was a pretty painful process.
RenoP's Resource Usage
I currently cannot test its resource usage in a real-world high-concurrency environment, but I can share the following data:
RenoP (Rust v1): At 1,000 concurrent requests on a single device, it took ~5% CPU and ~40 MB RAM, but all other incoming requests were blocked.
RenoP (Rust v2): At 1,000 concurrent requests on a single device, it took ~2% CPU and 500–1,400 MB RAM, with sluggish memory recovery after testing stopped.
RenoP (Golang): At 1,000 concurrent requests on a single device, it took ~0.1% CPU and ~41 MB RAM, memory dropped back down to 22 MB after testing, with a baseline idle footprint of around 18 MB RAM.
The Golang version stays so low on resource usage because it has a built-in rate limiter that returns a 429 status code to block IPs making frequent malicious requests.
Rust v2 actually has a rate limiter as well, but due to an unknown issue, it doesn't seem to work, leading to high memory consumption.
For detailed instructions on the rate limiter, you can check our documentation where everything is thoroughly described: https://renop.pkg.one/docs/api/rate-limit
I18N Support?
Yes, the RenoP frontend natively supports i18n, and we currently offer 12 languages. If you would like us to add your language, feel free to open an issue. If it receives enough votes (there is no fixed threshold), we will create the translation for you. If you prefer not to wait for the voting results, you can submit a PR directly, which will only require a quick review from our team.
The same applies to the RenoP frontend. However, please note that i18n added via PRs must be continuously maintained by the submitter or other contributors. We are only responsible for maintaining the 12 natively supported languages. If a community-maintained language goes unmaintained for over a year, it will be completely removed.
Additionally, RenoP does not currently support right-to-left (RTL) languages, as our UI is not adapted for them. If you need RTL support, you are welcome to submit a PR, though please be aware that this will be a challenging task.
RenoP exhibits abnormally high memory usage on Windows
Please check if Kaspersky is installed on your device.
We detected a bug in Kaspersky that causes the Go runtime to incorrectly load a 32MB static buffer from FIPS140.
This static buffer will not be garbage collected and may accumulate. The highest abnormal RSS I monitored was 140MB, the typical abnormal RSS was 43MB, and the normal RSS was 14MB.
I have reported this issue to the Kaspersky support team. You can temporarily alleviate this problem by exiting the Kaspersky process and then restarting Kaspersky.
We've also deployed a temporary solution in the latest RenoP that helps the Go runtime force the reclamation of unnecessary memory... once only.
Starting with f442889, we solved this problem by customizing the Golang compiler. You only need to perform an update check once and then install the update.