Adopt dashboard jobs into IaC

Use steadycron export to round-trip your existing dashboard jobs into a YAML manifest and start managing your account as code.

If you already have jobs in the SteadyCron dashboard, steadycron export exports your entire account state to a YAML manifest. From that point you can commit it to git, review changes in PRs, and apply them with the CLI — without losing any existing jobs.

Step 1 — create an API key

Go to Settings → API keys in the dashboard and create a key. Give it the write scope so the CLI can both read and apply.

Copy the key — you’ll only see it once.

Step 2 — export your account

export STEADYCRON_API_KEY=sc_...
steadycron export --namespace my-app > manifests/my-app.yaml

The --namespace flag assigns all exported resources to this namespace. From here on, apply --prune will only remove resources inside my-app — not jobs you create later via the dashboard (those land in the default namespace).

If you manage multiple environments, export each separately with a different namespace:

steadycron export --namespace production > manifests/production.yaml
steadycron export --namespace staging    > manifests/staging.yaml

Step 3 — review the exported manifest

Open the file. You’ll see:

  • Every job with its schedule, kind, and settings
  • An id field on each resource (auto-assigned if not already present)
  • Secrets replaced with ${VAR_NAME} placeholders — safe to commit as-is
  • Template variables preserved as {{var}} — also safe to commit

Add id values to any resource that is missing one. IDs are how the CLI tracks stable identity. Once you commit, changing an ID is treated as a delete + create.

Step 4 — validate

steadycron validate manifests/my-app.yaml

Fix any reported errors before continuing.

Step 5 — commit

git add manifests/
git commit -m "chore: adopt SteadyCron account into IaC"

Your manifest is now the source of truth. Future changes should go through this file, not the dashboard click-ops.

Step 6 — set up CI

Wire up GitHub Actions to post a plan diff on every PR and apply on merge:

Making changes after adoption

The workflow from here:

  1. Edit manifests/my-app.yaml
  2. Push a branch and open a PR
  3. CI posts the plan diff as a comment
  4. Merge → CI applies the change

To add a new job via the dashboard after adopting: that’s fine. Dashboard-created jobs land in the default namespace and won’t be touched by a namespaced apply --prune. If you later want to bring those jobs under IaC, re-run export for that namespace and merge the output into your manifest.

About --prune

Once you’re managing a namespace with the CLI, use apply --prune in CI. This ensures jobs deleted from the manifest are also deleted from your account — keeping the manifest as the single authoritative record.

Without --prune, sync will create and update but never delete. Jobs removed from the manifest will stay in your account unless you delete them manually.