Managing CI/CD Across Client Networks Without Losing Track of Access

When a deploy target sits inside a client's private network, a GitHub-hosted or GitLab-hosted shared runner usually can't reach it without a VPN tunnel you'd have to build and maintain yourself. A self-hosted runner placed inside the client's environment, registered to your GitHub Actions workflow or your GitLab CI project, solves this cleanly and is supported by both platforms.

The tradeoff is that you now own a small server living on the client's network, which needs patching and monitoring like anything else you're responsible for. Treat it as part of the engagement's infrastructure, not a one-time setup task you forget about after go-live.

The most common failure mode in MSP CI/CD isn't a broken pipeline, it's a deploy credential or a self-hosted runner token that's still active six months after the engagement ended. Set a calendar reminder tied to every client project's close date to revoke runner registrations, deploy keys, and any service account created specifically for that engagement.

Both GitHub and GitLab let you scope tokens narrowly and set expirations on them; use that instead of a token that works forever. A client finding your firm's unused credentials still active during their next audit is a worse outcome than the small friction of rotating credentials more often.

Change failure rate, how often a deployed change causes an incident, is one of the clearest signals of whether a client's pipeline is actually protecting them or just moving code faster into production¹. If your team is deploying into a client's environment several times a week and nobody is tracking how often those deploys cause a rollback or a support ticket, you don't actually know whether the pipeline is helping.

Add a lightweight tag in your ticketing system that flags whether an incident traces back to a recent deploy, and review it monthly with the client. It turns an abstract reliability conversation into a number you can both watch move.

Your firm's internal pipeline template, linting, test stages, required approvals, should stay the same across clients even when the deploy target changes from one client's on-premises server to another's cloud account. Consistency in the parts you control makes it easier to onboard a new engineer onto any client's pipeline without relearning your whole approach each time.

What should vary by client is the deploy step itself: the runner location, the credentials it uses, and the approval chain, since those genuinely depend on each client's environment and risk tolerance.

Before you connect a pipeline to a new client's environment, confirm:

• Who on the client side needs to approve a self-hosted runner living on their network, and has security signed off?
• What's the offboarding process for revoking runner tokens and deploy credentials at engagement close?
• Does the client require deploy logs to be retained for a specific period, and where will those logs actually live?
• Is there a single point of contact on the client side if a deploy needs an emergency rollback outside business hours?

Asking these questions before the first pipeline run saves a difficult conversation later, usually right when something's already gone wrong.

Some MSP engagements end with the client taking full ownership of the environment you built, and that transition goes badly more often than it needs to when the pipeline was never designed to be handed off. Keep the workflow file, the runner setup instructions, and a plain-language explanation of the approval chain in a single document the client's own IT staff can follow without you on the call.

Walk the client's team through an actual deploy before the contract ends, not just through documentation, so the first time they run the pipeline without you isn't also the first time anyone but your team has seen it work end to end. Schedule that walkthrough with enough runway to fix anything confusing, rather than squeezing it into the final week alongside everything else that's wrapping up.