DEV Community

Nikita Navral
Nikita Navral

Posted on

Stop Clicking Through a Dashboard to Deploy Notification Changes

#automation #devops #git #softwaredevelopment

Think about how you ship a normal change at work:

  1. Branch.
  2. Pull request.
  3. Review.
  4. CI runs.
  5. Deploy.
  6. If it breaks, git revert.

Now think about how a notification change ships: someone logs into a dashboard, edits a template, clicks save, and hopes staging and production still match.

Same company, same engineers, completely different standards. We wanted to close that gap, so this post is about treating notification assets like what they are: config that belongs in your repo.

The problem with dashboard-only notifications

When templates, workflows and preferences live only in a UI, a few things quietly go wrong:

  • The source of truth isn't in your repo. The real version lives somewhere else, and nobody can git blame it.
  • Environments drift. Staging and production slowly stop matching, and nobody notices until a send goes wrong.
  • There's no review trail. Who changed that subject line, and why? You find out by asking around.
  • Production access gets handed out widely. If the only way to ship a change is the production dashboard, many people need access to it.

None of this is a notification-specific problem. It's what happens to any config that lives outside version control.

What "notifications as code" looks like

The idea is simple: pull your notification assets down as local files, manage them like the rest of your code, and push them back through a pipeline.

With the SuprSend CLI, every core asset can be handled from the terminal: workflows, templates, schemas, events, preference categories and translations. Each one can be listed, pulled to local files, edited, pushed back, committed from draft to live, and synced between workspaces. You can also activate or deactivate a workflow straight from the shell, which is handy for shipping a new one, or for pulling a misbehaving one offline during an incident.

Install (macOS or Linux):

brew install --cask suprsend/tap/suprsend
Enter fullscreen mode Exit fullscreen mode

Authenticate with a service token, and you're ready to run commands next to the rest of your engineering work. (On Windows or in CI, grab the binary from GitHub Releases, or build from source.)

Three things this unlocks

1. Edit in your own editor

Pulling an asset writes it to your project directory as readable JSON. You edit it in your IDE with your usual linting, syntax highlighting and AI completions, then push it back. Pushes are validated against SuprSend schemas before anything is saved, so a malformed file is rejected before it reaches your workspace.

2. Git becomes your notification changelog

Once assets are files, they get everything Git gives you for free:

  • Commits show who changed what
  • Diffs show exactly what changed
  • A revert undoes a bad change in seconds

Your Git log becomes your notification change history, with no separate doc to keep updated.

3. Deploy through CI like any other change

Every CLI command is scriptable, so GitHub Actions, CircleCI or any other pipeline can run pulls, pushes and syncs as deploy steps.

Here's an illustrative GitHub Actions job that promotes assets from staging to production when a PR merges to main:

name: promote-notifications
on:
  push:
    branches: [main]

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Install the CLI (see the docs for the binary / Homebrew options in CI)
      # Authenticate with your service token stored as a CI secret
      - name: Promote staging to production
        run: suprsend sync --from staging --to production
Enter fullscreen mode Exit fullscreen mode

This is a sketch to show the shape of the workflow. Check the CLI docs for the exact install and auth steps in your CI environment.

The result: notification changes ship on the same cadence as your application code.

Environment promotion without production access

This one is a security win. Moving tested assets from staging to production is a single command:

suprsend sync --from staging --to production
Enter fullscreen mode Exit fullscreen mode

Because the pipeline does the promotion, nobody needs UI access to the production workspace to ship a change. Production access stays locked down, and changes only flow through reviewed pull requests.

Type-safe payloads (fail in your IDE, not in prod)

Here's the part developers tend to like most. You can generate native type definitions from your SuprSend schemas and drop them into your SDK:

suprsend schema generate-types --schema order-confirmation --output ./types
Enter fullscreen mode Exit fullscreen mode

Now a wrong payload key fails in your IDE, then in CI, then in your build, before any send is attempted. Instead of discovering a bad key at runtime when a user doesn't get their order confirmation, the schema becomes a guardrail at compile time.

Other handy use cases

  • Bootstrapping a new workspace: provision templates from a script instead of rebuilding them one by one in the UI.
  • Migrating from another tool or an internal codebase: recreate templates programmatically instead of by hand in the dashboard.
  • Incident response: deactivate a misbehaving workflow from your terminal in seconds.

Open source, and verifiable

The CLI is open source and free to use. You can install via Homebrew, download the binary from GitHub Releases, or build from source. If you're in a security-sensitive environment, you can verify the binary signature with Cosign before installing it.

Try it

Quick disclosure: we work on SuprSend, so we're obviously biased. But the underlying idea holds with any tool: if something affects what your users see, it deserves a pull request.

Your turn: how do you manage notification templates today? Dashboard only, Git, or a mix? And what's the worst "someone edited a template in prod" story you've seen? Tell us in the comments.

Top comments (0)