Warden Agent

Every deployment node runs a lightweight agent called Warden. It is the only software that communicates between your infrastructure and the LaserData control plane — and it does so entirely on its own terms.

Why Pull-Based

Traditional deployment agents use a push model — the control plane connects to your servers, runs commands, and pushes configuration. This requires open inbound ports, SSH access, or cloud-specific agents like AWS SSM.

Warden takes the opposite approach:

• Warden initiates all connections outbound to the control plane over HTTPS (port 443)
• The control plane never connects inbound to your infrastructure
• No SSH, no SSM, no open ports — your firewall only needs to allow outbound HTTPS

This means that even if the control plane is fully compromised, an attacker cannot push commands to your VMs. There is no inbound attack surface.

Deployments are also fully network-isolated by default. No traffic reaches your deployment endpoints until you explicitly create Access Rules — this includes LaserData itself. Our control plane orchestrates infrastructure but has no network access to your data or endpoints.

What Warden Manages

On each node, Warden is responsible for:

Stream UI

Warden embeds a full web interface — Stream UI — directly on every node. Stream UI lets you browse and manage your Iggy data:

• Streams, topics, partitions — view structure and metadata
• Messages — browse, search, and inspect individual messages
• Consumer groups — view connected consumers and their offsets
• Clients — see currently connected clients

Because Stream UI runs on the node itself, your data is accessed locally in full isolation — it never transits the control plane or any external service. Access to Stream UI is governed by the same Access Rules as your Iggy endpoints, so you control exactly who can reach it.

Task System

All operational changes — configuration updates, upgrades, certificate rotations — flow through a cryptographically signed task system:

1. An action is triggered (via Console, API, or automated process)
2. The control plane creates and signs the task
3. Warden polls for new tasks on its next cycle
4. Warden verifies the signature, then executes the task
5. Warden reports completion or failure back to the control plane

Warden rejects any task with an invalid signature. This ensures tasks cannot be tampered with in transit and always originate from the legitimate control plane.

Upgrades and Rollbacks

Upgrades are fully automated and zero-downtime:

1. A new version is published and a task is sent to Warden
2. Warden downloads the new binary, verifies its cryptographic signature, and swaps it in atomically
3. If the new version fails to start, Warden automatically rolls back to the previous version

Warden can also upgrade itself without stopping Iggy or Connectors — managed services continue running uninterrupted during a Warden self-upgrade.

All binaries (Warden, Iggy, Connectors) are cryptographically signed. Warden rejects any binary that fails verification, preventing supply chain attacks.

Credential Scope

Each Warden agent authenticates with a token scoped to a single node. If a token is compromised, the blast radius is minimal:

Network Requirements

No inbound firewall rules required. No SSH, no SSM, no bastion hosts.