# maily.to: a pre-designed email editor built on Tiptap and React

> Maily is an opinionated WYSIWYG editor for transactional and marketing emails, shipped as a pnpm and Turborepo monorepo under MIT. Its value is the component set, not the editing surface, and the README documents far more about using the hosted playground than about embedding the editor yourself.

**arikchakma/maily.to** — Craft beautiful emails effortlessly with Maily, the powerful email editor that ensures impeccable communication across all major clients.

- Repository: https://github.com/arikchakma/maily.to
- Website: https://maily.to
- Stars: 3,975 · Forks: 250
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/arikchakma-maily-to

## The problem Maily targets: email clients, not editors

Writing HTML that renders the same in Gmail, Outlook and Apple Mail is a layout problem before it is a writing problem. Maily's README frames the project around exactly that: designing emails that work across all email platforms and browsers is hard, so Maily is an opinionated editor with a fixed set of pre-designed components. The word opinionated is doing real work. You are not handed a blank canvas and a formatting toolbar; you are handed blocks that already know how to survive an email client.

That places the project's audience fairly narrowly. It suits product teams that send transactional or lifecycle email and want a non-engineer to assemble a template from approved pieces. It does not suit someone who wants a general-purpose rich text editor for a web app, because the component list (Logo, Buttons, Footer, Divider, Spacer, Link Cards, Section, Columns) is email-shaped, not document-shaped. The README lists the supported components and notes more are being added, which tells you the set is still growing rather than frozen.

## What the component list implies about the architecture

Maily is a TypeScript project whose topics name Tiptap, React, Next.js and shadcn-ui. The editor surface is therefore a Tiptap instance rendered inside React, with custom node types standing in for the email blocks. That is the standard way to get a WYSIWYG editing experience that still serialises to constrained markup, and it explains why the component list reads like a schema: each entry is a node the editor knows how to render and how to write out.

Three entries are more interesting than the layout blocks. Variables, Repeat and Show If Condition are template constructs, not visual ones. A Variables node implies placeholder substitution at send time. Repeat implies iterating a collection into repeated rows. Show If Condition implies conditional rendering per recipient. None of that is documented beyond the list itself, so treat the presence of these nodes as a statement of intent about templating rather than a specification you can build against without reading the source.

The repository layout is a pnpm workspace with apps/ and packages/, orchestrated by turbo.json, with vitest.config.ts at the root for tests. The distinction matters: apps/ is likely the hosted product and the playground, packages/ is where anything reusable would live. The README does not tell you which package to install, and no package version appears in the repository files.

## Installing the monorepo and running the development server

The README's contribution steps are the only install instructions present, and they are aimed at running the whole project locally rather than consuming it as a dependency. The sequence starts by cloning the repository and moving into it.

## Configuring Supabase auth before the dev server is useful

Before installing dependencies, the README asks you to copy the example environment file into place. The path is specific to the web app inside the workspace.

## Installing dependencies and starting the server

The root package.json pins the package manager, so the install command is not a free choice.

## The fastest real use is the hosted playground, not the repo

The README's actual getting-started instruction is a link: follow it to access the editor at the playground on maily.to. That is the honest first-use path. If your goal is to evaluate whether the component set fits your emails, opening the playground tells you more in ten minutes than reading the repository does, because the README describes the components by name only and never shows their configuration.

The gap between those two paths is the project's main documentation weakness. The playground is presented as the product; the repository is presented as something you contribute to. There is no README section on embedding the editor in your own React application, no import path, no props table, no serialisation example. If you need Maily inside your own product rather than as a hosted tool, you are reading source, not documentation. That is a legitimate way to work, but budget for it.

## Where Maily is the wrong choice

The clearest failure mode is version pinning. No releases were retrieved for this repository, so there is no published version history to depend on and no changelog to read before an upgrade. If your workflow requires a tagged dependency you can lock and audit, Maily does not currently offer that surface. The last push to the default branch was on 2026-08-28, which is recent, but recency of commits is not the same as a release process.

A second limitation is the opinionation itself. Maily's component set is fixed and pre-designed. If your brand requires a layout the blocks cannot express, the editor becomes a constraint rather than a shortcut, and you are back to hand-writing HTML for email. The README does not describe an escape hatch for custom blocks, so assume you would be adding node types in the source.

