Space logo


The intelligent code collaboration platform

Space is pivoting to SpaceCode, focused on Git hosting and code reviews. Learn more →


Introducing Space Packages

Space packages

We’re delighted to introduce Space Packages! In this post we’d like to share with you the existing features, as well as the planned features we have in store for this Space module.

First of all, what is Packages? Packages is a package repository manager. If you’ve ever heard of Maven Central, Docker Hub, or, then you’ll easily get the idea. In a nutshell, like these products, it lets you create your own repositories and use them to publish and share packages of various types, such as Docker/OCI images, .jar and .pom files, and others, all inside your Space instance!

While this is still a work in progress, you can already try out some of the repositories.

Repository types supported

Package repositories in Space are organization-wide entities, making it possible to share repositories between team members.

Space Packages supports (or will support) the following repository formats:

  • Container registries – Storage for Docker/OCI images and Helm charts.
  • Maven repositories – Maven compatible artifact storage to use in Gradle, Maven, and SBT builds.
  • [not-yet-available] NPM registries – Storage for NPM packages to use in npm/yarn.
  • [not-yet-available] NuGet feeds – Storage for NuGet packages for .NET developers.

Packages — Space -

Search and traceability

As a repository normally contains hundreds or even thousands of packages, it can be difficult to find exactly where a specific package resides. To address this issue, we’ve implemented powerful search capabilities to help you find packages. You can search for packages by name across multiple repositories.


Finding out who has published the specific package version and where they have it can also be a problem. Thanks to the synergized integration of Space modules to share information, it’s possible to get all the details of this information.

JetBrains Space. Package properties

Repository working modes

There are three modes for working with repositories:

  • Local – This is the default mode. The local repository is the main storage of your packages. You can push and pull packages, reference this repo in your IDE, and use it as you would normally use a package repository.
  • [not-yet-available] Mirror – In this mode, the repository becomes a mirror of another remote repository (for example, Maven Central,,, and so on).
    • If the mirror is set to Pull only, the repository works as a pull-only cache: When a package is not available locally, Space takes it from the upstream repo and then saves it locally.
    • If Push and pull are set, the mirror has two-way syncing with the upstream server. When you push a package to such a repo, the package is pushed to the upstream repo as well.
  • [not-yet-available] Group – In this mode, the repository serves as a single entry point to the group of local and mirror repositories. Instead of specifying a number of repositories, you can specify a single URL. Not only is this convenient, but in some cases, it also improves performance. For example, Gradle has a significant drop in performance if it has to go through a large number of repositories.


Want to learn more?

The Packages module already has a lot to offer. In the Space documentation, there are tutorials on how to:

There is also lots of other information there, which you might find useful for customizing and getting more out of Space, we recommend you go take a look.

What else is planned for Packages?

  1. Permissions management – Configure access permissions per repository/package name prefix to ensure fine-grained control for package owners.
  2. Retention policies – Automatic cleanup of repository content, leveraging retention policies with rules like “keep packages downloaded once in the last year”.
  3. IDE integration – Search by package name as well as by FQN class/method references inside the IDE.
  4. Project package repositories – Create package repositories for specific projects.
  5. Build tool caсhes – Create repositories for tools like Gradle/Bazel with required retention policies to store remote build caches.
  6. License analysis – Check reports of the used package licenses for specific projects.
  7. Vulnerabilities analysis – View the health of package dependencies for projects.

We’d really appreciate it if you would share your feedback with us about both the currently implemented functionality and our future plans:

If you haven’t tried Space yet, request your invite for a free Space EAP today!

Your Space Team

image description