Space
The intelligent code collaboration platform
Space and SpaceCode will be discontinued on June 1, 2025. Learn more → →
Understanding Visibility in Space: Project, Git Repository, Channel, and Package Repository
One particular question has been coming up a lot lately – “Who can see the data in my Space projects, Git repositories, channels, and package repositories?” In this blog post, we’d like to explain how resource visibility works and clarify who can access your resources in Space.
Space is an integrated team environment designed to help your team collaborate effectively. That means that the information you have in Space doesn’t leave your Space organization unless you’ve configured its export, mirroring, or distribution outside of Space, but all these settings are always off by default.
Simply put, a user has to be a part of your organization to gain access to your resources in Space. This applies to all Space subscription levels, including the Free plan.
Let’s now take a closer look at how resource visibility works for different Space entities – projects, Git repositories, channels, and package repositories – one by one.
Project visibility in Space
A Space project is a place to create, store, and manage all your work-related resources – Git repositories, documentation, checklists, issues, and packages. Projects in Space come with lots of tools to help you with various work tasks, there is everything from project planning to automation and deployment.
When you create a project in Space, it is visible to all the members of your organization by default. This means that all your project resources, such as source code, reviews, and discussions, can be viewed by anyone within your Space organization. Nevertheless, the project administrator can still limit the rights to commit and create reviews to specific members or teams, and they can also configure other project-level permissions.
All your Space projects are internal, meaning that they are not exposed to the general public on the web. A user has to be a registered member of your Space organization and logged in to access your project.
On the Organization and Enterprise pricing plans, you can make your projects Private. A private project is only visible to the members assigned to it by the project administrator. This means that you can hide the project from other members of your organization and they won’t be able to access it.
The main idea behind private projects, as opposed to regular projects, was to protect them from the permission rules that are set at the organization level. In other words, when you create a private project, you are the only one who controls access to it, while regular projects can be viewed by anyone in your organization.
Git repository visibility in Space
In Space, Git repositories are contained within projects. Members of the organization can access them from the Space web or desktop UI to track the commit history; search, examine and review code; or add and edit files. A single project can contain multiple repositories.
Git repositories follow the permissions defined for the project they are contained within. This means that the members of your organization will need sufficient permissions to work with them.
Because the repository permissions are inherited from the project, the distinction between regular and private projects applies to Git repository visibility in Space, too:
- If a Git repository is part of a regular (not private) Space project, it is visible to all the members of your Space organization. Organization members will still need to have sufficient permissions within the project to commit to the repository.
- If a Git repository is part of a Private Space project, it is only visible to the members assigned to that project by the project administrator – nobody else will be able to see or access it.
Space provides private Git repositories on all subscription levels, including the Free plan.
All your Git repositories contained in Space projects are internal, meaning that they are not exposed to the general public on the web. A user must be a registered member of your Space organization and logged in to access your project resources.
It is possible to maintain a public mirror of the Space Git repository using Git repository mirroring, but this has to be set up explicitly for each repository.
Channel visibility in Space Chats
Chats is your primary location in Space for communicating with your colleagues and staying informed. It serves not only as a messenger, but also as your personal inbox for notifications, requests, and alerts.
Channels are group chats created for a specific group or for discussing specific topics. For example, a dedicated channel can be created for a team to collaborate on a particular issue or project.
Channels can be made Public or Private. While public channels are open to all organization members, joining a private channel requires permission from its owner.
All channels and chats are internal, meaning that they are not exposed to the general public on the web. A user has to be a registered member of your Space organization and logged in to access the public channels in Space.
Package repository visibility in Space
Packages is a package repository manager built into JetBrains Space. Packages lets you create your own repositories and use them for publishing and sharing packages of various types: Docker and OCI images, .jar and .pom files, and others.
Space provides private package repositories on all subscription levels, including the Free plan.
The privacy settings for package repositories are different from the settings for projects, and they can be specified when you create a package repository:
- Private Package Repository – Only authenticated users can access private package repositories. By default, Space project members have Read, Write, and Create permissions, while organization members only have Read permission. You can change this in Project Settings | Access | Package Repositories.
- Public Package Repository – All unauthenticated users have Read permission for public repositories.
Please note that your public package repositories are exposed to outside your Space organization, which means that anonymous users can read them.
Leave your comments below if you have any questions or concerns about resource visibility in Space.
Subscribe to Space Blog updates