Third, the development setup assumes Supabase with Google and Github OAuth providers. That is a real dependency for anyone running the project locally, and it is stated as a prerequisite rather than an optional extra.

## How this differs from React Email and MJML

The obvious alternative in this space is MJML, which takes a custom markup language and compiles it to table-based HTML that email clients accept. MJML is a compiler: you write markup, you get HTML, and the output is deterministic and diffable in version control. Maily inverts that. You edit visually, and the editor owns the markup. The trade-off is direct: MJML gives you reviewable source and no runtime, Maily gives you a non-technical editing experience and no readable diff.

React Email takes a third position, letting you author emails as React components and render them to HTML. That keeps source in version control and in the same language as the rest of a TypeScript codebase, which is attractive if your team already lives in React. Maily's topics include React and Tiptap, so the two are not mutually exclusive in principle, but the README presents Maily as an end-user editor rather than a rendering library. If your problem is generating email from code, React Email or MJML fits better. If your problem is letting a marketer assemble an email without touching code, Maily's component set is the more direct answer.

## Licence and the cost of keeping up

Maily is MIT licensed, copyright Arik Chakma. For most teams that is the permissive end of the spectrum: you can use, modify and redistribute it, subject to the usual requirement to preserve the licence notice. The README separately links to sponsorship tiers and asks that paid products built with Maily consider sponsoring, which is a request, not a licence term. Nothing in the repository suggests a dual licence, a commercial tier, or a contributor licence agreement, so there is no licence reason to hesitate. This is not legal advice; read the licence file at the repository root if the distinction matters to your organisation.

The upgrade cost is harder to estimate because no releases were retrieved. In a pnpm and Turborepo monorepo, you inherit the whole workspace: Turbo task definitions, the pinned pnpm version, ESLint 9 and Prettier with the Tailwind plugin, and Vitest for tests. Tracking upstream means tracking all of that, not just an editor component. The root scripts give you the entry points for doing so.

## Conclusion

Adopt Maily if you want pre-designed email blocks (Logo, Buttons, Variables, Columns, Repeat, Show If Condition) rather than a blank rich-text field, and if you are comfortable working from a pnpm and Turborepo monorepo. Do not adopt it if you need a documented embed API, a published package version, or a release history to pin against; the README offers none of those, and the repository has no retrieved releases. Before committing, verify the workspace layout under packages/ and apps/ to see what is actually importable, and confirm the Supabase auth setup the contribution steps assume, since the README requires Google and Github providers in your Supabase project before pnpm dev is useful.

## FAQ

### Is @mail an email address?

This search question is not about the maily.to project, so it cannot be answered here. Maily is an email editor, and the README never mentions an @mail address or service.

### How do I install maily.to locally?

The README's steps are to clone the repository, copy apps/web/.env.example to apps/web/.env, add Google and Github providers in your Supabase project, then run pnpm install and pnpm dev. The root package.json pins pnpm@9.15.4 as the package manager.

### What components does the Maily editor support?

The README lists Logo, Buttons and Variants, Variables, Text Formatting, Image, Alignment, Divider, Spacer, Footer, Inline Code, Link Cards, Section, Columns, Repeat and Show If Condition, and notes that more are being added. Configuration for each component is not documented in the README.

### Is Maily free to use?

The repository is MIT licensed, copyright Arik Chakma. The README links to sponsorship tiers and asks that paid products built with Maily consider sponsoring, which is a request rather than a licence condition.

### Can I try Maily without setting up the repository?

Yes. The README's getting-started instruction is a single link to the playground on maily.to, described as the way to access the editor. That is separate from the contribution steps for running a development version.

## Sources

- [arikchakma/maily.to on GitHub](https://github.com/arikchakma/maily.to)
- [Issues](https://github.com/arikchakma/maily.to/issues)
- [License: MIT](https://github.com/arikchakma/maily.to/blob/main/LICENSE)
- [Project website](https://maily.to)
- [README](https://github.com/arikchakma/maily.to/blob/main/README.md)

---

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