Gleipnir
Become a design partner
relay relay Self-hosted fleet control for AI agents

Your AI agents can reach every node and endanger none.

Gleipnir Relay gives your AI agents and your ops team one way to inspect and recover a Linux fleet: check every node in one call, then restart a service on just the nodes where it’s failing. Each node runs only what its own root-owned Policy allows, and nothing sent over the wire can change that. Changes get their own, smaller reach cap, and can wait for a person to approve.

Become a design partner How it’s checked

From the first alert to the fix.

  • Checkout is throwing 502s.your operations service.status · disk.usage · logs.vacuum · service.restart → node:role=web Your AI agent finds three web nodes down and traces it to /var/log at 100%. Clearing logs waits for a person to approve; once they do, it frees the space with your team’s cleanup operation and restarts nginx on each node whose Policy allows it.
  • A NiFi node drops out of the cluster.your operations nifi.cluster_status · log.tail nifi · service.restart nifi → node:role=nifi Your AI agent checks cluster state with an operation your team wrote for NiFi, reads the logs, finds why the node fell out, and restarts NiFi on just that node. Your Policy defined every step before the incident started.
  • A CVE drops at 9am.your operations pkg.inventory · lb.drain → node:env=prod One call lists every node still running the vulnerable package. Your AI agent then asks a person to approve draining just those nodes from the load balancer, so no traffic reaches them until they’re patched.
  • Something is listening on 4444.built in net.listening → every node Security asks which nodes have an unexpected open port. One call answers, without opening a single SSH session.

Every operation is defined before your AI ever sees it.

AI agents don’t write commands. They call typed operations defined in advance, with every argument checked against the node’s Policy: a root-owned file, written by your config management, that lists what that node allows. Arguments can never change what runs. There is no shell for the AI to drop into, no way to chain a second command, and no path from one node to the next.

An AI agent can do exactly what it’s allowed to do, by definition.

/etc/relay-daemon/policy.toml 
# Deny-by-default: no rule, no run.[[operation]]name = "service.restart"allowed_args = [["nginx", "php-fpm"]][[operation]]name = "file.read"allowed_args = [["*"]]# Deny beats allow.[[deny]]name = "file.read"args = [["/etc/shadow"]]

Four checks. Each one can only say no.

Three on the Relay server, one on the node. Every refusal is recorded, and a compromised Relay server still can’t get past the last one.

Number check what it does
AI agent calls run_operation over MCP
01 account role Decides whether the caller may run operations at all.
02 reach cap Limits how many nodes one call can touch. Changes get their own, smaller cap.
03 approval gate Holds what it matches for a person. By default, never the one who asked.
04 node Policy The final word, on the node itself.
runs on each node that allows it
  1. AI agent calls run_operation
  2. 01 · account role Decides whether the caller may run operations at all.
  3. 02 · reach cap Limits how many nodes one call can touch. Changes get their own, smaller cap.
  4. 03 · approval gate Holds what it matches for a person. By default, never the one who asked.
  5. 04 · node Policy The final word, on the node itself.
  6. runs where allowed

Connections only go one way: each node’s daemon dials out to the Relay server. Nodes accept no inbound connections, and after enrollment both ends authenticate with mutual TLS.

Deployed by the config management you already run.

The Relay server runs under a hardened systemd unit. Your config management installs the relay-daemon on each node, verifies its checksum, and enrolls it with an expiring token you can limit to a set number of uses. Relay never pushes binaries or upgrades.

Relay’s web Console shows each node’s Policy fingerprint, so a node your rollout missed stands out.

Relay is available in alpha. Install it yourself from the release, or become a design partner and we’ll install it with you on a call. Either way, we never need access to your systems.

nodes
x86_64 Linux with systemd
relay-daemon
static Rust binary; dials out, never listens
Relay server
self-hosted, local storage, its own CA
record
every call, refusal, approval and Freeze, with who, what, where and when
telemetry
none
upgrades
through your config management, never pushed
license
source-available (BUSL-1.1)
price
free at home up to 25 nodes; from $75 a month at work

FAQ

Do my nodes need open ports?
No. The relay-daemon on each node dials out to the Relay server and holds that one connection. Nothing ever connects in to your nodes.
What if the Relay server is compromised?
An attacker can only request what each node’s Policy already allows. That Policy is root-owned on the node and can’t be changed over the wire.
What can the AI see?
Only what each node’s Policy lets it read. The default Policy blocks the usual credential files and keys.
Is there an escape hatch?
Raw Exec runs one exact command, never a shell. It’s off by default, admin-only, and limited to what that node’s Policy matches.
How do I stop everything at once?
Engage Freeze. All new work stops fleet-wide until an admin releases it with a recorded reason.
Does it replace Ansible?
No. Your config management still installs the daemon, writes each node’s Policy and runs upgrades. Relay handles response and day-to-day work.
Design partners

Run Gleipnir Runtime, Relay, or both, free for three months.

You get
Runtime and Relay free for three months, direct access to the engineering team, and a say in the roadmap.
We ask
Run it on your own work and join a call every other week to tell us what you’ve seen.
How long
Three months free. Then early-adopter pricing (40% off) locked in for 24 months, or walk away and give up the lock-in.
Become a design partner See pricing and licensing