Skip to main content
By the end of this guide, you’ll have exported your existing Dashboard-managed resources to YAML and transitioned to a code-managed workflow with no disruption to your monitoring.
  • DevHelm CLI installed
  • An API token — see Authentication
  • Existing monitors created through the Dashboard

​
Migration strategy

The goal is to transition from “click-to-create” to “commit-to-deploy” without any monitoring gaps. The process:
  1. Export your current state to YAML
  2. Validate the export matches what’s running
  3. Commit the YAML to your repository
  4. Let future changes go through code instead of the Dashboard

​
Step-by-step migration

1

Export current monitors

List all your monitors and capture their configuration:
devhelm monitors list -o json > current-monitors.json
Convert to YAML format:
devhelm export -o devhelm.yml
The export command generates a devhelm.yml from your current organization state including monitors, alert channels, tags, and notification policies.
2

Review the exported YAML

Open devhelm.yml and review:
  • Monitor names and URLs are correct
  • Frequencies and regions match expectations
  • Alert channel types are right (webhook URLs will be placeholders for security)
  • Tags are present
Replace any placeholder secret values with ${VAR} references:
alert-channels:
  - name: Engineering Slack
    type: SLACK
    config:
      webhookUrl: ${SLACK_WEBHOOK_URL}  # Replace placeholder
Set the secrets:
devhelm secrets set SLACK_WEBHOOK_URL=https://hooks.slack.com/services/...
3

Validate and plan

Check that the YAML is syntactically valid:
devhelm validate devhelm.yml
Preview what would change:
devhelm plan -f devhelm.yml
Since you exported from the current state, the plan should show no changes (or minimal differences from secret handling). If you see unexpected creates or deletes, review the YAML against the Dashboard.
4

Deploy

Apply the YAML to take ownership:
devhelm deploy -f devhelm.yml --yes
This makes DevHelm’s config-as-code system the source of truth. Dashboard changes will now show as drift in devhelm plan.
5

Commit to your repository

git add devhelm.yml
git commit -m "chore: import monitoring config from Dashboard"
git push
6

Set up CI/CD

Add a GitHub Actions workflow to deploy on push. See CI/CD pipeline guide.

​
Handling drift

After migration, if someone edits a resource through the Dashboard: 
devhelm plan -f devhelm.yml
The plan shows the drift. The next devhelm deploy overwrites the Dashboard changes with the YAML definition. Make this expectation clear to your team: YAML is the source of truth.

​
Incremental migration

You don’t have to migrate everything at once. Start with a subset:
  1. Export only your critical production monitors
  2. Deploy and validate
  3. Gradually add more resources to the YAML
  4. Eventually export alert channels and notification policies too
Resources not in the YAML file are left untouched — DevHelm only manages resources declared in the file.

​
Next steps

Monitoring as Code tutorial

Full YAML format and workflow guide.

Multi-environment config

Manage staging and production separately.

CI/CD pipeline

Automate deploys from GitHub Actions.