For many enterprise teams, the move to Octopus Cloud can run into the same limitation: their artifact repositories, source control servers, and other internal tooling live behind a network perimeter that was never designed to accept connections from the outside world. Opening inbound firewall ports isn’t an option—not when security and compliance teams have spent considerable effort locking those down.
So teams make a pragmatic choice: stay on Octopus Server and deal with the cloud migration later. But by extension then they continue to manage Octopus upgrades and operating system patching too; and have to accept they won’t have access to new Octopus features as they come out.
We’ve watched this play out with a number of large enterprises. One of them is a major global financial services institution in the middle of a significant undertaking: migrating over a decade’s worth of legacy deployment infrastructure to Octopus. Thousands of pipelines and years of accumulated configuration. A migration that is touching nearly every team in the organization.
Going straight to Octopus Cloud is the obvious goal — less infrastructure to manage, no platform to maintain. But it’s being blocked by a straightforward problem: Octopus Cloud has no way to reach the systems that matter most—their internal Artifactory instance, and their GitHub Enterprise server and other internal systems. In a regulated environment, asking the security team to open inbound ports to a third-party SaaS platform isn’t a conversation that team wants to have.
Enter the Octopus Connection Agent, available from July 2026.
How it works
The Connection Agent is a lightweight Docker container you run inside your own network. When it starts, it opens a secure, outbound-only connection to your Octopus Cloud instance over port 443—the same port used for standard HTTPS traffic.
Because the connection is initiated from inside your network, nothing needs to change on your firewall. No inbound rules. No VPN. No publicly accessible endpoints for your internal systems. The agent authenticates using a private key, and Octopus proxies traffic through it to reach whatever internal resources you need.
The financial services institution in this story ran the Connection Agent as a Kubernetes pod inside their own cluster—fitting naturally into the container infrastructure they already operated. After completing the registration step, the logs confirmed what they’d been waiting for:
[10:55:05 INF] Registering Connection Agent with Octopus instance URL: https://{instance}.octopus.app/api/connectionagent/registrations
[10:55:05 INF] Successfully registered Connection AgentWithin a single maintenance window, their Octopus Cloud instance was reprovisioned, and traffic began flowing through the agent to their internal GitHub Enterprise server. Artifactory followed shortly after. The only firewall edit required: outbound port 443 access to their Octopus Cloud instance and to Octopus’s authentication service.
From blocker to enabler
Once the Connection Agent is running, they can get on with populating Octopus Cloud, skipping an entire phase of infrastructure work—requesting and configuring firewall ports—and instead focusing on what actually matters, getting thousands of pipelines migrated and teams deploying to production.
That’s not a small thing as every migration carries risk. And adding yet more company infrastructure configuration steps into the mix—in this case extra firewall rules—doesn’t actually move the migration forwards, it only further compounds the risk. By using the Connection Agent, the company removes that risk entirely.
Security by design
For teams in regulated industries, security isn’t a checkbox—it’s a constraint that shapes every decision. The Connection Agent was designed with that in mind.
All connections are outbound-only. The agent initiates the connection; Octopus never reaches into your network. Authentication uses JWT-signed private keys. You can configure ALLOWED_IP_RANGES to lock down exactly which internal hosts the agent can access, so you define the boundary explicitly rather than leaving it open-ended.
At this early stage, we support the publicly accessible Certificate Authorities (CAs). Though if your internal systems use certificates issued by an internal certificate authority—common in financial services—then for now you can use those internal certificates and CAs by setting --ignore-certificate-validation-errors for a given internal domain.
So if you need to pin specific CAs or certificates, let us know!
What’s more, if you need redundancy, you can run multiple agents across different Kubernetes clusters.
What’s supported
The Connection Agent currently supports:
- Git repositories (e.g. GitHub Enterprise, Bitbucket)
- SMTP servers
- External feeds:
- Artifactory Generic Feed
- Azure Container Registry
- Docker Container Registry
- GitHub Repository Feed
- Helm Feed
- Maven Feed
- NPM Feed
- NuGet Feed
- OCI Container Registry
Support for additional resource types is in active development. Early adopters are working directly with the team to shape what comes next, which means real customer use cases are driving the roadmap.
Action: We would love to hear what other connectors would help. You can share them with us here.
Getting started
The Connection Agent is available as a Docker image on Docker Hub and is limited to a maximum of 5 connections i.e. 5 internal resources as of this writing.
Full documentation can be found here.
If you’re on Octopus Server and a connectivity gap is what’s been keeping you from moving to cloud, or if you’re already on Octopus Cloud and working around the lack of access to your internal systems, talk to your account team as this is the piece that was missing.
Happy deployments!
Tags:
