Foundation for Emails: responsive HTML email with the Inky templating layer

The problem Foundation for Emails is built around

HTML email is not web HTML. Outlook and a long tail of clients do not render the same box model that a modern browser does, so layouts that work in a browser often collapse in an inbox. Foundation for Emails addresses that by shipping a set of HTML and CSS components that the project says have been tested across every major email client for consistency, plus a Sass codebase you compile yourself rather than a stylesheet you link at send time.

The audience is narrow on purpose. This is for developers who already have a build step and want the final email HTML as a file they can inspect, diff and version. It is not for someone who wants to drag blocks around in a browser. The repository layout reflects that: scss/ holds the source styles, dist/ holds the compiled CSS and the minified build, templates/ holds page scaffolding, and gulpfile.js drives the whole thing. The package.json exposes three scripts, start, test and dist, and points style at dist/foundation-emails.min.css and main at dist/foundation-emails.css.

How Inky turns custom tags into email tables

The mechanism most people come for is Inky. The README describes it as a templating language that converts simple HTML into the complex tables required for email layout, and says the parser converts a set of custom HTML tags and expands them out into full HTML syntax. So you write a container, a row and columns, and the parser emits the nested table structure clients expect.

The README lists every custom element. The grid uses container, row, column, with responsive attributes such as small="12" and large="4". The block grid uses block-grid with an up attribute. Components include button with an href, and menu with nested item elements that each take an href. That is the whole vocabulary the README documents, and it is worth noting how small it is. There is no documented accordion, no documented dark-mode helper, no documented conditional-comment utility. If your design needs something outside that list, you are back to writing raw table HTML inside the Inky document, which is exactly the work Inky was meant to remove.

The conversion happens during the build, not at send time. The template stack handles it, and the same parser is available in the Ruby ecosystem through the inky-rb gem, which the README says bundles foundation_emails by default.

Installing the template stack and building a first email

The README names the email template stack as the main way to get started, and it is a separate repository: foundation/foundation-emails-template. The stated requirement is Node.js no greater than version 10, which is the single most important constraint on this page. The README points to nvm for managing that version. Clone the template, move into it, install Node 10 with nvm, and install dependencies:

git clone https://github.com/foundation/foundation-emails-template project
cd project
nvm install 10
nvm use 10
npm install

After that, npm start runs the project. The README says a new browser window opens with a BrowserSync server showing the finished files, so you edit a source file and the browser reloads with the compiled, inlined output. When you want the production artifact rather than the live preview, run the full inlining pass:

npm run build

Both scripts come from the template stack, not from the framework repository itself. The framework repository has its own scripts, and they do different work: npm start runs gulp to compile the documentation, npm run test:visual compiles the visual regression pages, and npm run dist produces the distributable build. If you clone foundation-emails instead of the template, you are building the framework and its docs, not an email.

For a Rails application the path is different and shorter. Add the gem to your Gemfile:

gem 'foundation_emails'

Then run bundle install, and import the framework in the stylesheet used by your mailers:

// app/assets/stylesheets/your_emails_stylesheet.scss

@import "foundation-emails";

The README notes that adding Inky's templating to Rails is handled by the inky-rb gem, which bundles foundation_emails, so a Rails team that wants both the styles and the custom tags installs inky-rb rather than wiring the two together.

The Node.js 10 requirement is the real adoption cost

The README states plainly that the template stack needs Node.js no greater than version 10. Node 10 is long past its end of life, so on a current workstation you are installing an old runtime through nvm and switching to it for this project only. That is workable, and nvm makes it a one-line switch, but it means the email build cannot share a runtime with the rest of a modern front end without care.

The framework repository itself is a different story. Its package.json lists devDependencies that include gulp 4, sass 1.98, gulp-sass 5, postcss and a set of gulp plugins, and the repository carries an .nvmrc file. The README does not state a Node version for building the framework or its documentation, so if you are compiling Foundation for Emails from source rather than using the template stack, the README is silent on which runtime that build expects. The .nvmrc in the repository is the file to read for that, not the README.

