Github-action: action in private repository

Too sad that this limitation wasn’t extended to organization level. Feels like the actions product is aimed for OOSS despite the price level for private usage.

This one piles on top of not being able to share secrets at organization level, not being able to manage secrets with the API, and more limits that make us hard to migrate from other providers (in my case circleci).

Hope this gets better in the next months


Perhaps using the external actions as git submodules would solve your problem?

1 Like

Thought the same but the GitHub token generated for the workflow is scoped specifically for the repo, so you have to manually setup additional secrets for cloning or checking out submodules.

:point_up_2:t2: I help maintaining this and it solves another kind of problem.

Just in case someone else wondered: this is doable but requires an additional token capable of cloning the other repo to be added as a secret as the token made available to the action is limited to the repo in question. With no API for managing secrets, this introduces toil.

The workarounds mentioned here are great, but this needs to be added natively - as organisations cannot be expected to publicly share their actions.

Is there a roadmap for this?

I’ve noted InVision havea workaround for this too:


Hello, any news about this issue?

Github actions is pretty useless for organizations without it :frowning:

Thank you!


Same with us. We are looking forward for this feature. So at least we need to see a roadmap for this in order to start using actions at organization level. 



Chiming in here for our organization.  This is a pretty crucial feature for Enterprise customers, and it’s somewhat disheartening to see it missing since GitHub actions as a whole is, in my opinion, a game-changer.


In theory, using the checkout action to clone the private repo into the workspace where you want to use it should work or?

It does. Now that there are preview APIs for managing secrets, you can wire up a secret for cloning the private action repo, but it is still a hack.

github/checkout@master recently got updated to include submodules. I have been doing it this way. Definitely a “hack” still, but very workable.


+1 for use within organizations. Without this, we need to repeat code in a lot of places.


this worked for me…  hope it helps!

name: Awesome Action

    types: ['opened', 'edited', 'reopened', 'synchronize']

    name: Awesome Action
    runs-on: ubuntu-latest
      # checkout this repo
      - name: Checkout Repo
        uses: actions/checkout@v2
      # checkout the private repo containing the action to run
      - name: Checkout GitHub Action Repo
        uses: actions/checkout@v2
          repository: MyOrg/my-action
          ref: v0.1.2
          token: ${{ secrets.GIT_HUB_TOKEN }} # stored in GitHub secrets
          path: .github/actions/my-action
      - name: Run My Action
        uses: ./.github/actions/my-action

Works like a charm :slight_smile:

Hey, but a good workaround.

oh perfect thanks Patrick. I wonder if this is actually the intended usage, but it does sound like Github haven’t thought about it. This is and submodules are a very good workaround, but it’d be nice if you could add tokens to uses part.


Works perfectly! Thank you! So much better than submodules.

workaround works, but more interested to see native support for private actions (aka, actions in private repo) to able to share in the org or even cross orgs.

1 Like

+1 for having private actions built-in support. This is definitely a must have for organisations like the one I currently work for that has hundreds of repos, most of them with the same CI/CD workflows. Copy and paste the same code is one of the worst code smells ever!

As we could not wait for the built-in support to start using GitHub Actions professionally, I’ve created a (public / published) custom action to solve the problem the way we think it’s good for our currently needs. I hope it can help someone: