Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Microsoft-hosted public CI/CD runtimes

24 Nov 2025 🔖 devops
💬 EN

Table of Contents

I drafted an architectural building block and network diagram to better communicate how publicly-networked Microsoft-hosted CI/CD runtimes work.

Default is publicly networked

  • When you author the .yml file defining a GitHub Actions workflow, you have to specify a runs-on for each job. If you use one of the built-in defaults like 'ubuntu-latest', then you’ve just chosen to use a publicly networked, fully-managed GitHub-hosted runner that already comes not only with Ubuntu Linux, but also with git preinstalled, Node.js preinstalled, a Java compiler and interpreter preinstalled, etc.
  • Same goes for authoring an Azure DevOps (“ADO”) Azure Pipelines pipeline. If you choose vmImage: 'ubuntu-latest', you’ll run a publicly networked, fully-managed Azure Pipelines Microsoft-hosted agent that, again, comes with lots of software preinstalled in addition to its Linux operating system.

Default capabilities

These default runtimes enable GitHub Actions / Azure Pipelines to:

  1. Build/compile source code (stored in Azure Repos / GitHub Repositories) into executable artifacts.
  2. Deploy those executable artifacts into their target “compute” runtime infrastructure.
    • (As long as the target infrastructure is also publicly networked.)

Network Diagram

It isn’t pretty, because it’s hacking a flowchart into pretending to be a network architecture diagram, but I think it sorta works.

Here are 3 options to view the diagram:

  1. View in the Mermaid Live Editor.
  2. View in the Mermaid Playground.
  3. If the links above ever auto-expire, copy the source code below, and paste it yourself into the Mermaid Live Editor.
graph TD;

    %% Box definitions (used as architectural resource nodes)

    repo_forge["📂: Source code version control _(GitHub Repositories or Azure Repos)_"]
    cicd_public_runtime["🚀: CICD PaaS _(GitHub Actions or Azure Pipelines)_ public runner/agent _(Microsoft-assigned IP address)_"]

    idp_instance["🧑🏿‍🤝‍🧑🏿: Identity provider _('IDP')_"]

    vendor_controller_internet["⚙️: publicly networked cloud/vendor infrastructure/controller/API _(e.g. AWS/Azure/GCP resource instances, Salesforce orgs, ServiceNow helpdesks, etc.)_"]


    %% Subgraph definitions (used as network boundary surrounding-boxes)

    subgraph idp_cloud["☁️: Cloud-based IdP _(public internet)_"]
        idp_instance
    end

    subgraph forge_cicd_commercial["☁️: GitHub.com or ADO"];
        repo_forge
        cicd_public_runtime
    end

    subgraph vendor_internet["☁️: Vendor/Cloud/etc. target resources _(public internet)_"]
        vendor_controller_internet
    end


    %% Arrow definitions

    repo_forge --> |"Step 1/3: code edit, schedule, etc. triggers CI/CD job within:"| cicd_public_runtime

    cicd_public_runtime -.-> |"Step 2/3: assumes appropriate nonhuman identity _(tip: hopefully over OIDC; see footnotes)_, if necessary, from:"| idp_instance

    cicd_public_runtime --> |"Step 3/3: runs CI/CD job against:"| vendor_controller_internet

Recommendation

I believe that CI/CD pipeline authors should attempt to use their CI/CD platforms’ default publicly networked, managed runtimes before exploring private-networking-related workarounds.

Even job-by-job!

For example, it’s already conventional for CI/CD pipeline authors to split CI/CD behavior into separate “build” and “deploy” jobs that each use their own runtimes.

  • Inevitably, “deploy” jobs into privately networked target infrastructure likely need workarounds.
  • However, the preceding “build” jobs might still be able to leverage CI/CD platforms’ default publicly networked, managed runtimes.

Known issue

Because these managed CI/CD runtimes exist on the public internet, in an enterprise setting, these runtimes’ (rapidly changing and widely shared by other customers) IP addresses are typically forbidden from deploying “built” executable artifacts into privately networked target infrastructure, such as:

  1. on-prem virtual machines
  2. privately networked web-hosting PaaS instances (e.g. AWS Elastic Beanstalk, Azure App Service, GCP App Engine, etc.).

I’m planning to publish a sibling “privately networked CI/CD runtime” building block to demonstrate a workaround, soon.

--- ---