Skip to main content
By the end of this guide, you’ll have a complete devhelm.yml defining monitors, alert channels, and tags — deployed via the CLI.
  • DevHelm CLI installed (npm install -g devhelm)
  • An API token set as DEVHELM_API_TOKEN
  • A text editor

File format

A devhelm.yml file has a version field and one or more resource sections:

Secret references

Use ${VAR_NAME} syntax to reference environment variables or DevHelm secrets. Secrets are resolved at deploy time — never store credentials in the YAML file.
Set secrets via the CLI or environment variables:

CLI workflow

Validate

Check config syntax offline (no API calls):
Validation runs against the DevHelm JSON Schema. Editors with JSON Schema support (VS Code, JetBrains) provide autocomplete and inline validation.

Plan

Preview what would change without applying:
Plan output shows resources to create, update, and delete. Use -o json for machine-readable output:

Deploy

Apply changes:
Deploy shows the plan and asks for confirmation. Use --yes to skip confirmation (for CI):
Use --dry-run to simulate without applying:
With --detailed-exitcode, dry-run returns exit code 10 when changes are pending (useful for CI gating):

CI/CD integration

GitHub Actions

PR preview

Add a plan step to pull requests to preview changes before merging:

Deploy locking

DevHelm uses deploy locks to prevent concurrent deploys from conflicting. Only one deploy can run at a time per organization. If a deploy is interrupted, you can release the lock:

Drift detection

If someone modifies a resource through the Dashboard while you’re managing it via Monitoring as Code, devhelm plan shows the drift. The next devhelm deploy overwrites the Dashboard changes with the YAML definition — YAML is the source of truth.

Next steps

YAML file format

Full schema reference for devhelm.yml.

CI/CD pipeline guide

Set up automated deploys from GitHub Actions.

Terraform provider

Alternative: manage monitors with Terraform.

Deploy workflow

Deep dive into validate → plan → deploy.