SSH is the only transport DeployOS uses to talk to your server no proprietary protocol, no custom daemon, just the same encrypted channel you already trust for ssh user@server.
What SSH Actually Gives You
An SSH connection is an encrypted, authenticated pipe between two machines over an untrusted network. Every command sent through it and everything sent back is encrypted end-to-end.
[Your Desktop] <=== SSH connection (encrypted) ===> [Your Server]
It's built into every Linux server and macOS machine, and available on Windows natively. Nothing extra to install on the server side.
What DeployOS Actually Sends Over It
It's worth being precise here, because "tunnel" can imply your app's live traffic routes through your laptop it doesn't. Your deployed apps are reached directly over the internet, on your server's own public IP, through the reverse proxy DeployOS installs there (Traefik or Caddy) with normal open ports 80 and 443.
The SSH connection is DeployOS's control channel, not a traffic tunnel. When you click Deploy, the desktop app opens an SSH session to your server and runs the actual commands remotely: git clone/pull, docker build, docker compose up, writing the proxy's route file, checking container health. Nothing about your visitors' HTTP requests passes through your desktop only the commands that set the deployment up do, and only while you're actively deploying.
That distinction matters for reliability, too: DeployOS's SSH layer does host-key pinning (so you're warned if a server's identity ever changes), automatic reconnection, and a heartbeat wrapper so a long silent build (like a large docker build) doesn't get mistaken for a dead connection and dropped.
Why SSH Over a Custom Agent?
| Feature | Plain SSH | Agent-Based | |---------|-----------|-------------| | Encryption | Built-in | Custom implementation | | Authentication | Key-based | Usually token-based | | Resource usage | None when idle | 100-500MB constant | | Audit trail | System logs | Vendor console | | Portability | Universal | Vendor-specific |
How a Deploy Actually Works
When you click Deploy in the app, here's what happens:
- The desktop app opens an SSH connection to your server
- It runs
git clone/pull(or reads your local folder), then builds the container (Railpack, Dockerfile, Compose, or a prebuilt image) - It writes the proxy's route file and reloads it, provisioning SSL via Let's Encrypt
- It probes the container's real port and health endpoint, self-correcting the route if the app is listening somewhere unexpected
- The SSH session closes nothing stays running on the server between deploys except your app and its containers
Every step in that pipeline runs over the one encrypted SSH channel. No data passes through DeployOS's own infrastructure, because there isn't any in the deploy path the connection goes straight from your desktop to your server.
Best Practices
Key Management
Use dedicated deploy keys, not your personal SSH key:
ssh-keygen -t ed25519 -f ~/.ssh/deployos -C "deployos@your-server"
ssh-copy-id -i ~/.ssh/deployos.pub user@server
Firewall Rules
Restrict SSH access to trusted IPs and disable password authentication:
# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy
Monitoring
Check for unauthorized SSH sessions:
ss -tnp | grep ':22'
last | grep still
The Bottom Line
Plain SSH isn't just secure it's the simplest, most auditable, and most portable way to manage remote infrastructure. By building on SSH rather than a custom agent, DeployOS ties your security posture to a protocol that's protected the internet for 30 years, not to a vendor's runtime.