Define work. Run it where files live. Ship it to production.

Jobs, workflows & schedules

• Job types: shell COMMAND, HTTP, NOOP, GIT_RELEASE (download release assets and execute)
• Workflows with ordered steps, conditions, and restart from a failed step
• Cron schedules targeting a job or a workflow
• Search, filter, and paging across catalogs and history

Agents where work runs

• Out-of-process agents claim work from the control plane
• Same agent JAR on Linux and Windows
• Preferred agent pinning for host-specific scripts
• Cancel / kill, retries, and orphan recovery when an agent is lost mid-run

Security & workspaces

• Local users with VIEWER / OPERATOR / ADMIN roles
• OIDC SSO with IdP group → role mapping (Entra ID, Okta, Keycloak)
• Hybrid mode: SSO for people + local break-glass; agents use HTTP Basic
• Personal, group, and platform workspaces — multi-team isolation on one plane
• Audit trail with actor attribution

How agents work

• Pull model — agents open outbound HTTPS to the control plane; the server does not need to dial agent hosts
• Identity by name — register, heartbeat, and claim use a unique agent name
• Hostname is a label — optional display metadata for operators; not used for routing
• Preferred agent on a job pins work to a named agent (the host that has your files)
• Linux & Windows — same agent package; shell via /bin/sh or cmd.exe
• Scale-out — run multiple agent processes for parallel capacity

Full detail: Agents guide (PDF)

Federated agent placement

• Install agents on app servers, batch hosts, jump boxes, or containers next to workloads
• EU / US / LOB teams keep code and secrets on their systems while sharing one control plane
• COMMAND jobs invoke existing start/status/stop scripts already installed on the agent host
• GIT_RELEASE jobs can pull versioned binaries onto the agent and execute them
• Orphan detection marks work when an agent goes offline mid-run; operators cancel or requeue

Supported deployment models

• Docker Compose — PostgreSQL, dual app nodes, dual agents (recommended production starter)
• Kubernetes / AKS — Helm chart for server, agents, optional Postgres
• Bare metal / VM — Java 21 runtime; agent JAR on any JVM host
• Local JAR — single process with embedded H2 for sandbox and demos

Reference architecture

 Operators / UI
        │
        │  HTTPS  ·  REST API  ·  session or SSO
        ▼
  ┌─────────────────────────────────────┐
  │  Control plane (N app nodes)          │
  │  UI · REST · scheduler · RBAC         │
  └───────────────┬─────────────────────┘
                  │ private DB network
                  ▼
            PostgreSQL
         (system of record)

  Agents (Linux / Windows / containers)
        │
        │  HTTPS outbound only
        │  register · heartbeat · claim · complete
        │  authenticated agent API (no direct DB)
        └──────────────────────────────►  Control plane

Agents never connect to the database. They call the control plane over a secured HTTP API (register, claim, complete). Only app nodes talk to PostgreSQL on a private network. Customers typically run dedicated production control planes (and optional pre-production) with agents co-located to each environment’s application estate—so work runs next to the systems it serves. One-page PDFs: deployment architecture · security overview.