Fleet
Your own servers and clusters
Your servers and clusters, without opening a port.
Install one agent. It dials out, and every terminal, database query, kubectl call and internal dashboard goes through that connection — checked against guardrails, recorded, and tied to the person who asked.
- Inbound ports
- 0
- Agent modes
- host · docker · k8s · tunnel
- Databases
- Postgres · MySQL · Redis · Mongo
- Servers from
- Pro
$ curl -fsSL https://cdn.subnomic.com/subnomic/install.sh \ | sudo TOKEN=<token> bash subnomic-agent.service active · outbound only
How it works
Install, reach, govern.
Install the agent
A systemd service on a host, a Deployment in a cluster, or a container next to Docker. It opens one outbound connection and needs nothing inbound.
$ kubectl apply -f \
https://cdn.subnomic.com/subnomic/agent.yamlReach what is behind it
A terminal in the browser or subnomic ssh, a database console, internal web apps, and kubectl through a generated kubeconfig — all over the same tunnel.
$ subnomic ssh db-primaryGovern it
Guardrails check commands and queries before they run, sessions are recorded for replay, and a server can require just-in-time approval before anybody connects.
Access and operations
What the agent opens up.
Terminal, in the browser or the CLI
An interactive shell on any host the agent runs on, with a per-command guardrail check. On Linux, people act as their own operator user.
A database console nobody needs a password for
PostgreSQL, MySQL, Redis and MongoDB. Every statement is classified as read, maintenance or write and needs the matching permission.
Internal apps
Open dashboards and web apps on private networks through the tunnel, without a VPN or an exposed port.
kubectl through the proxy
A generated kubeconfig sends kubectl through Subnomic, and deleting the cluster revokes it. Plus a browser API console.
Recorded, and watchable live
Terminal, pod-shell and database sessions recorded for replay. Watch a live terminal, send input, or end it.
Kubernetes resource manager
Inventory, YAML and form edits, image updates, cordon and drain, and right-sizing from the P95 of sampled usage.
Alerts, incidents, on-call
Rules on CPU, memory, disk and unhealthy resources open incidents, escalate to the on-call after fifteen minutes, and get an AI investigation.
Anomaly detection
Off-hours sessions, a first session to a new host, and mass file operations flagged against thresholds you can tune.
Patching and cloud accounts
Pending updates and security fixes via apt, dnf and yum; DigitalOcean and Proxmox machines provisioned with the agent already on.
Enterprise
What the Enterprise tier adds for the audit.
Everything above is in Team. These are the parts a security review asks about, and they come with Enterprise.
Just-in-time access and break-glass
Request, approve and let it expire — an hour by default. Break-glass is self-issued with a reason, fifteen minutes by default, and notifies owners at once.
Tamper-evident audit
The activity log sealed into a per-workspace hash chain; verification reports deleted and altered rows, and says how much is not sealed yet.
Audit streaming
Sealed entries delivered exactly once to a signed webhook for your SIEM, or to Slack.
Evidence packs
Access reviews and a ZIP of reports and raw evidence framed for SOC 2, ISO 27001, HIPAA or PCI DSS — material for your audit, not a certificate.
Workspace network restrictions
An IP allowlist in monitor or enforce mode, with a guard that stops you locking yourself out.
Ops notebooks
Runbooks whose steps actually run, next to the prose that explains them.
Guardrails
A rule list where the first match decides.
Rules are regular expressions matched against a query, a command or a Kubernetes change, in priority order. The first match wins — allow, deny or require approval — and if the rules cannot be loaded, the action is refused.
- Database queries and Kubernetes changes are checked on the statement itself, before it runs.
- Interactive shell rules are a guard against mistakes, not a sandbox: bash -c or an editor escape can get around them. RBAC, approval to connect and recording are the boundary.
- Unattended callers — schedules, workflows, AI — treat require approval as a refusal.
- A dry-run tester and 71 templates to start from.
# priority target pattern action
10 database \bdelete\s+from\s+scratch\b allow
20 database \b(delete|update)\b(?![\s\S]*\bwhere\b) deny
30 server \bsystemctl\s+(stop|restart)\b require_approval
40 kube delete.*namespace=prod denyPlans
Where each part starts.
| Plan | Free | Pro | Team | Enterprise |
|---|---|---|---|---|
| Servers & clusters | — | 3 | 25 | 250 |
| Terminal, apps, kubectl | — | ✓ | ✓ | ✓ |
| Database console, scheduled tasks | — | ✓ | ✓ | ✓ |
| Guardrails, session recording | — | — | ✓ | ✓ |
| Alerts, incidents, on-call, detection | — | — | ✓ | ✓ |
| Cloud accounts, patching, cost | — | — | ✓ | ✓ |
| Just-in-time access, break-glass | — | — | — | ✓ |
| Tamper-evident audit, audit streaming | — | — | — | ✓ |
| Evidence packs, IP allowlist | — | — | — | ✓ |
Every tier is bought the same way — Enterprise included. The whole price list.
Questions
The ones a security review asks first.
Does the agent need an inbound port?
No. It opens one long-lived outbound connection, and every kind of access shares it. It also refuses to dial anything outside its allowlist, which defaults to private ranges.
Which systems does the agent run on?
Linux with systemd is the tested path. Builds also ship for macOS, Windows, FreeBSD and OpenBSD on amd64 and arm64, and the Kubernetes agent runs as non-root.
Are database results stored in recordings?
No. A database recording keeps the query text, the row count and the timing — never the result rows.
Does it make us SOC 2 compliant?
No tool does. Evidence packs collect the access reviews, sessions, grants and configuration an auditor asks for, framed for the control set you name.
The rest of the workspace
Same bill, same credentials, same audit log.
Close the last inbound port.
Connect a server in a couple of minutes. Servers and clusters start on Pro.