Centralized remote access for Linux devices, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

What it is: Open-source (Apache-2.0) centralized SSH gateway — think a jump host you actually control, with a web UI, firewall rules, and session recording built in [2].
Who it’s for: Engineers and DevOps teams managing Linux devices across cloud, edge, or IoT environments who are done fighting with NAT, dynamic IPs, VPN configurations, and jump hosts [README].
Cost savings: Pricing for ShellHub Cloud is not published on the homepage — contact sales. The self-hosted Community Edition is free and unlimited. Commercial SSH access tools like Teleport Team or JumpCloud run $3–8/user/month or more; with 10 engineers on a team that’s $360–$960/year minimum.
Key strength: No public IP required on managed devices. The ShellHub agent phones home through the gateway, so it works behind NAT, firewalls, and CGNAT without touching router config [README][1].
Key weakness: 1,960 GitHub stars puts it well behind Teleport or Guacamole in community size and integration depth. Community Edition is missing MFA, session recording, and firewall rules — those are Enterprise-only [2].

What is ShellHub

ShellHub is a centralized SSH gateway. You deploy it once (self-hosted or cloud), install a lightweight agent on each Linux device, and from that point you can SSH into any of those devices from anywhere — using a standard SSH client, a browser terminal, or the mobile app — without needing a public IP, VPN, or jump host on the target device [README][3].

The core problem it solves is real: every operations team eventually builds some version of this themselves. You get a fleet of servers and IoT devices spread across clouds, co-los, and customer premises. Some have public IPs, most don’t. You end up maintaining a jump host, managing VPN credentials, or begging network teams to open firewall rules. ShellHub replaces that ad-hoc infrastructure with a purpose-built, auditable gateway [README][2].

The GitHub repository describes it as “centralized SSH for the edge and cloud computing” — which is accurate without being oversold [README]. The homepage pitches “seamless, technology-driven remote access from anywhere, at any time,” which is where the marketing language starts creeping in. Ignore that, the underlying tool is genuinely useful for the right use case [website].

As of this review: 1,960 GitHub stars, Apache-2.0 license, 23 contributors listed in the README, 150,000+ devices using the technology, over 1 million agent downloads, deployments across 50+ countries [README][website]. The star count is modest for a tool in this category, but the download numbers suggest real production use.

Why people choose it

The available third-party coverage is thin — a Medium setup post from 2020 [4] and the official docs [1][2][3] — so this section draws more from the product’s own documentation and the specific technical problems it addresses, rather than synthesizing a rich review ecosystem.

The NAT problem. The single most-cited reason to run a centralized SSH gateway is NAT traversal. If your devices are at customer sites, behind CGNAT, or on dynamic IPs, you can’t SSH to them directly. The traditional answers — VPN, port forwarding, jump host — all require infrastructure you have to maintain and configuration on every router between you and the device. ShellHub’s agent model inverts this: the device calls out to the gateway, not the other way around. You connect to the gateway; the gateway proxies through to the device [README][3]. This is the architectural advantage.

The credential management problem. Managing SSH keys across a fleet gets messy fast. ShellHub centralizes public-key management — you add keys once to the dashboard, and they’re distributed to devices [README]. This is the same reason companies buy tools like Teleport or JumpCloud. Revoking a user’s access across 200 devices becomes a single operation instead of a scripted loop.

The audit problem. In regulated industries (healthcare, finance, industrial IoT), you need a record of who accessed what and when. ShellHub builds audit logging into the gateway — every SSH connection creates a session record [README]. Enterprise edition adds full session recording with replay [2]. One customer testimonial from an industrial controls company: “The tool allows the Engineering team to do a much more effective monitoring of the devices in the field, reducing our travel demands and enabling instant analysis of internal and field situations.” [website]

IoT and embedded Linux. The FAQ is explicit: ShellHub works on “any hardware architecture, from single-board computers to desktop, as long as the device has Docker installed.” [3] For Raspberry Pi and similar edge devices, there’s also a source-build path and Yocto Project integration, so Docker isn’t a hard requirement [3][4]. The Karmine Medium post specifically walks through the non-Docker agent installation using Go build + systemd service [4] — useful for constrained devices where Docker overhead matters.

Features

Based on the README and official documentation:

Access and connectivity:

