Network security

Alpacon connects your servers to the platform through an agent that makes only outbound connections. Alpacon never opens an inbound connection to your servers, so no inbound port needs to be open for Alpacon access — your own services keep whatever ports they require. This page covers how the connection works and how to configure your network, firewall, and proxy for it.

For transport encryption, certificate management, and platform-side protections, see Platform security and availability.

Connection model

Agent-based, outbound only

Traditional SSH access requires you to expose port 22 to incoming connections. Alpacon works the other way around: the Alpamon agent on each server opens an outbound connection to the platform, and all access flows back through that channel.

Traditional SSH:
Internet → Firewall (inbound port 22) → Server

Alpacon:
Server → Alpamon agent (outbound only) → Firewall → Platform

What this gives you:

No inbound ports for Alpacon: The agent only dials out; Alpacon never connects in.
Outbound only: The Alpamon agent initiates every connection.
Firewall friendly: Works with restrictive firewall policies and network address translation, with no inbound allowlisting.
Location-independent access: Network location alone never grants access; every session is authenticated and authorized.

How a connection is established

Agent starts: The Alpamon agent starts on your server, opens an outbound connection to your workspace endpoint, authenticates with its server token, and keeps the connection alive with a heartbeat.
User connects: You sign in to Alpacon through the web console or CLI. When you open a server, the platform checks your permissions and routes the session through the agent’s existing outbound channel.
Session runs: There is no direct connection between you and the server. The platform relays the session, which is encrypted in transit. Closing either end ends the session.

Agent network requirements

The Alpamon agent needs outbound HTTPS and WebSocket (WSS) access to your workspace endpoint. It does not open any listening ports on the host.

Endpoints:

Outbound HTTPS (443) to <workspace>.<region>.alpacon.io
Outbound WSS (443) to <workspace>.<region>.alpacon.io for the persistent channel

Footprint: The agent is lightweight, typically using around 128 MB of memory and 150 MB of disk. It reconnects automatically with exponential backoff after a network interruption, and reattaches to sessions it had launched.

Proxy support:

# Configure an HTTP proxy
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
 
# Configure a SOCKS proxy
export ALL_PROXY=socks5://proxy.company.com:1080
 
# Restart the agent to apply
sudo systemctl restart alpamon

Firewall configuration

Required outbound rules (server side)

For servers running the Alpamon agent:

Protocol	Port	Destination	Purpose
HTTPS	443	`<workspace>.<region>.alpacon.io`	Agent connection
WSS	443	`<workspace>.<region>.alpacon.io`	Persistent channel
HTTPS	443	`api.github.com`	Agent version checks
HTTPS	443	`github.com`, `release-assets.githubusercontent.com`	Agent install and self-update
HTTPS	443	`*.amazonaws.com` (S3)	WebFTP file transfer (optional)

Some optional features reach additional endpoints: the in-browser code editor downloads from code-server.dev and open-vsx.org on first use, and Linux package installs use packagecloud.io. Allow these only if you use those features.

Example iptables rules:

# Allow outbound HTTPS to your workspace
iptables -A OUTPUT -p tcp --dport 443 -d <workspace-ip> -j ACCEPT
 
# Allow established connections back in
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Drop all other inbound traffic
iptables -A INPUT -j DROP

Required outbound rules (client side)

For users accessing Alpacon from a web browser or the CLI:

Protocol	Port	Destination	Purpose
HTTPS	443	`alpacon.io`	Main application
HTTPS	443	`<workspace>.<region>.alpacon.io`	Workspace access
HTTPS	443	`auth.alpacon.io`	Authentication
WSS	443	`<workspace>.<region>.alpacon.io`	Terminal sessions

Corporate firewall and proxy

Alpacon works behind corporate proxies.

Supported configurations:

HTTP/HTTPS proxy: Standard proxy using the CONNECT method
SOCKS proxy: SOCKS4 and SOCKS5
Authenticated proxy: Username and password authentication
Proxy auto-config (PAC): Automatic proxy configuration

Proxy bypass:

# Bypass the proxy for the local network
export NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16

IP allowlisting

🚧 Coming soon - planned for the Essentials plan or higher.

IP allowlisting will let you restrict access by source IP address for tighter control:

Workspace-level allowlist:

Restrict workspace access to specific IP ranges, such as office networks or VPN gateways
IPv4 and IPv6 addresses
CIDR notation for flexible ranges

Server-level allowlist:

Apply IP restrictions to individual servers
Useful for production databases that need extra protection
Override the workspace-level setting per server

Use cases:

Office-only access to a workspace
VPN-gateway-only access for production servers
Geographic restrictions for compliance
Partner and vendor access management
Locking production databases down to application servers only

Need this today? Contact support@alpacax.com and let us know your requirements.

Programmatic access can already be restricted per token: service tokens support IP allowlists and rate limits. See Service tokens.

Migrating from VPN

Because access is granted per user and per server rather than at the network level, many teams retire a VPN that existed only to reach their servers. A phased rollout keeps a fallback in place until you are confident:

Run in parallel: Keep the existing VPN for emergency access, deploy Alpacon to your servers, and let the team get familiar with it.
Migrate gradually: Move non-critical servers first, then teams one at a time, watching usage and gathering feedback.
Decommission the VPN: Remove the VPN client from workstations and close its firewall rules. Keep the infrastructure available for a grace period as a fallback.
Complete the transition: Retire the VPN infrastructure and update your network documentation.

Best practices

For network administrators

Minimize attack surface: Block all inbound ports except essential services.
Segment the network: Isolate servers in separate network segments.
Monitor traffic: Use network monitoring to detect anomalies.
Keep the agent updated: Run the latest Alpamon version.
Log firewall rules: Enable logging on your firewall rules.

For server administrators

Close SSH: Block port 22 once Alpacon is deployed.
Monitor the agent: Watch agent status and connectivity.
Use your proxy: Configure the corporate proxy where required.
Centralize logs: Forward agent logs to your central logging system.

Troubleshooting

Agent shows as offline

Possible causes:

Firewall blocking outbound HTTPS or WSS
Incorrect proxy configuration
Network connectivity problems
Invalid agent token

What to check:

# Agent status
sudo systemctl status alpamon
 
# Connectivity to your workspace
curl -v https://<workspace>.<region>.alpacon.io/health
 
# Agent logs
sudo journalctl -u alpamon -f
 
# Test through a proxy
export HTTPS_PROXY=http://proxy:8080
curl -v https://<workspace>.<region>.alpacon.io/health

Slow terminal response