stack as code

A single YAML file declares your org's monitors, channels, and rules. pngr apply -f stack.yaml reconciles the org to match the file: it diffs the current state, prints the changeset, and — on confirm — creates, updates, and deletes through the same REST API the web UI uses.

It's a first-class surface, not a bolt-on. Most uptime tools ship a Terraform provider as an add-on; pngr ships a native YAML format that covers monitors, channels, and rules together, applied by a CLI that drops straight into any CI pipeline.

why use it

Review infrastructure in PRs. Your monitoring config lives in git next to the service it watches.
Reproducible environments. The same file brings up staging and prod monitoring identically.
Round-trips cleanly. pngr dump exports the live org as a stack file that apply accepts back unchanged — so you can adopt it incrementally from an org you built in the UI.

the shape

apiVersion: pngr.dev/v1
kind: Stack
metadata:
  org: acme
spec:
  channels:  [ ... ]
  monitors:  [ ... ]
  rules:     [ ... ]

The full schema, field conventions, and a complete example are in the stack file.

the workflow

dump the current org, or hand-write the file from scratch.
diff to preview what apply would change.
apply to reconcile — review the kubectl-style changeset, then confirm.

note

Additive by default. apply never deletes a resource just because it's missing from the file. Pruning is strictly opt-in via --prune — an accidental apply -f wrong-file.yaml can't wipe your monitors. See apply, diff & prune.

where you can run it

surface	how
CLI	`pngr apply` / `pngr dump` / `pngr diff` — see the pngr cli
the `/stack` page	a browser editor: view the org as generated YAML, paste/edit, preview the diff, and apply — reachable from the sidebar
MCP	`stack_dump` and `stack_apply` tools, so an agent can edit the whole stack as one artifact — see mcp server

Each list page's empty state also carries an or define your fleet in yaml → link to /stack, so the GitOps path is discoverable without cluttering existing workflows.

roles

apply is admin/owner only — members and viewers get a 403. dump is readable by any member. Every successful apply writes one audit entry per changed resource plus a batch entry with the file checksum and actor, and the audit log has a "stack applies" filter preset.

previousalerting & escalation nextthe stack file