Warden Agent

Warden runs on every deployment node. It manages local runtimes and exchanges tasks, configuration, and telemetry with the LaserData control plane. A runtime is a managed process, such as Iggy or Connectors.

Why Pull-Based

Warden retrieves tasks instead of accepting inbound management connections. It starts outbound HTTPS connections on port 443. The control plane does not need inbound ports, SSH, AWS SSM, or a bastion host to manage a node.

Warden still runs authorized tasks from the control plane. The identity of that service and its task-signing keys remain part of the security boundary. Outbound-only connections do not remove that trust requirement.

Application traffic connects directly to deployment endpoints. Paid deployments need access rules first. Managed Free deployments include an initial global rule.

Architecture

What Warden Manages

Warden manages these services on each node:

Stream UI

Stream UI browses streams, topics, partitions, messages, consumer groups, and connected clients. It loads through the Console and runs in your browser. Application data travels directly between the browser and deployment node.

Data isolation

Stream UI separates data access from platform management:

• The browser calls Warden's HTTP proxy on the deployment node directly.
• The LaserData backend serves static application files. It does not receive stream contents, message bodies, or query results.
• Stream UI runs in a sandboxed iframe with its own origin, isolated from the surrounding Console. The surrounding Console cannot read its data.
• Each user receives a signed session token for one deployment. Tokens expire in minutes. Warden makes sure that the signature is valid on every request, using the Ed25519 key pair that also signs tasks.

Network requirements

Warden's HTTP proxy uses the Iggy HTTP API ports, 80 and 443. The iggy_http toggle therefore controls browser access. Add the browser IP to an access rule with iggy_http: true on the deployment. LaserData does not proxy these requests, so the rule needs no LaserData-owned IP.

Managed data

The data plane is the service that turns records into queryable views and state. A backend is a storage or query engine that this service uses. The Backends page configures those engines and requires deployment:config:manage. You do not need to open this page to send and read ordinary Iggy messages.

If the deployment runs the managed data plane, Stream UI also exposes its supported tools. Requests use the same direct path through Warden. They do not pass through the LaserData backend.

The tools include these operations:

• Create, replace, and drop projections, definitions that extract events into queryable tables. Bind them to source topics and targets.
• Query a projection with the structured JSON query language. It supports filters, sorting, paging, aggregation, and vector search rather than SQL input.
• Register and drop writer schemas in the schema registry.
• Read and edit namespaced keys and values. An optional TTL sets each key's lifetime.
• Create forks, copy-on-write branches of a read model. Promote a fork onto the trunk or discard it.

The Managed data area appears only when the deployment advertises support. Individual tools appear according to its capabilities.

Task System

Configuration changes, upgrades, and certificate rotation follow the same signed task sequence:

1. A user or automated process requests an action through the Console or API.
2. The control plane creates and signs a task.
3. Warden retrieves the task on its next polling cycle.
4. Warden makes sure that the signature is valid before it runs the task.
5. Warden reports success or failure to the control plane.

Warden rejects invalid signatures. This protects tasks against changes in transit and authenticates their origin at the control plane.

Cluster Readiness and Shared Hosts

Warden follows local Iggy leadership and node readiness. Provisioning waits for a healthy cluster roster before it creates credentials. Source connectors run only on the healthy local leader. If leadership is unknown, they remain disabled with their configuration intact.

Managed data also depends on plane replay, ownership, and backend health. Read readiness and metrics during recovery. A recent heartbeat alone does not prove that a node can serve requests.

Free deployments can share a host with separate runtime processes and CPU quotas. Host metrics and runtime metrics remain separate. The fleet upgrade workflow updates shared-host binaries in place.

Upgrades and Rollbacks

Runtime upgrades can interrupt client connections. Clients must reconnect after an interruption. Warden follows this sequence:

1. A published version becomes available, and Warden receives an upgrade task.
2. Warden downloads the binary and makes sure that its signature is valid.
3. Warden replaces the binary atomically, as one indivisible operation.
4. If the new binary fails to start, Warden restores the previous version.

Warden can upgrade itself without stopping Iggy or Connectors. Those services continue to run during its upgrade. Warden rejects any binary with an invalid signature. Signatures apply to Warden, Iggy, and Connectors binaries.

Credential Scope

Each Warden token grants access to one node. A compromised token remains limited to that node's permissions:

Network Requirements

Management requires outbound HTTPS. It does not require inbound firewall rules, SSH, SSM, or bastion hosts. Application listeners still require the client access described above.