When your servers sit behind a firewall, most deployment tools cannot reach them. The standard fix is a deployment agent — a lightweight process that runs inside your private network, connects outbound to the deployment platform, and routes deployment traffic through that tunnel.
Several tools offer this pattern, but the implementations differ significantly. This guide compares three deployment agents side by side: the DeployHQ Agent, the Buddy Proxy Agent, and the Octopus Deploy Polling Tentacle — covering architecture, setup, protocols, security, pricing, and the scenarios where each one fits best.
If you are not sure whether you need a deployment agent in the first place, read our guide on how to deploy to servers behind a firewall, which compares agents against SSH tunnels, VPNs, bastion hosts, and self-hosted CI/CD runners.
How Deployment Agents Work
All three tools solve the same fundamental problem: your deployment platform lives in the cloud, your server lives behind a firewall, and the firewall blocks inbound connections.
The solution is to flip the direction. Instead of the platform connecting inbound to your server, an agent on your server connects outbound to the platform. Since firewalls typically allow outbound traffic, the connection goes through. The platform then sends deployment instructions back through this established tunnel.
flowchart LR
A[Agent] -->|Outbound connection| B[Platform]
B -->|Deploy traffic| A
A -->|Local network| C[Server]
style A fill:#1abc9c,color:#fff
Where the three tools diverge is in the tunnel protocol, the agent-to-server relationship, and the scope of what the platform does beyond deployment.
Architecture Comparison
DeployHQ Agent: One Tunnel, Any Protocol
The DeployHQ Agent establishes a persistent outbound TLS connection to agent.deployhq.com on TCP port 7777. Once the tunnel is up, DeployHQ routes deployment traffic through it using whatever protocol the deployment target requires — FTP, SFTP, SSH, or S3.
flowchart LR
A[DeployHQAgent] -->|TLS port 7777| B[DeployHQ]
B -->|FTP/SFTP/SSH/S3| A
A -->|Any protocol| C[Server1]
A -->|Any protocol| D[Server2]
A -->|Any protocol| E[Server3]
style A fill:#1abc9c,color:#fff
The agent acts as a network proxy. One agent instance can deploy to multiple internal servers — you control which ones via an access file (~/.deploy/agent.access) that accepts individual IPs, hostnames, or CIDR ranges like 192.168.1.0/24.
Key technical details:
- Tunnel protocol: TLS over TCP (port 7777 outbound)
- Deployment protocols: FTP, SFTP, SSH, S3 — protocol-agnostic
- Agent-to-server ratio: One agent, many servers (proxy model)
- Runtime: Ruby 2.2+
- Platforms: Linux, macOS, Windows
- Open source: Yes — deployhq/deploy-agent on GitHub
- Reconnection: Automatic — runs as a background service
Buddy Proxy Agent: SSH Tunnels Under the Hood
The Buddy Proxy Agent establishes an outbound SSH connection to Buddy's infrastructure and keeps a reverse SSH tunnel alive. Buddy routes deployment traffic back through this tunnel to reach servers inside the private network.
flowchart LR
A[BuddyAgent] -->|SSH tunnel| B[Buddy]
B -->|SSH/SFTP only| A
A -->|SSH/SFTP| C[Server1]
A -->|SSH/SFTP| D[Server2]
style A fill:#9b59b6,color:#fff
Like DeployHQ's agent, Buddy's agent acts as a proxy — one agent can route traffic to multiple internal servers. You configure target servers as SFTP or SSH targets within Buddy, selecting the agent as the proxy during setup.
Key technical details:
- Tunnel protocol: SSH (reverse tunnel)
- Deployment protocols: SSH and SFTP only — no FTP or S3 support
- Agent-to-server ratio: One agent, many servers (proxy model)
- Runtime: Docker-based agent
- Platforms: Linux (Docker required)
- Open source: No
- Reconnection: Automatic while agent container is running
Octopus Deploy Polling Tentacle: Agent Per Machine
The Octopus Polling Tentacle takes a fundamentally different approach. Instead of one proxy for the network, you install a Tentacle on every deployment target. Each Tentacle independently polls the Octopus Server over HTTPS (port 443 or 10943) asking for work.
flowchart LR
A[Tentacle1] -->|HTTPS poll| B[OctopusServer]
C[Tentacle2] -->|HTTPS poll| B
D[Tentacle3] -->|HTTPS poll| B
style A fill:#e67e22,color:#fff
style C fill:#e67e22,color:#fff
style D fill:#e67e22,color:#fff
When the Octopus Server has a deployment task for a target, it responds to the next poll with the deployment package and instructions. The Tentacle executes the deployment steps locally — no traffic proxying involved.
Key technical details:
- Tunnel protocol: HTTPS polling (port 443 or 10943 outbound), WebSocket option available
- Deployment protocols: Custom Octopus protocol (Halibut) — packages are pushed to the Tentacle, which executes deployment steps locally
- Agent-to-server ratio: One Tentacle per server (per-machine model)
- Runtime: .NET
- Platforms: Windows, Linux, Docker containers
- Open source: Tentacle is open source; Octopus Server is not
- Authentication: Certificate-based mutual TLS
- Reconnection: Automatic polling on configurable interval
Side-by-Side Comparison
| DeployHQ Agent | Buddy Proxy Agent | Octopus Polling Tentacle | |
|---|---|---|---|
| Architecture | Proxy (one agent, many servers) | Proxy (one agent, many servers) | Per-machine (one Tentacle per server) |
| Tunnel protocol | TLS (TCP 7777) | SSH (reverse tunnel) | HTTPS polling (443/10943) |
| Deployment protocols | FTP, SFTP, SSH, S3 | SSH, SFTP only | Custom (Halibut) |
| Multi-server access | Yes — CIDR-based ACL | Yes — configure per target | N/A — one per machine |
| Agents to manage | 1 per network | 1 per network | 1 per server |
| Runtime requirement | Ruby 2.2+ | Docker | .NET |
| Platforms | Linux, macOS, Windows | Linux (Docker) | Windows, Linux, Docker |
| Open source | Yes | No | Tentacle only |
| Authentication | API token | SSH key | Mutual TLS certificates |
| Inbound ports needed | None | None | None |
| WebSocket support | No | No | Yes (Windows) |
| Setup time | ~5 minutes | ~10 minutes | ~15 minutes per server |
The Proxy Model vs the Per-Machine Model
This is the most important architectural difference and it affects everything from setup time to security posture.
Proxy Model (DeployHQ, Buddy)
One agent sits at the edge of your private network and proxies deployment traffic to internal servers. You install and manage one process. Adding a new server means updating a config file (DeployHQ) or adding a target in the UI (Buddy) — no software installed on the target server itself.
Advantages:
- Minimal infrastructure overhead — one process to monitor and maintain
- Adding or removing servers does not require installing or uninstalling agents
- The agent machine is the only one that needs outbound internet access
Trade-offs:
- Single point of failure — if the agent goes down, all deployments to that network stop
- The agent machine has network access to every whitelisted server, which means compromising it could allow lateral movement
- Deployment protocols are limited to what the platform supports through the tunnel
Per-Machine Model (Octopus)
Every deployment target runs its own agent. Each one independently connects to the Octopus Server and executes deployments locally.
Advantages:
- No single point of failure — one Tentacle going down only affects that server
- Each Tentacle can have independent security policies, update schedules, and permissions
- Deployments execute locally on the target, so no file transfer protocol limitations
- Better fit for environments where different teams own different servers
Trade-offs:
- More infrastructure to manage — N servers means N agents to install, monitor, patch, and update
- Every target server needs outbound internet access (or access to a shared Octopus Server)
- Adding a new deployment target means installing and configuring a new Tentacle
Which Model Fits?
The proxy model is simpler for small to medium deployments where one team manages a cluster of servers behind a single firewall. The per-machine model makes more sense in enterprise environments with dozens of servers, multiple teams, and compliance requirements that demand per-target audit trails.
Protocol Support
This is where DeployHQ's agent stands out.
Many legacy applications and hosting environments rely on FTP or SFTP for deployments — shared hosting with cPanel, older WordPress setups, and environments where SSH access is not available. Buddy's agent only supports SSH and SFTP, which means you cannot deploy to FTP-only servers through the proxy.
DeployHQ's agent proxies at the network level, supporting FTP, SFTP, SSH, and S3 through the same tunnel. This makes it the only option for teams that need to deploy to a mix of modern and legacy infrastructure behind the same firewall.
Octopus takes a different approach entirely — the Tentacle does not proxy protocols. Instead, Octopus sends deployment packages to the Tentacle, which executes deployment steps locally. This means protocol support is not a factor because files never transfer through a tunnel in the traditional sense.
Security Comparison
All three tools avoid inbound firewall rules, but their security models differ:
DeployHQ Agent: Outbound TLS on a single port (7777). The access control file explicitly whitelists which internal servers the agent can reach, limiting blast radius if the agent machine is compromised. The agent source code is fully auditable on GitHub.
Buddy Proxy Agent: Outbound SSH tunnel. SSH provides strong encryption, but the agent is not open source, so you cannot audit what runs inside the container. Access control is managed through Buddy's UI rather than a local config file.
Octopus Polling Tentacle: Outbound HTTPS with certificate-based mutual TLS authentication. This is the strongest authentication model of the three — both the server and the Tentacle verify each other's identity via certificates. However, each Tentacle has full local access to its host machine, and the .NET runtime has a larger attack surface than a Ruby gem or Docker container.
| Security Factor | DeployHQ | Buddy | Octopus |
|---|---|---|---|
| Encryption | TLS | SSH | HTTPS/TLS |
| Authentication | API token | SSH key | Mutual TLS certificates |
| Access control | Local file (IP/CIDR) | Platform UI | Per-Tentacle certificates |
| Open source agent | Yes | No | Tentacle only |
| Attack surface | Ruby gem | Docker container | .NET runtime |
| Blast radius if compromised | All whitelisted servers | All configured targets | Single server only |
Pricing
Deployment agents are typically bundled with the platform, but the platforms themselves have very different pricing models.
DeployHQ
Pricing is based on projects and servers. The Agent is included on all plans, including the free tier.
| Plan | Price | Projects | Servers |
|---|---|---|---|
| Free | €0/mo | 1 | 5 |
| Solo | €9/mo | 3 | 15+ |
| Pro | €19/mo | 10 | 50+ |
| Business | €39/mo | 20 | 100+ |
| Enterprise | €99/mo | 50+ | 250+ |
DeployHQ is a dedicated deployment tool — it does one thing (deploy code from Git) and the pricing reflects that simplicity.
Buddy
Pricing is based on seats and compute minutes. Agents are included, but Buddy is a full CI/CD platform, so you are paying for build pipelines, testing, and deployment together.
| Plan | Price | Seats | Key Limits |
|---|---|---|---|
| Free | €0/mo | 1 | 300 GB-minutes, 1 concurrent pipeline |
| Pro | €29/mo | 2 | 3,000 GB-minutes |
| Hyper | €99/mo | 5 | 6,000 GB-minutes, SSO |
Additional seats cost €9-29/month depending on the plan.
Octopus Deploy
Pricing is based on projects, with add-ons for machines and tenants. Octopus is an enterprise release management platform — significantly more expensive than the other two.
| Plan | Price | Projects | Machines |
|---|---|---|---|
| Free | $0/yr | 10 | 10 |
| Professional (Cloud) | $4,330/yr | 100 | 10 (add-ons: $770/yr per 10) |
| Enterprise (Cloud) | $24,600/yr | 100+ | Custom |
Each Polling Tentacle counts as a machine. Since you need one per server, costs scale linearly with your infrastructure.
Cost for a Typical Setup
For a team deploying to 10 servers behind a firewall:
| DeployHQ | Buddy | Octopus | |
|---|---|---|---|
| Monthly cost | €19 (Pro) | €29+ (Pro) | ~$361 (Professional) |
| Agents to install | 1 | 1 | 10 |
| Includes | Deployment only | Full CI/CD | Release management |
When to Use Each Tool
Choose DeployHQ Agent When:
- You need to deploy to servers using FTP, SFTP, SSH, or S3 — especially mixed-protocol environments
- You want a single agent proxying to multiple servers with minimal infrastructure overhead
- You prefer an open source agent you can audit
- You use a separate CI/CD tool (GitHub Actions, GitLab CI, Jenkins) and need a dedicated deployment step
- Budget matters — it is the most affordable option for deployment-only use cases
- You deploy to shared hosting, cPanel, or legacy infrastructure alongside modern servers
Choose Buddy Proxy Agent When:
- You want CI/CD and deployment in one platform
- All your servers support SSH or SFTP (no FTP-only targets)
- You need build pipelines running alongside deployment
- Your team is already using Buddy for other CI/CD workflows
Choose Octopus Deploy Polling Tentacle When:
- You need per-server agent isolation for compliance or multi-team environments
- You are deploying .NET applications on Windows infrastructure
- You need enterprise release management features (approvals, tenanted deployments, runbooks)
- You have the budget and team to manage Tentacles across many servers
- Auditing requirements mandate per-target deployment logs and certificate-based authentication
Conclusion
All three tools solve the same problem — getting deployments through a firewall without opening inbound ports — but they target different audiences:
- DeployHQ is the simplest path for teams that need protocol-flexible deployments with minimal infrastructure overhead
- Buddy bundles deployment with CI/CD for teams that want everything in one platform
- Octopus Deploy is enterprise release management for large-scale Windows/.NET environments
If you are just trying to deploy code to a few servers behind a firewall, the DeployHQ Agent is the fastest way to get there. Install one agent, whitelist your servers, and deploy — same workflow as any publicly accessible server.
Get started with DeployHQ — the Agent is available on all plans, including the free tier. For setup instructions, see the Agent documentation.
Questions about deploying to firewalled servers? Reach out at support@deployhq.com or on Twitter/X.