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
GitHub-hosted runners live in Azure data centers, so they can't reach your private network by default, no matter how long you wait. Bring the runner inside the network with a self-hosted runner, or tunnel the MCP connection through a secure proxy. This is an execution-environment constraint, not a network glitch.
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.
The longer-timeout retry approach 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.
The public-exposure-with-authentication approach 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.
The self-hosted-runner-or-secure-tunnel approach is correct. The two standard solutions for this class of problem are: 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 establish a secure tunnel (for example, 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.
The GitHub Codespaces migration approach 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.