Native SSH support — connect using OpenSSH, PuTTY, or any standard SSH client without installing anything on the client side [README]
SCP/SFTP support for file transfers using standard tools [README]
SSH port forwarding — TCP tunnel from local port to remote device port, including SOCKS proxy [README]
Web-based terminal — browser access without any local SSH client [website]
Mobile app support [README]
Works behind NAT, dynamic IPs, and firewalls — agent initiates the outbound connection [README][3]

Authentication and access control:

Public-key authentication with centralized key management [README]
Multiple users can authenticate as the same system user with separate keys — revoke one without affecting others [README]
Firewall rules for filtering SSH connections by source, user, or device [README]

Audit and compliance:

Audit logging of all SSH sessions [README]
Session recording with replay via built-in player — Enterprise Edition only [2][README]
MFA (Multi-factor authentication) — Enterprise Edition only [2]

Administration:

Web-based admin console for device management — Enterprise Edition only [2]
Unlimited device management in Community Edition [2]
Docker-based agent installation (default) [1][3]
Source-build and Yocto Project integration for non-Docker environments [3][4]
Devices must be manually accepted in the dashboard before they become active [3]

Enterprise-only features (not in Community):

Session recording
MFA
Firewall rules management (the FAQ suggests this is cloud/enterprise gated [3])
Web-based admin console
Premium support with dedicated response times [2]

The community/enterprise split is worth paying attention to. Firewall rules are listed as a core feature in the README but the FAQ implies they’re a cloud-tier feature [3][README]. The official self-hosted docs put firewall rules under Enterprise Edition [2]. This inconsistency in documentation is a signal worth noting — the community edition feature boundary isn’t always clearly communicated.

Pricing: SaaS vs self-hosted math

Specific pricing for ShellHub Cloud is not published. The website offers three tiers — Community, Cloud, and Enterprise — but directs you to contact sales for Cloud and Enterprise pricing rather than listing numbers [website]. This is common for infrastructure tools targeting mid-market and enterprise buyers, and it’s mildly frustrating for a founder doing due diligence.

Self-hosted Community Edition:

Software license: $0 (Apache-2.0) [README]
A Linux VPS to run it on: $5–20/month
Docker and Docker Compose required on the server [1]
Unlimited devices in Community Edition [2]

Comparable commercial tools (for reference):

Teleport open-source is free; Teleport Team starts at approximately $5/user/month; Enterprise is custom pricing.
JumpCloud device management and SSH access: $3–11/user/month depending on tier.
Bastillion (open-source web SSH): free self-hosted but no gateway agent model — requires direct network access to targets.

For a team of 10 managing 50–200 devices: Teleport Team at $5/user/month is $600/year. ShellHub self-hosted on a $10 VPS is $120/year plus the setup time. The gap closes at enterprise scale but for small-to-mid teams the math is clear.

The real pricing question is whether the Community Edition covers your actual needs. If you need session recording, MFA, or the admin console, you need Enterprise. If basic centralized SSH with public-key management and audit logs is enough, Community Edition self-hosted is genuinely free and unlimited.

Deployment reality check

The install path is Docker Compose, documented in the official getting-started guide [1]. The broad strokes:

git clone -b v0.9.4 https://github.com/shellhub-io/shellhub.git shellhub
cd shellhub
make keygen
make start

First startup can take up to 10 minutes [1]. After that, the web UI is accessible at http://localhost. Production deployments require SSL, which you handle by putting nginx or Caddy in front of the Docker containers — ShellHub doesn’t manage that for you [1].

What you actually need:

A Linux server with Docker and Docker Compose installed
Ports 80 (HTTP) and 22 (SSH) open inbound
A domain and reverse proxy for HTTPS in production
Enough compute to run multiple microservices (ShellHub uses a microservices architecture internally) [1]

Important: port 22 conflict. ShellHub’s gateway listens on port 22 — which is also where your host’s SSH daemon typically listens. The Karmine setup guide flags this directly: “since the ShellHub Server will be using the SSH port: 22, I recommend you to change the sshd port to something different” [4]. If you forget this and lock yourself out of the server, you’re in a bad position. This is a concrete gotcha that the official docs [1] don’t foreground prominently enough.

Agent deployment:

Docker-based: simplest, just run the agent container with your tenant ID [3]
Binary without Docker: requires building from Go source; Karmine’s Medium post walks through this including the systemd service file [4]
Yocto integration: for embedded Linux images baked at build time [3]

