Skip to content

[GA] Guest Collaborators for enterprise managed users

Guest Collaborators for GitHub Enterprise Cloud EMUs are now generally available. Originally announced in public beta at the end of last year, this feature allows an identity provider to assign the guest collaborator role to a user which will restrict that user’s default access to internal repositories.

Our thanks go to the thousands of public beta participants that guided our hand to the GA experience. By popular request, today we also released a public beta for repository collaborator access in EMU enterprises! This brings the “outside collaborator” access style to EMUs, limited to selecting users that are members of the enterprise account. Combining these two features together lets you grant the most granular possible access rights to specific repositories and organizations that fit your needs for contractors and other limited access use cases.

Learn more about guest collaborators

Enterprise Managed Users can now be added directly to a repository in their enterprise as a collaborator, without becoming a member of the organization. These users function like outside collaborators, with a few differences:
1. Only user accounts from within the enterprise can be added to the repository. This means that users you want to collaborate with must still come from your linked identity provider (IDP).
2. EMU users can only be collaborators on repositories in their enterprise. EMU accounts cannot collaborate outside their enterprise.
3. Repo Collaborator invitations can only be sent by an EMU’s enterprise owner by default, while in non-EMU enterprises and organizations both enterprise and organization owners can manage outside collaborators.

Like outside collaborators – users do not have to SSO authorize their credentials in order to access repositories that they have been granted access to as a repository collaborators. This aligns to the current access model for internal repositories on GitHub.

You can try out repository collaborators by going to the repository policies section of your Enterprise settings and selecting which tiers of administrators are allowed to invite collaborators.

For more information about repository and outside collaborators, see “Roles in an organization“.

See more

Previously, developers who used private registries to host their packages on internal networks could not use Dependabot to update the versions of those packages in their code.

With this change, users can choose to run Dependabot pull request jobs on their private networks with self-hosted GitHub Actions runners, allowing Dependabot to access on-premises private registries and update those packages.

A prerequisite for enabling self-hosted runners includes enabling GitHub Actions for the repositories of interest. It’s important to note that running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.

To get started, check out our documentation on managing self-hosted runners with Dependabot Updates.

If you’re interested in learning more about what it means to run Dependabot as a GitHub Actions workflow, check out our changelog and FAQ or Dependabot on Actions documentation.

See more