Cerberus: three templates against the email client wilderness

A few patterns, annotated, against a hostile platform

Cerberus frames the problem plainly: coding regular emails is hard enough by itself, and making them responsive and accessible should not add to the headache. Its answer is a few simple, but solid patterns that optimize emails for small screens and assistive technologies, and its form factor is the interesting part. This is not a framework or a service but a small set of HTML files whose code blocks are compartmentalized so they can be used, combined and nested to build an email. Every template is annotated, meaning the comments explain what each block survives, and the project claims good support among popular email clients, with Outlook and Gmail named in the description as the benchmark. The audience is the developer who hand-writes emails and wants prior art rather than abstraction.

Fluid, responsive, hybrid: three bets on client behavior

The three templates embody three strategies for the same uncertainty. cerberus-fluid.html is for simple layouts, transactional and single-column emails, where a fluid width is enough and nothing needs to transform. cerberus-responsive.html targets more complicated, shape-shifting layouts that work on some mobile clients, the phrase doing quiet work: media query support in email clients is partial, so responsive behavior is a bet on the client. cerberus-hybrid.html is the hedge, reconfiguring the layout for different screen sizes regardless of media query support, the approach that earned hybrid its reputation as the Outlook answer. Choosing among them is a judgment about the audience's client mix, and because the blocks are compartmentalized, the strategies can be mixed within one email rather than chosen once per project.

Release notes as an email client bug log

The version history reads like a compatibility diary. Version 3.3.0, from 2019-08-15, was light refactors and iOS Outlook fixes. Version 3.4, on 2022-02-12, added dark mode support and an updated documentation site, acknowledging that email clients now render two appearance modes. Version 3.4.1, on 2022-03-19, fixed an Outlook border issue, one month later. The cadence tells the story of the genre: releases are event-driven, triggered when a client changes behavior, and long gaps mean stable clients rather than an abandoned project. That reading is confirmed by activity after the last release, with the repository pushed as recently as 2026-09-14, four years of quiet maintenance beyond the newest tag.

A maintainer handoff visible in the metadata

The project's continuity is written into its own files, if you read them side by side. The package.json still names Ted Goas as author, points its repository and issues URLs at TedGoas/Cerberus, lists a homepage on tedgoas.github.io and carries version 3.3.0, while the README's copyright line says Jordie van Rijn, the repository now lives under the emailmonday organization, and the documentation site has moved to cerberusemail.com. Together those artifacts document a stewardship transfer, the original author's repository adopted and continued by another maintainer, without the metadata being rewritten to pretend otherwise. An archived-versions directory keeps the older iterations available, which for email work matters more than usual, since a template that shipped years ago still needs to be diffable against its descendants.

Accessibility sits in the pitch, not a footnote

The README's first paragraph puts small screens and assistive technologies in the same sentence, which is rarer than it should be in email tooling. The patterns are built to optimize for both, and the annotations carry that intent into the code, since accessibility in email lives in details like semantic structure, alt text discipline and reading order that a developer needs to see explained in place. There is no accessibility checklist document or audit badge, just the claim embedded in what the templates demonstrate, which fits the project's whole posture: read the HTML, learn the pattern, keep the habit. The license is MIT, introduced in the README with a shrug toward simplicity and permissiveness, letting the patterns be absorbed into any product's email pipeline without obligations beyond attribution.

Bower.json in 2026, and other fossils that tell the truth

The repository's archaeology is honest about its age. bower.json sits at the root, a manifest for a package manager long retired from mainstream use, and package.json is metadata only, no scripts, no build, no bin, because Cerberus was never something you install and invoke. The deliverables are the three HTML files, meant to be opened, read and copied. This is the project's actual distribution model: the file is the package. For a modern build pipeline that means integration is a copy step or a vendored file with your own diffs, and updates arrive by re-reading the annotated source rather than by bumping a dependency version, a workflow that suits hand-maintained email templates better than it would library code.

Patterns to read versus frameworks to compile

Cerberus occupies a specific corner of the email tooling landscape, and the neighbors clarify it. MJML is a markup language that compiles down to email-safe HTML, and Foundation for Emails is a framework with its own build chain; both buy component abstraction and pay for it with tooling every developer on the project must adopt. Cerberus is the opposite trade: plain HTML with comments, nothing to install, nothing to compile, and a learning curve that consists of reading well-annotated code. Teams with many templates and a dedicated email build process often end up happier compiled, while teams with a handful of hand-tended transactional emails usually find that three annotated files and copy-paste outlast any toolchain. The project's decade of relevance suggests the second group is larger than the tooling industry assumes.

Editorial conclusion

Use Cerberus when you write transactional or newsletter emails by hand and want battle-tested, commented HTML you can copy and nest without adopting a build chain. Choose MJML or Foundation for Emails when you prefer compiling a component syntax into email HTML and accept the tooling that implies. Verify first which of the three templates matches your audience, hybrid being the safe pick where Outlook dominates, and check the annotations in the actual files rather than the site, since the repository is the source that still receives pushes.

Frequently asked questions

Official sources

1. emailmonday/Cerberus on GitHub
2. License: MIT
3. Project website
4. README
5. Releases