05 · Runtime and execution
Place each run on an eligible, isolated execution target.
NopsAI separates the control plane from the data plane. Durable state stays in the platform while transient work executes in agent containers, step containers, pods, volumes or PVC workspaces.
How it works
Runtime and execution, end to end.
The flow stays explicit enough for operators to inspect, secure, automate and improve.
Create durable run state
The control plane validates and stores the resolved request before asking the dispatcher for execution.
Select an eligible runner
The dispatcher filters connected runners by scope registration, routing rules, capacity, affinity, availability and runtime pool.
Launch an isolated agent
A Docker container or Kubernetes pod receives the bounded job context and owns orchestration for that run.
Stream state home
Agents and runners send logs, task transitions, completion state and diagnostics through authenticated service callbacks.
Platform capabilities
What teams can standardize.
These are current NopsAI platform primitives, not a future-state feature list.
Docker execution
Use long-lived Docker runners to create one agent container and shared workspace volume for each run.
Kubernetes execution
Use namespace-scoped runners to create agent pods, step pods and agent-owned ephemeral PVC workspaces.
Routing and capacity
Constrain runner IDs per scope and account for runner capacity before dispatch.
Lifecycle control
Support cancellation, timeouts, approval suspension, resumed execution and durable status reporting.
Configuration
Declared once, reviewed like code.
The example is declarative and Git-reviewable. Runtime behavior still passes through live AAA, credential, compatibility, execution and monitoring boundaries.
runner_id: k8s-runner-ams-1
runner_scopes: staging,prod
runner_capacity: 30
runtime: kubernetes
kubernetes:
namespace: nopsai-runs
service_account: nopsai-runner
default_workspace_size: 5Gi
default_run_timeout: 2h
storage_class: fast-rwo
affinity_enabled: true
dispatcher_routing:
prod:
- k8s-runner-ams-1
"*":
- runner-general
runtime_pools:
default:
node_selector:
workload: nopsaiEnterprise controls
Configuration stays inside the governance model.
Service-authenticated callbacks
Dispatcher, runner and agent updates use internal service identity and protected endpoints.
Scoped resource resolution
Variables, secrets and runtime targets are authorized and resolved before the job reaches a runner.
Transient workspaces
Containers, volumes, pods and PVCs hold execution state while Postgres retains the durable run record.
Runner diagnostics
Connectivity, capacity, history, system logs and platform doctor checks support operational readiness.
Related capabilities
Continue through the operating model.
06 · Evidence and monitoring
Connect run history, system logs, outputs, AI usage, reliability, security, cost, alerts and recommendations.
01 · Workflow orchestration
Combine scripts, LLM goals, approvals, reusable steps and child pipelines without splitting the operating model.
02 · GitOps configuration
Manage pipelines, scopes, access, knowledge, profiles, triggers and runtime defaults as versioned configuration.
Bring a real runtime and execution workflow.
We can map the configuration, authorization, runtime and evidence boundaries against your current platform model.