On your own server!
Integrated with your private repositories and your continuous integration system!

Who is using it?

“Automated version notifications of open source and self developed closed source components by VersionEye Enterprise are very helpful especially to our distributed iOS teams. They help reducing coordination and communication efforts. The VersionEye team always did a great job supporting us with individual features!”

Alexander Greim
Director Mobile Engineering @ XING AG

“VersionEye Enterprise takes the use of open source in our enterprise software development to the next level, helps optimizing our processes and makes our software development even more productive than before.”

Matthias Feßenbecker

“We are using the VersionEye API to keep our internally hosted NodeJS projects up-to-date. We integrated the VersionEye API into our Continuous Integration Lifecycle via the NPM module versioneye-update and it saves us the hassle for checking updates manually.”

Jens Doose
CEO @ Onwerk GmbH

Which binary repositories are supported?

The whole point of running VersionEye as on-premise installation is that it can crawl internal binary repositories, such as Nexus Pro, Artifactory Enterprise and other ones. That way VersionEye gets a complete list of ALL your dependencies! The open source dependencies AND your private components as well! Currently these binary repositories are supported:

Which git repositories are supported?

VersionEye can be connected with different git servers. That way it's possible to use the Git servers API as single sign on (OAuth) for VersionEye. Currently this git servers are supported:

GitLab support is coming soon!

Simply turn on the switch for project files in git repositories which should be monitored by VersionEye!

Turn on the switch and receive daily email notifications about your dependencies.
It was never easier to stay up-to-date!

How is the integration with CI systems?

For all major build tools there is a native VersionEye plugin. The native plugins are resolving the dependencies localy and only send the results to the VersionEye API to create or update a VersionEye project. Specially for JVM projects where the dependencies are distributed over multiple files it is always recommended to use the native VersionEye plugin for the corresponding build tool.

Pretty much all plugins have goals which check the response for security vulnerabilities & license violations and exit with an non 0 exit code if something is wrong. The VersionEye Maven Plugin for example has a goal "securityAndLicenseCheck" which checks all dependencies for security vulnerabilities and license violations. If that goal is called on an continuous integration server it breaks the build if a dependency has an issue. For Maven reactor builds this goal can be executed on the parent pom. That works with all kind of CI systems like Jenkins, Bamboo, TravisCI, CodeShip, CircleCI and many more.

mvn versioneye:securityAndLicenseCheck

How do I install VersionEye?

VersionEye is completely open source! The source code repsoitories are on GitHub and every time we do a deployment to VersionEye.com, new Docker images are build and published to Docker Hub. In this repository you find a description how to spin up your own VersionEye instance.

After the instance has booted successfully you can open a browser and navigate to the IP address of the instance. On the default HTTP port 80 the VersionEye web application will come up, where you can activate the instance with an valid API key.

After activation you can login with admin/admin and connect your VersionEye instance with your private SMTP / MS Exchange, LDAP / Active Directory, binary repository and git servers. And if you run your VersionEye instance in your DMZ behind your Enterprise firewall, you can configure a Proxy server which will be used for connections to the internet.

How are software updates rolled out?

VersionEye is shipped as a set of Docker images. All Docker images are publicly available at Docker Hub. Software Updates are provided as new Docker images. There is an update script in the versioneye/ops_contrib repository. With that the newest VersionEye Docker images can be downloded any time, via a secure SSL connection! Updating software has never been easier!

Which resources are needed for a VersionEye instance?

The minimum requirements are:

  • 1 CPU 2.0 GHz
  • 4 GB RAM
  • 20 GB HD

Depending on your setup and the amount of the components in your private repositories more resources are required. We recommend to run it with:

  • 2 CPU 2.5 GHz
  • 8 GB RAM
  • 100 GB HD

How to keep the database up-to-date?

VersionEye.com is monitoring 1.5 Million open source projects on a daily basis. The crawlers are running 24/7 to keep our database in the cloud up-to-date. With your own VersionEye instance you can crawl your private repositories in-house, but then your are still missing all the open source libraries from the Internet. For sure you don't want to run & maintain a huge crawling cluster in your company ;-) That's why there is a sync mechanism between each VersionEye instance and VersionEye.com. The self hosted VersionEye instance pulls data from the VersionEye.com API to keep the local database up-to-date.

When uploading a pom.xml (or any other project file) to your VersionEye instance, all open source dependencies are displayed as unknown. But in the background your instance will resolve all dependencies via the VersionEye API and pull in the desired data into the local database. Depending on the number of the dependencies this can take a couple of minutes. Besides that there is a nightly sync, to keep the metadata for the local dependencies up-to-date.


The pricing depends on the number of open source components you want to sync every day to your private instance and the desired SLA. If you are interested please fill out the form below and we will reach out to you.