# Inky v2: a Rust email framework with templates, inlining and a CLI

> Inky is a rewritten email framework that turns simple component markup into responsive, table-based email HTML, and it now ships as a Rust binary, a WASM module, a native shared library and bindings for five languages. It is still on a 2.0 beta line, which matters if you plan to depend on it.

**foundation/inky** — An email framework that converts simple HTML into responsive email-ready HTML.

- Repository: https://github.com/foundation/inky
- Website: https://foundationcss.com/inky/
- Stars: 708 · Forks: 104
- Language: Rust
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/foundation-inky

## A compile step for email, with the framework hiding the tables

Inky takes a piece of simple HTML and turns it into email-ready HTML, and the example in the README makes the transformation concrete. The input is a container element holding a row with two columns marked with an lg attribute, and the output is nested presentation tables with role attributes, tbody wrappers and class names such as small-12 large-6 columns first. That output is what email clients can actually render. The point of the tool is that nobody writes those tables by hand, and that the same transformation runs in every language binding, producing byte-identical output to the CLI. The audience is email developers and the teams who own their templates, and the earlier branding, Foundation for Emails, is folded into the Inky name starting with v2, so anyone arriving from the old project should read the migration material rather than the old docs.

## Four ways to consume it, one pipeline underneath

The v2 rewrite changed the shape of the project more than the shape of the output. It is now written in Rust and distributed as four artefacts, and the README is explicit that the full build pipeline, meaning layouts, includes, data merge, framework CSS, component transform and CSS inlining, is not CLI-only but available in-process to PHP, Python, Ruby and Go through build() and Build() calls. The Cargo workspace lists the four crates: inky-core as the core transformation engine producing a Rust library, inky-cli producing the inky binary, inky-wasm producing the .wasm module published on npm as inky, and inky-ffi producing the .so, .dylib or .dll shared library behind the PHP, Python, Ruby and Go bindings. Node.js is served by the WASM build. That is the reason to care about the rewrite: the same engine is now reachable from every stack a mail team might use, without a service to deploy.

## The CLI covers scaffolding, building, watching and preview

The command line is the fastest way to see the tool work. Installation has three documented routes, and the README shows them as alternatives:

```bash
# Homebrew
brew install foundation/inky/inky

# Cargo
cargo install inky-cli

# npm (WASM)
npm install inky
```

The first-run workflow is a scaffold, a build and a watch loop:

```bash
# Scaffold a new project
inky init my-email
cd my-email

# Build
inky build

# Watch for changes
inky watch
```

There is also inky serve, which starts a local development server with auto-reload, and inky migrate, which converts v1 syntax to v2 automatically. For a team moving from the old JavaScript-era Inky, that migration command is the shortest path, and the existence of a per-language example repository for Node.js, PHP, Python, Ruby and Go means each binding has a worked example to copy.

## Components, SCSS variables and the new attribute syntax

The v2 feature list is long, but three items define the day-to-day work. First, the component set grew to 27 components, covering layout, buttons, cards, alerts, hero sections, social links and video, with the full reference and examples in the component documentation. Second, the syntax changed from classes to attributes, so a column is written size="small" rather than class="small", which is a real authoring change rather than a cosmetic one and one the migration tool exists to handle. Third, there is an SCSS framework with per-template variable overrides, so a brand can change colours, typography and layout without rewriting templates. A project also gets layouts and includes through the layout and include elements, custom ink-* components, and template variables, and the SCSS style reference documents the variables for colours, typography and layout.

## Validation, plain text and spam checks as part of the build

This is the part that separates v2 from a template compiler. The tool validates output, with 22 rules covering links, accessibility, rendering quirks, Gmail clipping and spam detection, and it reports missing alt text, Gmail clipping risks and Outlook issues. It can generate a plain text multipart version of an email automatically with the plain-text flag, and it ships a spam checker as a separate command, inky spam-check, which detects common spam triggers. A hybrid output mode adds a different rendering strategy, emitting a div-based layout with Outlook MSO ghost table fallbacks, and bulletproof buttons produce VML v:roundrect fallbacks for styled buttons in Outlook. The email client compatibility document provides a support matrix across desktop, webmail and mobile, and the email development guide covers CSS support, Outlook quirks, images and testing.

## Data merging, template friendliness and per-template data

Templates in the real world are not static. Inky handles that with optional Jinja2-compatible data merging through MiniJinja, enabled with the data flag pointing at a JSON file, and with per-template data, where the data flag can point at a directory and JSON files are auto-paired with templates. What matters here is that the framework does not fight your templating engine: the template friendly behaviour auto-preserves ERB, Jinja2, Handlebars and other merge tag syntax, so the merge placeholders survive the transform rather than being mangled by it. That single detail is what allows the same template to be processed by Inky and then handed to whichever templating system your application already uses.

## Still a beta, with a release history of beta tags

The version status deserves a clear statement, because the marketing-style v2 language can obscure it. Every recent tag is a beta: v2.0.0-beta.8 on 2026-03-31, v2.0.0-beta.9 on 2026-04-24 and v2.0.0-beta.10 on 2026-07-14, and the default branch is develop rather than main, with the repository also carrying an archive-plan.md and a ROADMAP.md at the root. The last push was on 2026-09-23. The README states the licence as MIT, although the repository metadata reports no standard licence identifier, so anyone redistributing it should confirm the terms in the repository itself. For an email framework that sits in the build path, the beta status is the main adoption risk: the API can change between betas, and pinning a specific beta tag is the only way to keep a build reproducible.

## Conclusion

Inky v2 fits a team building HTML email that wants one build pipeline for templates, layout, includes, data merging and CSS inlining, available from a CLI or from PHP, Python, Ruby, Go and Node code with identical output. It does not fit a project that cannot accept a 2.0 beta dependency, or a team that needs a feature list frozen today. Before adopting it, read the migration guide and the v1 to v2 syntax differences, check the email client compatibility matrix for the clients your audience actually uses, and confirm that the beta tag you pin will not shift under you.

## FAQ

### How do I install Inky?

Three routes are documented: brew install foundation/inky/inky for Homebrew, cargo install inky-cli for a Rust toolchain, and npm install inky for the WASM build. Building from source uses cargo build -p inky-cli --release, with the binary landing at target/release/inky.

### What does Inky v2 change from the old Foundation for Emails?

The project was renamed from Foundation for Emails to Inky, and v2 is a Rust rewrite shipped as a CLI binary, WASM module, native shared library and Rust crate. Syntax moved from classes to attributes, the component set grew to 27, CSS inlining is on by default, and a migration command converts v1 syntax to v2.

### Can I use Inky from PHP, Python, Ruby or Go?

Yes. The README states the full build pipeline is available in-process to PHP, Python, Ruby and Go through build() and Build(), producing byte-identical output to inky build, and the workspace provides an inky-ffi crate for the shared library behind those bindings.

### Does Inky generate a plain text version of an email?

Yes, a .txt multipart version is auto-generated with the plain-text flag. There is also a separate spam checker command, inky spam-check, and validation covering 22 rules including links, accessibility, Gmail clipping and Outlook issues.

## Sources

- [foundation/inky on GitHub](https://github.com/foundation/inky)
- [Issues](https://github.com/foundation/inky/issues)
- [Project website](https://foundationcss.com/inky/)
- [README](https://github.com/foundation/inky/blob/develop/README.md)
- [Releases](https://github.com/foundation/inky/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/foundation-inky