Agents & orchestration
Pull-model orchestrators over mTLS that put certificates where they belong, reload the services that use them, and prove the renewal actually worked — on Linux and Windows.
No inbound connections. Ever.
An agent registers with a bootstrap token and receives an mTLS client certificate signed by a dedicated agent CA. New agents land pending until an admin approves them — only then can they claim work. From that point on they only pull: no listening ports on your servers, no inbound firewall rules, works behind NAT.
Register
Bootstrap token; the agent reports its capabilities and build id.
Approve
An admin gate before any job is claimed; the mTLS identity is issued.
Poll
The agent pulls jobs over mTLS, executes them, and reports results.
Supervisor + worker — built not to brick
The agent is split into two binaries, the same pattern used by Elastic Agent and Teleport. The supervisor holds the server connection and never restarts during an upgrade; the worker runs once per job as a short-lived subprocess. Upgrading the worker is just replacing a file on disk — the next job runs the new binary, with no restart and no connection drop.
ens0key-agent
supervisor- ▸Holds the mTLS connection: register, poll, report
- ▸Rotates the mTLS identity in place (reset / rekey)
- ▸Ships recent log lines into the UI on request
- ▸Runs upgrade jobs for the worker binary
ens0key-agent-worker
worker- ▸Executes each job as a short-lived subprocess
- ▸Store deploys with snapshot, post-deploy steps and verification
- ▸Discovery, ADCS enrollment, IIS binding on remote networks
- ▸Replaced on disk during upgrades — no restart, no downtime
Fleet upgrades from the platform
Outdated agents are upgraded with one click from the Agents page — no SSH or RDP to any host. A bad upgrade can never brick an agent.
Queue
The upgrade job is queued from the UI; the supervisor picks it up on its next poll.
Verify
The new worker is downloaded over mTLS, its SHA-256 is checked, and it must pass a self-test.
Swap
Atomic rename over the old binary; the previous version is kept on disk.
Roll back
Any failure keeps or restores the old worker — the agent stays online throughout.
Zero-touch renewal with a safety net
Renewal is a pipeline, not a script. Every step is recorded, and the last two are the ones nobody else ships built in.
Renew
The scheduler renews before expiry via the CA connector.
Deploy
The agent installs the certificate and key into the store, after taking a snapshot.
Reload
Ordered post-deploy steps reload the service that uses the certificate.
Verify
A service check confirms the new certificate is actually being served.
Rollback
Any failure restores the previous certificate automatically.
Post-deploy TLS verification with automatic rollback ships built into the product — not as a script somebody maintains on the side.
Run a fleet, not one host
Blueprints
Template a full agent configuration — stores, renewals, checks — and roll it out across the fleet in one action.
Health & logs
Online/offline from a 60-second heartbeat; recent agent logs pulled straight into the UI.
Reset & rekey
The mTLS identity can be re-keyed in place, cancelling in-flight jobs safely.
Capability routing
Agents report what they can do at registration — the server routes each job only to agents that can run it.
Watch a renewal roll back, live
In a demo we deliberately break verification — and you watch the agent restore the previous certificate.
Request a demo