Repository Ownership

OpsLevel can track ownership of all your git repos, not just services. Libraries, internal tools, templates, Terraform, and more.

You can use OpsLevel to manage your repositories. Teams can be assigned to repositories to promote ownership. Certain repositories can be hidden to avoid cluttering your account with old, unused repositories.

Assigning Ownership

Assigning ownership of your repositories can be done in multiple ways. This can be done from the Repositories List Page, a single Repository Details page and with config as code using opslevel.yml docs.

Repositories List Page

To define ownership of your repositories from the Repositories List Page, select which repositories you wish to edit by clicking on the checkbox next to the name.

Repositories Checkboxes

Once you have selected 1 or more repositories, you will see the bulk actions menu become active.

Repositories Bulk Actions

When you click the Bulk Actions menu button, you will see a list of options. Press on the Set Owner action to set an owner on the repositories you selected.

Repositories Bulk Action Options

From the Set Repository Owner modal, select a team from the dropdown and press Set Owner.

Repositories Bulk Action Modal

If you have a lot of teams in your organization, you can use type ahead search to search for a team.

Repositories Bulk Modal Typeahead

If you do not wish to change the owners of any connected services, uncheck the modal checkbox shown below.

Repositories Bulk Modal Service Owner Sync

Repository Details Page

To define ownership from a Repository Details Page, hover over the owner field and click the pencil icon.

Repository Owner Edit

From the dropdown you can select a new owner for your repository.

Repository Owner Edit Dropdown

If you have any services connected to your repository, you can choose to sync the owner between them.

Repository Connected Service Owner Sync


You can also define who owns your repositories using opslevel.yml. Refer to the opslevel.yml docs for more information.

Hiding Repositories

With opslevel.yml and our Git integrations, you can automatically import all your repositories into OpsLevel. But you might not want to show all of your repositories. Some might contain old, deprecated services. Others could have experimental, proof-of-concepts.

You can hide these repositories in OpsLevel so that they won’t show up by default. This will ensure OpsLevel accurately reflects your production infrastructure.

By default, the Repositories List page only shows visible repositories. To view hidden repositories, you can change the View filter.

Repository Visibility Filter

To hide repositories, select the ones you want to hide and press the Hide Repos Bulk Action.

Repository Visibility Bulk Action Hide

To unhide repositories, select the ones you want to unhide and press the Unhide Repos Bulk Action.

Repository Visibility Bulk Action Unhide

To hide a repository while on the Repository Details page, press the gear icon and then press the Hide Repo button.

Repository Visibility Hide

To unhide a repository, press the gear icon and then press the Unhide Repo button. Note that hidden repositories will have a Hidden label next to their name.

Repository Visibility Bulk Unhide

If a repository has a connected service, it cannot be hidden. You must disconnect it from the service if you want to hide it. This applies to repositories that were connected to services through the OpsLevel website or through opslevel.yml.

When a hidden repository becomes connected to a service, it will automatically be unhidden and made visible.


Git providers allow you to archive a repository, making it read-only. OpsLevel will automatically hide a repository that becomes archived. The repository cannot be unhidden while it is archived. An archived repository cannot be attached to a service. When an archived repository becomes unarchived, OpsLevel will unhide it.

If the repository has a connected service controlled through opslevel.yml and it gets archived, OpsLevel will unlock the service, and then hide the repository. Referencing an archived repository in opslevel.yml will result in a opslevel yaml error as well.

If there are multiple repositories mapped to a service controlled through opslevel.yml and one gets archived, OpsLevel will try to promote one of the other repositories to primary if an opslevel.yml is found.


Deleting a repository is an uncommon task, but sometimes a necessary task to keep your organization tidy. When you delete a repository in your git provider, we will mirror that action and delete it from OpsLevel.

If the repository has a connected service controlled through opslevel.yml and it gets deleted, OpsLevel will unlock the service, and then delete the repository. We keep the service around in OpsLevel just in case it is still needed, so it will need to be manually cleaned up if not.

Losing Access

If we lose access to a repository, such as when permissions have been changed, we will invalidate the repository. This will allow users to delete the repository to clean it up.

If the repository has a connected service controlled through opslevel.yml and it gets invalidated, OpsLevel will unlock the service, and then show a warning on the repository.