An agent runs inside a GitHub Actions workflow on a GitHub-hosted runner. The agent attempts to call an external MCP server hosted on a private network endpoint that is not reachable from GitHub's public runner infrastructure. The call fails with a connection timeout. What is the most appropriate architectural solution?
Select an answer to reveal the explanation.
Short Explanation and Infographic
GitHub-hosted runners live in Azure data centers — they cannot reach your private network by default, no matter how long you wait. The fix is to bring the runner inside the network (self-hosted runner) or create a secure tunnel between the two environments. This is a fundamental execution environment constraint, not a network glitch.
Full explanation below image
Full Explanation
GitHub-hosted runners execute in Microsoft Azure's cloud infrastructure and have outbound internet access but no native access to private networks, VPNs, or on-premises environments unless specifically configured. A connection timeout to a private MCP server is not a transient error — it is a structural mismatch between the execution environment and the required network topology.
Option A is wrong. The timeout is not intermittent — it is a predictable, consistent failure caused by network unreachability. Increasing the timeout will not resolve the underlying issue. GitHub-hosted runners simply cannot reach private network endpoints without additional configuration. Retrying indefinitely wastes pipeline time and does not address the root cause.
Option B is wrong. Exposing a private MCP server to the public internet specifically to accommodate GitHub-hosted runners creates a significant security risk. The private MCP server is private for a reason — it may have access to internal systems, sensitive data, or infrastructure controls. Making it internet-accessible (even with authentication) expands the attack surface unnecessarily. This trades a network architecture problem for a security problem.
Option C is correct. The two standard solutions for this class of problem are: (1) deploy a self-hosted GitHub Actions runner inside the private network where the MCP server is reachable — the runner has the same private network access as any other host on that network; or (2) establish a secure tunnel (e.g., a private network gateway, VPN bridge, or reverse proxy) between the GitHub-hosted runner environment and the private network. Both approaches solve the connectivity problem without exposing private infrastructure publicly.
Option D is wrong. GitHub Codespaces does not natively provide private network access. Codespaces run in cloud-hosted containers with internet access, not private network access. Additionally, Codespaces are an interactive development environment, not a CI pipeline execution environment. Migrating an agent workflow to Codespaces does not address the network access requirement.