Templates

Your email templates deserve the same workflow as your code

SES templates are powerful — but managing them means editing raw HTML in the AWS console, hoping nobody overwrites your changes, and deploying with scripts you wrote two years ago. SendOps gives your templates a proper home: a Git repository, pull requests, previews, and automatic deployment to SES on merge.

Get Started See how it works

The problem

Templates are the easiest thing to break and the hardest thing to fix quickly

A broken email template doesn't throw an error in your application. It throws an error in your customer's inbox. A missing variable, a malformed link, a layout that renders as a wall of code — and it goes out to everyone on the list before anyone notices.

SES templates live in the AWS console. You can edit them there, one at a time, with no version history, no review process, and no way to preview with real data. If marketing needs a copy change, they file a ticket. Engineering makes the edit in the console, hopes the HTML is right, and deploys it live. There's no staging. There's no diff. There's no rollback button.

Most teams solve this by building their own deployment pipeline — a script that reads templates from a folder and pushes them to SES via the API. It works until someone forgets to run it, or runs it from the wrong branch, or the script breaks and nobody notices for a week.

Manual SES console edits needed

From merge to live in SES

Of template changes tracked in Git history

Deployment scripts to maintain

How it works

Templates go through the same workflow as your code

A developer or marketer edits a template file in the repository. The file is standard HTML with Handlebars-style variables — the same format SES uses natively.

templates/order-confirmation.html

@@ -12,5 +12,5 @@

12-Hi {{first_name}},

12+Hi {{name}},

13 Order #{{order_id}} confirmed

14-<a href="{{link}}">Track order</a>

14+<a href="{{tracking_url}}">Track your order</a>

Every template change is a pull request. Every pull request gets validated, previewed, and reviewed before it goes live. If something breaks, you roll back with a Git revert — not by hoping you remember what the template looked like yesterday.

It works in the other direction too. Edits made in the SendOps dashboard stay drafts until you explicitly publish — and publishing opens a pull request back to your repo. Marketers propose changes without an IDE, engineers still review, and git stays the source of truth. Once merged, templates feed broadcasts and workflows directly.

Before and after

What changes when templates live in Git

Today

Edit templates in the AWS console, one at a time
No version history — if you break a template, you rewrite it from memory
No review process — changes go live the moment you click save
No preview — you send a test email and check your inbox
Marketing files a ticket for every copy change
Custom deployment scripts that someone has to maintain and remember to run

With SendOps

Edit templates in your IDE, in a repository your whole team can access
Full Git history — every change is tracked, every version is recoverable
Pull request workflow — changes are reviewed, validated, and previewed before they reach production
Rendered preview with sample data, desktop and mobile, right in the PR
Marketing edits in the dashboard, no IDE required — SendOps opens the PR, engineering reviews, not rewrites
Automatic sync to SES on merge — no scripts, no manual steps

Validation

Catch problems before they reach an inbox

Every template goes through automated checks before it can be deployed.

Syntax validation

Author in React Email (TSX) or plain Handlebars — SendOps validates every change at PR time. Broken markup, bad props, and invalid expressions are caught before the email goes out, not after.

Variable verification

SendOps checks that every variable used in the template is defined in the template's schema. No more {{undefined}} showing up in customer emails.

Rendering preview

See the template rendered with sample data. Desktop and mobile layouts, light and dark email clients. If it looks wrong, you see it before your customers do.

Deployment safety

Templates only deploy to SES when a PR is merged to your main branch. No one can accidentally push a half-finished template by running a script from the wrong directory.

Assets

Images on your own domain

Templates need images — logos, product shots, headers. SendOps gives them a home: an asset library, served from an Edge CDN on your own custom domain, with certificates provisioned per organisation. Assets are content-addressed, so the URL in an email you sent last year still points at exactly the image it pointed at then.

Images referenced from templates in your repo are picked up automatically — commit the file, and it's on the CDN. And because everything serves from your domain, your marketing email doesn't reference third-party image domains.

One workflow that works for everyone

Template management is a cross-team problem. The current process — tickets, console edits, deployment scripts — fails because it forces every change through engineering. SendOps gives each team the access they need without giving up the controls engineering requires.

For Developers

Templates are files in a repository. Edit them in your IDE, commit, push, open a PR. Validation runs automatically. Deployment happens on merge. No console, no scripts, no manual steps — just the workflow you already use for everything else.

For Marketing

Change copy, update links, adjust layouts — and open a pull request. See a rendered preview of exactly what the email will look like. No more filing tickets for a one-line copy change and waiting three days for engineering to get to it.

For Operations

Every template change is tracked in Git. You know who changed what, when, and why. If a template breaks, you revert the commit. Deployments are automatic and auditable — no more wondering which version of a template is live in SES.

Template format

Author in React Email. Ship native Handlebars.

Write templates as React Email components — the open standard for email as code — and SendOps' converters compile them to the Handlebars templates SES runs natively. What lands in SES is a plain SES template: no runtime dependency on SendOps, React, or anything else. Prefer to write raw Handlebars? That works too.

Author in React Email (TSX) — the same open standard used across the industry
Custom converters compile your components to SES-native Handlebars at deploy
What runs in SES is a plain SES template — no runtime dependency on SendOps

Full authoring reference: React Email in the SendOps docs — components, escaping and strict-render rules, and the CI render-to-Handlebars step.

emails/order-confirmation.tsx

// emails/order-confirmation.tsx
import { Html, Body, Heading, Text, Link, Section, Row, Column } from "@react-email/components"

type Props = {
  name: string
  orderId: string
  items: { name: string; quantity: number; price: string }[]
  trackingUrl: string
}

export default function OrderConfirmation({ name, orderId, items, trackingUrl }: Props) {
  return (
    <Html>
      <Body>
        <Heading>Order confirmed</Heading>
        <Text>Hi {name}, your order #{orderId} is confirmed.</Text>
        <Section>
          {items.map((item) => (
            <Row key={item.name}>
              <Column>{item.name}</Column>
              <Column>{item.quantity}</Column>
              <Column>{item.price}</Column>
            </Row>
          ))}
        </Section>
        <Link href={trackingUrl}>Track your order</Link>
      </Body>
    </Html>
  )
}

Stop editing templates in the AWS console

Get Started View Pricing

Free plan available. Connects to your SES account in two minutes.