Resource manager

The inventory

Resources in the sidebar lists what each agent reports, grouped by kind. Kubernetes covers workloads, config, network, storage and cluster objects (Deployments, Services, ConfigMaps, Secrets, Ingresses, …); Docker covers Containers, Images, Volumes, Networks and — on a swarm manager — Services, Nodes and Stacks. Open any item for its details, raw object, logs (where available) and its task history. The Docker Services list shows each service's image and replica count (running / desired) in place of a namespace.

Create & edit (apply)

Form-driven kinds have a New button and (Kubernetes) an Edit button. You fill in fields; Subnomic builds the manifest / spec and sends it as an apply task. Apply is idempotent — re-applying the same name updates the existing object rather than failing:

• Kubernetes — a server-side apply, so it creates or updates the live object and reconciles only the fields the form owns.
• Docker service — updated in place (rolling) when it already exists, else created.
• Docker container — recreated with the new spec when the name already exists (brief downtime; the new image is pulled first so a bad reference never destroys the running container).

Update just the image

To roll out a new image without touching anything else, open the resource and use Update image (or schedule it — see Scheduled tasks). It operates on the live object, so it always applies to whatever is running:

• Kubernetes (Deployment / StatefulSet / DaemonSet / ReplicaSet) — patches one named container's image and waits for the rollout. Pick the container from the dropdown; the current image is prefilled so you only change the tag.
• Docker service — swaps the image on the live service spec and lets swarm roll the tasks (no downtime).
• Docker container — pulls the new image, then recreates the container with the same config, name, volumes and networks (brief downtime; its id changes).

Lifecycle actions

Per-kind buttons dispatch a task to the agent: restart, scale to N replicas (workloads / swarm services), start / stop (Docker containers), update image, and delete in cluster. The Schedule button pre-fills a scheduled task for the same resource + action.

History & rollback — Infra Time Machine

Open a Kubernetes resource's manifest (the YAML tab on its detail page) and Subnomic keeps a history of its distinct configurations — the Infra Time Machine. A snapshot is recorded whenever the live manifest is viewed or a change is applied and it differs from the last one, so the snapshots form a timeline (the most recent are kept).

• History — the snapshot timeline, with who recorded each and when.
• Diff — pick a snapshot to see a side-by-side diff against the current manifest, so you can see exactly what drifted.
• Rollback — restore a snapshot; it's re-applied through the same governed kubernetes.apply task as a manual edit (guardrails + approval), attributed to you.

Private registries

When an image lives in a private registry:

• Docker — the agent reuses the docker host's own credentials (a prior docker login, i.e. ~/.docker/config.json and any credential helper). No extra setup: if the host can pull it, so can the agent.
• Kubernetes — create a registry secret (Secret → type kubernetes.io/dockerconfigjson): just fill in the registry server, username and password and Subnomic builds the credential for you. Then reference it from a workload's Image pull secrets field (below).

Attaching secrets & config to workloads

Deployment / StatefulSet / CronJob forms can wire Secrets and ConfigMaps into the pod, every way Kubernetes supports:

• Image pull secrets — names of registry secrets used to pull private images.
• Env from secrets / configmaps — inject every key of a Secret / ConfigMap as environment variables (envFrom).
• Env from a single key — one variable from one key, written as VAR → secret:key (or configmap:key).
• File mounts — mount a Secret / ConfigMap as files at a path (name → /path), read-only. Other volumes you manage outside the form (e.g. a PVC) are preserved on edit.

Guardrails & audit

Every mutating action (apply, update image, scale, restart, start / stop, delete) is gated by guardrails (target type kube / docker) and written to the activity log. A denied action is blocked before it reaches the agent; an action that requires approval is blocked too (a fire-and-forget task can't be approved interactively). See Guardrails.

Permissions

resource.read browses the inventory; task.create runs create / edit / lifecycle actions (they execute as tasks). Whether an action actually succeeds also depends on the agent's own rights — its Kubernetes ServiceAccount RBAC, or its access to the Docker daemon.