A second limitation is the scope of the components. Because the documented Inky element list stops at grid, block grid, button and menu, anything more ambitious is hand-written HTML. Teams that expect a broad component library from a framework with this name will find the surface smaller than they assumed.

Testing email output, and where Litmus fits

The repository treats visual regression as part of the workflow rather than an afterthought. Running npm run test:visual compiles the pages under test/visual/pages, and per the README those pages are compiled and inlined. From there they can be uploaded to Litmus for testing across clients.

That is an honest division of labour. The framework produces the inlined HTML; Litmus renders it in real clients and shows you screenshots. Foundation for Emails does not claim to render your email itself, and nothing in the repository suggests it does. The practical consequence is that your confidence in a template depends on how many of those visual pages you actually cover with your own markup. The default set is a starting point, not a guarantee about your specific design.

This also explains why the project leans on inlining at all. Inlining moves your compiled CSS onto the elements, which is what most clients require, and it is the step npm run build performs in the template stack. Skip it and you are shipping a stylesheet that a large share of inboxes will ignore.

Foundation for Emails compared with MJML and React Email

MJML solves the same core problem with a different shape. It is a markup language with its own compiler, and you write MJML rather than HTML with custom tags. The practical difference is that Inky documents are HTML documents: the parser expands custom tags in place, so you can drop raw table markup into the middle of an Inky file when a component does not exist. With MJML you are inside its language, and the escape hatch is a raw-HTML component rather than simply writing HTML. Foundation for Emails also gives you the Sass layer directly, which matters if your team already maintains a design system in Sass and wants the email styles to sit beside it.

React Email takes a third approach: you compose emails as React components and render them to HTML. That fits a codebase already written in React, and it means your email templates get the same tooling as the rest of the app. It does not give you a Sass framework, and it does not give you the Inky tag vocabulary. If your team writes Rails or plain Node without React, the React component model is an extra concept rather than a saving.

The honest summary is that the three differ mainly in what you write. Inky plus Foundation for Emails means HTML with a small set of custom tags and a compiled Sass stylesheet. MJML means a dedicated markup language. React Email means components in JavaScript or TypeScript.

Maintenance, licensing and the move to Inky v2

The repository is not archived. The last push was on 2026-03-13, and the most recent release is 2.5.1 from 2026-03-12, following 2.5.0 the day before. Those two releases come after a long gap: the previous release listed is v2.4.0 from 2022-03-22. So the project received a burst of maintenance in March 2026 after roughly four years without a tagged release.

The README is explicit about where new work is going. It states that Foundation for Emails will merge into the Inky project starting with Inky v2.0, that the styling portion will live on as Inky Styles within the Inky repository, and that the Inky templating engine is being rewritten in Rust with bindings for JavaScript via WASM, PHP, Python, Ruby and Go. It also states that this repository will continue to receive maintenance updates while new feature development happens in Inky v2. Read that as a maintenance mode with a stated successor rather than an abandoned project, but do not plan a roadmap that depends on new components landing here.

Licensing is MIT, per the LICENSE.md file in the repository root. That is permissive and imposes no source-disclosure obligation on your emails or your application. This is a description of the licence text, not legal advice; if your organisation has rules about attribution or about bundling third-party assets, have someone read LICENSE.md rather than taking this paragraph as clearance.

Editorial conclusion

Adopt Foundation for Emails if you want the generated table markup in your own repository and you can pin Node.js 10 for the template stack, or if you are on Rails and want the foundation_emails gem plus inky-rb. Do not adopt it if you need a component library that is still gaining features: the README states that new feature development is moving to Inky v2, with the styling portion continuing as Inky Styles. Before committing, verify three things: that your toolchain can run the Gulp build from package.json, that your email client matrix is covered by the visual pages under test/visual/pages you upload to Litmus, and whether you need the Ruby path at all, since the gem only ships assets and stylesheets.

Frequently asked questions

Official sources

1. foundation/foundation-emails on GitHub
2. License: MIT
3. Project website
4. README
5. Releases