Does Digger’s Orchestrator Backend need to be accessible publicly?
We often get asked this question. The answer is simple - the orchestrator backend for Digger does not necessarily need to be publicly accessible, but it does need to interact with GitHub to trigger CI jobs. So basically, whether you choose to self-host Digger or use the managed Digger Cloud service, the orchestrator must be able to receive events from GitHub and start jobs in your CI system.
Self hosting Digger - Resources
To get started with self-hosting, you can refer to the following resources from our docs:
Each of these guides includes steps on prerequisites, setting initial environment variables, starting the service, creating a GitHub app, and installing the GitHub app.
If self-hosting, it's important to ensure that your Digger instance is properly secured, especially if it is accessible over the internet.
Backend-less mode
However, for hobby developers, POC’s without approval from compliance and for small teams self-hosting the orchestrator backend may not be needed, as Digger can run as a standalone GitHub Action without a backend, known as "backendless mode."
This configuration, however, won't have certain features such as concurrency, has a potential for clashing applies, and there's a need for manual setup of buckets or tables for PR-level locks. This is purely for technical reasons, as all of the above mentioned features require some sort of a backend.
Conclusion
So, in summary, whether you need your orchestrator to be public or not will depend on your network setup and how you manage GitHub's interaction with the Digger orchestrator backend.
If you opt for Digger Cloud, this is managed for you and the backend will be accessible as needed without you having to expose anything publicly.