Mautic GrapesJS email and landing page builder: what it does and when teams need it
Teams that self-host Mautic need a builder when marketers must produce emails and landing pages without writing HTML for every campaign. Mautic's built-in builder, based on the GrapesJS web builder framework, is the tool that covers this need. It has shipped since Mautic 3.3 and became the default builder in Mautic 4.0, so a self-hosted instance on any supported release line from 4.0 onward uses it unless the team has changed that setting. If your marketers are still asking developers to hand-code templates, this builder is the first thing to evaluate before you plan custom tooling. The builder is a drag and drop editor. GrapesJS supplies a set of built-in blocks, such as text, images and layout sections, and Mautic's implementation lets users place these into an email or landing page and adjust them in the editor. GrapesJS is designed to be extended, so a team can add custom blocks that carry approved markup, brand components or recurring layouts. That extension point is where most implementation effort sits, because a custom block is code your team or partner must write, test in several mail clients and maintain across Mautic upgrades. The project history matters for planning. The builder was initiated by Webmecanik and contributed to the community by Aivie. For your purposes, this means the builder is part of the Mautic codebase you upgrade, not a separate add-on with its own release schedule. Check the builder's behavior in each release you test, and read the release notes before moving a production instance to a new minor or major version. The main decision is whether marketers will work primarily in the builder or whether most email will arrive as hand-built HTML from an agency or design system. If the builder covers the common formats, plan a small library of custom blocks and a governed set of templates. If your brand requires strict HTML email rules or a design tool outside Mautic, confirm early that the builder's output and your review process can meet those rules before you commit to a launch date. Before committing, confirm three points with your own environment: which Mautic release line you will run, whether your existing templates are compatible, and who in your organization will own custom blocks after go-live. These answers shape the scope of any implementation quote more than the builder itself.
Which builder options fit which kinds of email and page work
This table compares the built-in GrapesJS blocks, custom blocks, and reused templates against the kinds of email and landing page work teams usually bring to Mautic. Read each row to find the option that matches your work, then check the maintenance and consistency notes before committing to a block structure.
| Work type | Built-in GrapesJS blocks | Custom blocks | Reused existing templates |
|---|---|---|---|
| Standard newsletters | Suited to fast, simple layouts that marketers assemble themselves with little setup | Usually unnecessary, and adds upkeep if the newsletter layout changes often | Useful when a proven newsletter layout already exists and only the content changes |
| Branded landing pages | Works for basic pages, but brand fonts, spacing and colors may need manual adjustment each time | Well suited when a fixed set of branded sections must appear on many pages | Works if the template was built for Mautic's builder; confirm it needs the configuration line Mautic's builder docs describe |
| Pages that must match a corporate theme | Limited fit, since default blocks may not carry the corporate design system | Best fit, because the block markup can carry the approved styles and components | Partial fit, as older HTML templates may need rework to match the theme |
| Maintenance effort | Lowest, since blocks are maintained as part of the builder | Highest, since each custom block needs updates when the builder or theme changes | Moderate, since templates must be checked after each Mautic upgrade |
| Consistency across marketers | Depends on training, because marketers can build very different layouts from the same blocks | Strong, because marketers choose from approved blocks rather than building layouts from scratch | Strong for each template, but variation grows if marketers edit templates freely |
| Dependence on block structure | Low, since the default blocks are the baseline everyone uses | High, since custom blocks tie content to the builder's structure and may need rework after changes | Medium, since templates depend on the builder's expected markup and configuration |
| Questions to confirm before choosing | Which default blocks your teams need and how they render in your target email clients | Which block set to build, who owns it and how it is versioned and tested | Whether each template works with the configuration line and what rework your theme needs |
How custom blocks extend the Mautic builder without forking it
Custom blocks let your team add brand components to the Mautic builder while keeping Mautic's own code unchanged. The builder is based on GrapesJS, which ships with built-in blocks and can be extended with custom blocks. The first decision is which brand components become blocks. Good candidates are components marketers rebuild by hand in almost every email or landing page, such as a header with the approved logo, a call-to-action button in brand colors, a two-column product module, and the legal footer with preference and unsubscribe wording. Keep the first set small. Each block should map to a component that has an agreed owner, a clear purpose and a stable set of settings that marketers can change without breaking the layout.
Blocks must produce markup that email clients can render. In practice this means table-based layout, inline styles where clients require them, images with explicit dimensions and no scripts or external stylesheet dependencies. Landing pages have different needs, so decide early whether one block set serves both or whether some blocks are limited to landing pages. Ask your implementation team to confirm which contexts a block can be registered for in your release line. Then test each block in the email clients and devices your audience uses, and record the results. A block that looks correct in the builder preview can still break in a mailbox, so the preview alone is not evidence that a block is safe to send.
Every block needs a named owner who is responsible for its definition, default content, styling values, tests and retirement. In most organizations this is a platform engineer, with a marketing lead who approves design changes. Decide who maintains blocks after go-live. If the internal team will own them, check that it has the skills to change the builder's JavaScript and to retest after upgrades. If a partner maintains them, ask for the initial block build and the recurring maintenance to be quoted separately, and confirm who pays for changes requested by marketing. Recurring work includes fixing blocks after upgrades and retiring blocks that no campaign uses anymore.
Blocks depend on the builder code of the Mautic release you run, so version them with that release. Mautic's stated cadence includes monthly patch releases, minor releases every three months and major releases every two years. Mautic 7.2 receives active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Mautic 5.2 receives security support until 30 June 2026, and Mautic 4.4 has paid Extended Long Term Support through 31 December 2026. Record the release line each block set was built and tested against, keep block definitions in version control, and retest blocks in staging after every patch, minor or major upgrade before production.
Existing templates need attention before they work with the new builder. The Mautic builder documentation says existing templates need one line added to the configuration file, so confirm the exact line and the extension method for your release line in the builder documentation before you change anything. Then inventory the templates in use, note which ones depend on blocks you plan to retire, and assign each one a migration owner. Test a sample of templates in staging, including one with complex layout and one used for a live campaign, so you can see how they render in the new builder before any campaign depends on them.
How to set up the builder on a self-hosted Mautic instance
This sequence takes a self-hosted Mautic instance from confirming that the GrapesJS builder is available to a tested email and landing page setup ready for production. Each step ends with a check, so the team knows whether to continue or go back. Running the sequence on staging first lets template and block problems surface before any contact receives a message.
Confirm the release ships the builder
The platform owner confirms the installed Mautic version and checks the release notes and the builder documentation for that version. Mautic has shipped a GrapesJS-based builder since version 3.3 and made it the default builder in version 4.0, so an installation at 4.0 or later should use it for new emails and landing pages. If the instance runs an older release, plan an upgrade before going further, and confirm the target release is still on a supported line. The check is that a new email or landing page opens in the GrapesJS builder by default when created from the admin interface.
Check server requirements for the release
The infrastructure owner compares the server against the requirements page for the exact Mautic release, not for a previous one. Confirm the supported PHP range, the MySQL or MariaDB version with InnoDB support, the web server (Apache, Nginx or IIS), and npm, which is required from Mautic 5.0 onward. Confirm the host is a VPS or dedicated server, because the project advises against shared hosting. Record the output of the PHP, database and npm version commands in the change record. The check is that every reported version falls inside the range listed for the release.
Build a staging instance
The platform engineer builds a staging instance that matches production in PHP, database engine, web server and Mautic release. Install from the production package with the web or command-line installer, or use the Composer project template, which is the recommended method since version 4.0. Configure the cron jobs for segment updates, campaign updates and campaign triggers, staggering their start times as the documentation advises. Add the broadcasts command for segment emails and a messenger consumer if emails will be queued. The check is that the admin login works, the cron jobs run on schedule, and no errors appear in the Mautic logs after a full cycle.
Create a test email and landing page
A marketing operations lead creates one email and one landing page in the GrapesJS builder on staging, using only the built-in blocks first. This isolates whether the builder works on the instance before custom work begins. Save both assets, preview them in the builder, and send the email to internal seed addresses that cover at least two mailbox providers the organization uses. Submit the landing page form if it has one, and confirm the submission reaches the contact record. The check is that both assets save, preview correctly, and deliver with the expected content and tracking.
Add custom blocks and update existing templates
A front-end developer adds custom blocks by extending the GrapesJS configuration that ships with Mautic, following the builder documentation for block definitions and their styling. For each existing template, add the configuration line that the Mautic builder documentation says is needed before a template works with the new builder, then open each template in the builder to confirm it loads without errors. Test each custom block in the block panel and drag it into the test email and landing page. The check is that every custom block appears in the panel, renders in the builder, and produces the expected markup in the saved asset.
Verify rendering in mail clients and browsers
The QA owner tests the test email and landing page across a written list of mail clients, webmail services and mobile browsers that the audience actually uses, agreed before testing starts. Use a rendering testing service or a set of devices the organization controls, and check the layout, images, links, dark mode behavior and the landing page form on small screens. Log each defect against the block or template that caused it, then fix it in the custom block or template and retest. The check is a signed-off test record showing that every agreed client and device renders the content without layout breakage, and that all defects are closed or accepted in writing.
Promote the setup to production
The platform owner moves the approved templates, custom blocks, test assets and configuration to production through the same change process used for other releases. Campaign and asset transfer can use the export and import methods described in the Mautic campaign import and export topic, or the team can reapply the configuration through version-controlled code. Confirm the production cron jobs and queue consumer run on the same schedule as staging. Send one production test email to internal seed addresses and load the landing page on a production URL. The check is that the production test email and landing page match the staging results and that the cron and queue logs show normal activity.
What existing themes and templates need before they work with the builder
The Mautic builder documentation says that existing templates need one line added to the configuration file before they work with the new GrapesJS builder. Treat this as the first gate for every template and theme created before the builder was in use on your instance. Confirm the exact line, the file it belongs in, and the documentation section that describes it for the Mautic version you run. Documentation for a current release may not match an older install, so record the version, the date you checked, and the section reference in your change ticket. Do not copy a line from a forum post or from another instance without checking it against your own version.
Run an inventory before you change anything. List every email template and landing page theme that marketers can select, and record where each one lives, who created it, and whether it is stock, custom or third-party. Stock items follow upstream changes, so they should need the least work. Custom items were written by your team or a contractor and need a named owner. Third-party items come from a vendor or marketplace, so request the vendor's written statement on builder compatibility. Also check which emails and landing pages reference each template, because the usage count decides how much testing and rebuilding each one deserves.
Sort each template into a likely path. Some can take the configuration line and keep working as they are. Others contain markup that the builder cannot edit cleanly, and those need rebuilding as blocks, which are reusable sections of structure and content that marketers can drag and drop. The rebuild is where design decisions move into the builder. Decide which brand components become custom blocks, which fields marketers may edit, and which elements stay fixed. Rebuilding usually takes longer than the configuration step, and it needs time from marketing, design and the template owners. Do not set a schedule until the inventory gives you a count of templates in each path.
Test every template on staging before production is touched. Copy the production templates and a recent set of content into a staging instance, apply the configuration line there first, and then open each template in the builder. Send test emails to seed addresses across the mail clients your audience uses, and load each landing page on desktop and mobile widths. Confirm that edits saved in the builder appear on the public page and that dynamic content still resolves. Log each failure against a template, an owner and a decision: fix, rebuild or retire. Schedule the production change only after that list is closed, and confirm which backups and rollback steps the documentation for your version requires.
Security and operational considerations for builder content
Builder content in Mautic reaches recipients and visitors directly, so who edits it, how custom code is reviewed, and how pages are hosted all matter. The cards below cover the access, review, hosting and upgrade decisions to settle before the builder goes into regular use.
Editing and publishing access
Builder access is controlled through Mautic user roles, so builders and publishers can be different people. Map each role to a job, since marketers, designers, sales staff and agencies usually need different permissions. Confirm in your version which permissions cover building, editing and publishing emails and landing pages, then test each role with a non-administrator account before go-live. Review who holds administrator access, because the default role setup gives new users full administrator access unless you change it.
Custom block code and HTML review
Custom blocks can carry HTML, inline styles and script, and each output behaves differently in email than on a landing page. Set a written rule for who may add or edit block code, and require a second person to review it before publication. Test each block in a staging instance across the email clients and browsers your audience uses. Confirm what your version permits in each context, and keep a record of who approved each change.
Authentication and single sign-on
Mautic uses basic authentication for users by default, so accounts are local to the instance unless you configure more. Mautic can integrate with a SAML single sign-on identity provider, which must send email, first name and last name attributes. The documentation describes no LDAP option, so confirm directory sign-in with the project before you plan around it. Decide before go-live how builder users are provisioned and removed, and who owns the identity provider configuration.
Landing page hosting and change control
Landing pages built in the builder are served from your Mautic instance, so availability, TLS certificates and DNS sit with the team that runs the server. Confirm the public URL structure, caching behavior and the steps for rolling back a page before a campaign goes live. Record who edited each page and keep an approved copy of each version before major changes. Use a staging instance for pages that carry forms or tracking.
Template changes during upgrades
Mautic's builder documentation says existing templates need one line added to the configuration file before they work with the builder. Treat that line as a checklist item for every upgrade rather than a one-time fix. After each upgrade, open a sample of older email and landing page templates in the builder and confirm they load and render. Store the configuration with your other infrastructure code, and test templates built on third-party themes separately.
Release cadence and support windows
Mautic plans monthly patch releases, minor releases every three months and major releases every two years, and builder fixes arrive through these releases. Plan a patch window each month and an upgrade decision each quarter. Support dates shape those decisions: Mautic 7.2 has active and security support until 30 September 2026, Mautic 6.0 has security support until the same date, Mautic 5.2 until 30 June 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Confirm current dates on the releases page before you commit to a release line.
Questions teams ask before they hire help with the Mautic builder
How much effort does a Mautic builder rollout take?
Effort depends on four inputs: how many templates you carry over, how many custom blocks you need, how strict your brand rules are, and how many people must approve each asset. No public figure covers this work, so ask for a quote built from a written scope that lists each input separately.
Templates that already work in the builder need little more than the configuration change Mautic's docs describe. New custom blocks need design, build and testing across mail clients and landing page widths. Brand rules add effort when they must be enforced inside the builder, and less when a reviewer checks them by eye.
Ask each provider which of these inputs its estimate assumes.
What drives the cost of a Mautic GrapesJS builder project?
The main cost is professional time for scoping, block development, template conversion, testing and documentation, which the implementation partner is paid for. Your own team pays internally for brand assets, reviewer time and test mailbox setup, and these costs are easy to overlook.
Costs rise with the number of custom blocks, the number of brand rules that need automated checks, and the number of approval stages. They fall when you reuse components from an existing library.
A quote should itemize each phase, state what is excluded, and name the Mautic version it targets. Ask which costs are one-time and which recur, such as upgrades and new content, and whether ongoing support is priced separately. DeployOpen offers retainers for ongoing support.
How long does a builder rollout take from start to finish?
A rollout moves through a fixed sequence of steps, and the length of each step depends on your inputs. The usual sequence is scope and asset inventory, a template audit, block design, build, testing, review and sign-off, then handover with documentation.
Scope and inventory set the pace for everything after them, so gaps in brand assets slow the later steps. Testing takes longer when many mail clients or landing page layouts must be covered. Review time depends on how many people approve each asset and how quickly they respond.
No general duration applies to every organization. Ask for a written plan that lists each step, its start and end conditions, a named owner for every handoff, and the sign-off dates your team has to meet.
What does our internal team need to provide before the work starts?
Your team needs to provide brand assets, approved components, test mailboxes, owners for sign-off and access to a working Mautic instance.
Brand assets include logos, color values, font licenses and the current design guidelines. Approved components are the blocks and layouts your reviewers already accept, which gives the build a clear target. Test mailboxes should cover the mail clients your audience uses, and someone must keep them reachable.
Sign-off owners need one named person per approval stage with authority to decide, plus a deputy for absences. Provide a staging instance for builds so that test sends never reach live contacts. Confirm access to the Mautic admin area and to the email transport before work begins.
Can our marketing team run the Mautic builder without outside help?
Yes, a marketing team can build and send emails and landing pages in the builder once templates and custom blocks exist. Day-to-day tasks such as editing copy, replacing images and assembling pages from approved blocks do not require a developer.
Outside help is usually needed to design and build custom blocks, convert legacy templates, set up brand rules, and handle upgrades or configuration changes. Where the line falls depends on your team's skills and how often new block types are needed.
A practical test is a pilot. Ask marketers to build three pages from your component library before you decide. Confirm the Mautic version you run first, since builder behavior and configuration can differ by release line.
Do existing email templates need changes to work in the builder?
Yes, existing templates usually need some work before they run in the new builder. Mautic's builder documentation says one line added to the configuration file lets existing templates work with the builder, and that line is the starting point rather than the full job.
Engineers should check each template for hard-coded markup, inline styles that conflict with the builder, dynamic content tokens and tracked links. Templates built for older layouts may not map cleanly onto GrapesJS blocks, so some will need rebuilding as custom blocks.
Test every converted template in staging at desktop and mobile widths, then send it to test mailboxes before any campaign uses it. Keep a record of which templates were converted and when each one passed review.
Which Mautic release line should we confirm before planning builder work?
Confirm your release line before you plan builder work, because the release line sets the support window for any custom blocks and templates you build. The builder has shipped since Mautic 3.3 and became the default builder in Mautic 4.0.
Mautic 7.2 receives active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027, according to the Mautic releases page. Check that page before you plan, because support dates change how much custom work makes sense on one version.
If you run an older line, plan the upgrade as its own project, since builder changes and template conversion may both be involved.
Limits to confirm in your environment before you commit
Each item below is a check to complete before you commit to a release, a template set or a sending design. They connect because the builder, the Mautic release you run and the sending pipeline change together during an upgrade.
Release line and security support
Confirm which Mautic release line you will run and whether it still receives security fixes on your go-live date. The releases page lists 7.2 with security support until 30 September 2026 and 7.3 as the planned long-term support release with security support through 31 December 2027. Check 6.0, 5.2 and the paid Extended Long Term Support for 4.4 against your go-live and upgrade plan, since their dates fall sooner.
Builder behavior on your release
The GrapesJS builder has shipped since Mautic 3.3 and became the default in 4.0, but editor options, block sets and asset handling can differ between the lines you might run. Install the exact release in a staging environment, open an existing email and an existing landing page in the builder, and record what changes. Ask your partner or the Mautic project which builder behaviors are tied to the version you pick.
Rendering across browsers and mail clients
The builder produces the HTML for landing pages and emails, but your audience's browsers and mail clients decide how it looks. Build a test matrix from your contact data covering the browsers used on your landing pages and the mail clients your subscribers open email in. Send seed messages to test accounts, then check layout, images, links and dark mode, and confirm that your tracking and consent markup survives in each client.
Existing templates and the configuration change
The builder documentation states that existing templates need one line added to the configuration file before they work with the new builder. Inventory every template in use, including those from themes, plugins and older installations, and confirm which ones depend on that line. Apply the change in staging first, then open each template in the builder to confirm it loads and saves without losing sections or dynamic content.
Custom blocks across upgrades
GrapesJS lets you extend the built-in blocks with custom blocks, so your code sits alongside Mautic's own builder files. Confirm where each custom block lives, whether in a theme or a plugin, and review what changed in the builder code between your current release and the target one. Keep custom blocks in version control and run each upgrade through staging with a block-by-block test before production.
Queue, cron and sending interaction
Mautic relies on cron jobs for segment updates, campaign updates and campaign triggers, which the documentation says should be staggered, plus a broadcasts command for segment emails. When emails are queued, a messenger consumer must also run. Confirm how builder-created emails reach the queue, which jobs run in which order, and who monitors the consumer, because a stopped consumer or overlapping cron runs can delay sends without an obvious error.
How DeployOpen scopes, builds and supports the Mautic builder
DeployOpen scopes the Mautic builder as part of the wider Mautic implementation, starting from the templates, blocks and email content your teams already use. Work is planned in writing before the build begins, and the builder is tested and documented inside your own infrastructure. Ongoing support is available as a retainer once the builder is live.
How we scope
- The written scope names which Mautic email and landing page templates are included.
- Existing themes are audited for the configuration line and template changes the new builder needs.
- Fixed-scope engagements are agreed in writing before work starts, with ongoing support available as a retainer.
How we build
- Custom GrapesJS blocks are designed for the layouts your marketing team reuses in emails and landing pages.
- Built-in GrapesJS blocks are extended only where the reusable components need behavior beyond the defaults.
- Builder changes are tested in a staging instance with sample emails and landing pages before production.
How we hand over
- Handover includes the template and block inventory, with each custom block's purpose and its owner.
- Runbooks cover the configuration line, template conversion steps and adding a new block safely.
- Marketers receive a short walkthrough of building emails and landing pages with the delivered blocks.
How we support
- Custom blocks and templates are rechecked against each Mautic release before the upgrade goes live.
- Support covers fixes to custom blocks and template issues raised by your marketing team after go-live.
- Ongoing support and upgrades are available as a retainer, scoped in writing like the original build.