Device acceptance: New devices appear in a “pending” state and require manual acceptance in the dashboard before they become accessible [3]. This is a security feature, not a bug — but it means automated fleet onboarding requires a workflow step that you’ll want to script.

The docker-compose down warning: Running docker-compose down destroys volumes and wipes your data — devices, users, audit logs [3]. Use docker-compose stop if you just want to pause the server. The FAQ calls this out explicitly, which suggests it’s bitten people.

Realistic setup time for a technical user: 1–2 hours to a running instance with HTTPS and a first device registered. For someone who hasn’t configured nginx or Docker Compose before: budget a full afternoon.

Pros and Cons

Pros

No public IP required on managed devices. The agent-phones-home architecture means you can reach devices behind NAT, dynamic IPs, and firewalls without touching network config [README][3]. This is the killer feature for edge and IoT use cases.
Apache-2.0 license. Permissive. You can self-host, fork, embed in your product, or distribute it commercially without a commercial agreement [README]. This is a meaningful advantage over tools with more restrictive open-core licensing.
Standard SSH protocol. You connect using OpenSSH or PuTTY — no proprietary client, no plugin, no agent on your workstation [README]. Existing scripts and tooling just work.
SCP/SFTP included. File transfers work through the same gateway without additional configuration [README].
SSH port forwarding. Tunneling TCP traffic and SOCKS proxy through the gateway covers a lot of “access a service running on that device” use cases [README].
Real production adoption. 1M+ agent downloads, 150K+ devices, customer testimonials from industrial and embedded Linux companies [website] — this isn’t a side project with a polished README.
Works on any Linux hardware architecture including Raspberry Pi and single-board computers [3][4].
Non-Docker agent path. The Go binary + systemd service approach means you can run the agent on constrained devices where Docker is too heavy [4].

Cons

Session recording, MFA, and firewall rules are Enterprise-only. The Community Edition covers basic centralized SSH, but the features most compliance teams care about — audit trails with session replay, MFA enforcement, fine-grained firewall controls — require the paid tier [2]. This is the central trade-off.
Documentation inconsistency on feature boundaries. The README lists firewall rules as a core feature; the self-hosted docs put them in Enterprise Edition [README][2][3]. If you’re evaluating Community Edition specifically, you need to read the docs carefully rather than trust the marketing copy.
Port 22 conflict is a real gotcha. The SSH gateway competes with the host sshd for port 22. Easy to get wrong, potentially dangerous if it locks you out of the server [4]. Needs better upfront documentation.
docker-compose down destroys data. Wiping your device registry and audit logs with a common Docker command is a significant operational risk. Production deployments need documented backup/restore procedures [3].
Small contributor community. 23 contributors in the README, 1,960 GitHub stars [README]. Compare to Teleport’s substantially larger ecosystem. Fewer integrations, fewer guides, fewer community plugins.
No built-in Kubernetes agent. The FAQ mentions Docker and source-build paths but not Helm charts for running agents on Kubernetes clusters. If you’re managing K8s nodes this way, you’re on your own.
Cloud pricing is opaque. No pricing published for ShellHub Cloud — contact sales. Fine for enterprise buyers, frustrating for founders trying to compare options [website].

Who should use this / who shouldn’t

Use ShellHub if:

You manage Linux devices at edge locations, customer sites, or behind NAT where you can’t guarantee a public IP.
You want a free, Apache-licensed SSH gateway with no per-device or per-user fees on the self-hosted tier.
Your team already uses standard SSH tools and you don’t want to retrain anyone on a proprietary client.
You need IoT or embedded Linux device management — ShellHub explicitly supports any Linux hardware architecture including ARM and Yocto builds [3].
Basic centralized SSH with audit logging covers your compliance requirements (Community Edition) — or you’re willing to pay for Enterprise for session recording and MFA.
You want to eliminate jump hosts and per-site VPN tunnels without rebuilding your network architecture.

Skip it if:

You need session recording, MFA, or role-based firewall rules and aren’t ready to pay for Enterprise. These are not in the free Community Edition [2].
You’re managing Windows devices. ShellHub is explicitly Linux-only [3].
You need Kubernetes-native access patterns (exec into pods, Kubernetes RBAC integration). That’s Teleport’s territory.
Your compliance requirements include certificate-based authentication with a certificate authority and short-lived credentials. Teleport’s model is more mature here.
You need a tool with deep community documentation, third-party integrations, and abundant “how I set this up” blog posts. ShellHub’s ecosystem is thin.

