allow private namespaces for orbs w/ CircleCI

Many organizations using orbs would most likely want to publish their orbs privately.

I assume orbs will be scoped to your GitHub org as namespace?

So it would be great if we can publish orbs to foobar/wizzle (assuming GH org foobar), and to have those be only visible to users / jobs within org "foobar"

  • Guest
  • Sep 17 2018
  • Candidate
  • Attach files
  • Michael Bailey commented
    7 May 12:24am

    You should be able load an orb from any repo in the same org as the repo building built.

    Config would look like:

    repo: my-private-orbs
    version: v1.2.3
    path: my-orbs/orbs.yml

    Circle already has the auth setup for the linked Github org `my-linked-org` , so the above config would use that auth to load:

  • Kevin Morton commented
    4 May 10:10pm


  • Ned Lucks commented
    30 Apr 07:00am

    +1 we could really use this with about 500 projects sharing the same private build steps.

  • Marc Destefanis commented
    16 Apr 02:00pm

    Any updates?

    I've seen that we can unlist orbs from the registry search results by using the CLI. But it's not enough as orbs are still world-readable and can therefore be used if referenced with a valid name.

    We would need private orbs on the organisation level.

  • Glenn Nagel commented
    8 Apr 02:09pm

    I'd love to see this ASAP, this is one of the features we get out of GCP that I would like to see here too.

  • A Al commented
    30 Mar 09:13pm

    Any updates Circle team?

  • Ilya Trushchenko commented
    20 Feb 06:55pm

     I can't believe it's still not implemented! 2 years!!!

  • ANDREW HILTON commented
    24 Jan 02:13pm


  • Joao Henrique Machado Silva commented
    19 Jan 10:24pm

    It's really a shame that this feature does not exists yet. It seems like a trivial thing to have in my opinion. And very important based on the amount of comments. 

  • Bryan Campbell commented
    19 Dec, 2019 08:06pm

    Today we opened 160 PRs to update our build configs from node 10 to node 12. Sure would be nice to be able to centralize our configuration into a private orb.

  • Aviad Shikloshi commented
    9 Dec, 2019 08:58am


  • Timothy c commented
    3 Dec, 2019 04:22pm

    Hidden is enough for our usecase

  • Igor Belikov commented
    16 Oct, 2019 07:53am

    Any progress on this? This is the most upvoted idea, having some kind of solution for this (and unlisting is not a real solution for a lot of us here) would be greatly appreciated.

    I had to create ~70 pull requests recently just because using orbs is a no go until there are private namespaces. If there's no real timeline on having them, I'd rather spend my time on migrating away from CircleCI at all.

  • Giuseppe Landolfi commented
    23 Sep, 2019 07:28am

    +1 from here as well. We're migrating to CircleCI and this one is the single most important thing that we miss. We're duplicating A LOT of config across projects because having our build steps public is not an option.

  • Guest commented
    20 Sep, 2019 06:48pm

    Really need this feature. There really aren't many options for sharing config across projects in CircleCi, there's pretty much no way to DRY out config at the moment. And having the orbs unlisted makes no difference, if the source can be seen then it represents a security concern and most companies are not going to be willing to allow that.

  • Guest commented
    18 Sep, 2019 06:40am

    +1 for real private orbs. unlisting is not enough..

  • Manuele Cavalli-Sforza commented
    17 Sep, 2019 11:50pm

    Thanks for the update! Are there any plans to develop fully private orbs? This is a blocker for our use case as well.

  • Admin
    Sara Read commented
    17 Sep, 2019 11:41pm

    Hi Everyone! It is now possible to unlist orbs from the registry search results by using our CLI. Documentation to do so can be found at:


    Please note that:

    • Unlisted orbs can be listed in the orb registry again with the same CLI command.
    • Only org admins can unlist/list orbs.
    • Unlisting an orb does not affect its ability to be referenced by name in builds or for its source to be viewed.
  • Dominik commented
    4 Sep, 2019 09:14am


    We want to be able to phase-out older orb versions in our company-internal workflows. We have checks running in the orbs which are company specific & will change over time.
    These orbs should not be publicly available as we don't guarantee any long-term maintenance on any version.

    For our use-case, we would:

    * either just need hidden orbs (as we don't put any secrets in orbs) and whitelisting our orb namespace (
    * or a third-party orb registry (

  • Filip Tepper commented
    2 Sep, 2019 05:35am

    I definitely need it to be truly private. I would go as far as saying that some parts of the build process are a trade secret from security perspective.

  • Load older comments
  • and 466 more