Skip it (pick Teleport open-source instead) if:

You’re managing cloud infrastructure and want native AWS, GCP, and Azure integrations alongside SSH access.
You need Kubernetes exec, database access proxying, or application access all in one tool.
Your team wants certificate-based short-lived SSH credentials instead of long-lived keys.

Skip it (use a simple VPN instead) if:

You have fewer than 10 devices and a technical person who can configure WireGuard. A WireGuard VPN on a $5 VPS is simpler to operate and understand for small fleets.

Alternatives worth considering

Teleport — the obvious benchmark. More mature open-source edition, larger community, Kubernetes and database access alongside SSH, certificate-based credentials, native cloud integrations. The open-source edition is free but more complex to deploy. Commercial plans at ~$5/user/month for teams. More powerful; steeper learning curve.
Warpgate — newer open-source SSH and HTTPS bastion written in Rust. SSH and web-based access, recording, MFA. Lighter than Teleport. Still early-stage (smaller community than either ShellHub or Teleport).
Bastillion — web-based SSH bastion. No agent model — requires network-level access to targets, so it doesn’t solve the NAT problem. Works well for traditional server fleets with direct connectivity.
Guacamole (Apache) — web-based remote access with SSH, RDP, and VNC. Much broader protocol support, significantly more complex to deploy. Useful if you need Windows RDP alongside SSH.
JumpServer — Chinese-origin open-source PAM with SSH, RDP, web access, and session recording. Feature-rich. Worth evaluating if you need enterprise PAM features without enterprise pricing. More complex deployment.
WireGuard + jump host — not a product, but the common DIY alternative. One WireGuard peer per site, one jump host, standard SSH. More manual operational overhead but simpler architecture that any Linux admin understands.
Boundary (HashiCorp) — identity-based access management, integrates with Vault for dynamic credentials. Enterprise-grade but genuinely powerful. overkill for small teams; strong choice for organizations already on the HashiCorp stack.

For a non-technical founder managing a small Linux fleet and wanting something self-hosted and free: the realistic shortlist is ShellHub Community vs Warpgate vs a WireGuard VPN. ShellHub wins if you have mixed/IoT devices behind NAT. WireGuard wins if the fleet is small and you have someone technical to configure it once.

Bottom line

ShellHub solves a specific problem well: it gives you a centralized, auditable SSH gateway for Linux devices that don’t have public IPs, without requiring you to reconfigure every firewall and router between you and your fleet. The Apache-2.0 license and unlimited-device Community Edition make the self-hosted path genuinely free and unrestricted. For IoT and edge deployments — industrial equipment, field devices, distributed Raspberry Pis — this is one of the few purpose-built tools in the open-source space that addresses the NAT traversal problem without bolting on a VPN.

The trade-offs are real. The community is small, third-party documentation is sparse, and the features that compliance teams care about (session recording, MFA, firewall rules) are locked behind the Enterprise Edition. The docker-compose down data-loss gotcha and the port 22 conflict are rough edges that a more mature project would have smoothed over. If you need Teleport’s feature depth — certificate-based credentials, Kubernetes access, database proxying — ShellHub won’t get you there. But if the problem is specifically “I need SSH access to Linux devices behind NAT and I don’t want to pay per seat,” ShellHub Community Edition on a $6 VPS is a legitimate answer.

If the deployment is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for clients. One-time setup fee, you own the infrastructure.

Sources

ShellHub Installation Guide — “Installing — ShellHub”. shellhub-io.github.io. https://shellhub-io.github.io/getting-started/installing/
ShellHub Self-Hosted Documentation — “Introduction | ShellHub”. docs.shellhub.io. https://docs.shellhub.io/self-hosted/
ShellHub FAQ — “Frequently Encountered Issues — ShellHub”. shellhub-io.github.io. https://shellhub-io.github.io/support/faq/
Karmine, Medium — “ShellHub — Setup” (Dec 9, 2020). karmine.medium.com. https://karmine.medium.com/shellhub-setup-b7757e9ecaf6

Primary sources:

GitHub repository and README: https://github.com/shellhub-io/shellhub (1,960 stars, Apache-2.0 license, 23 contributors)
Official website: https://shellhub.io
Official documentation: https://docs.shellhub.io