TRMNL: Blog

Creator Fund - April 2026

2026-05-07T00:00:00+00:00

for more context see the Creator Fund announcement.

our 7th payout rewards community contributions between April 6, 2026 and May 6, 2026.

source of funds

each payout period, a portion of developer-specific revenue goes directly to creators.

source	revenue	share	amount
Stripe Developer Edition TRMNL+ Shopify Developer Edition Clarity Kit (X) Clarity Kit (OG) BYOD	$3,980 $538 $149.65 $12,139.38 $14,379.29 $18,095.15	15% 80% 15% 10% 10% 10%	$697 $430.40 $22.45 $1,213.94 $1,437.93 $1,809.52
	$49,281.47		$5,511.23

source

revenue

share

amount

Stripe

Developer Edition
TRMNL+

Shopify

Developer Edition
Clarity Kit (X)
Clarity Kit (OG)
BYOD

$3,980
$538

$149.65
$12,139.38
$14,379.29
$18,095.15

15%
80%

15%
10%
10%
10%

$697
$430.40

$22.45
$1,213.94
$1,437.93
$1,809.52

$49,281.47

$5,511.23

by the numbers

total payout: $5,511.23
plugin author share: $3,857.86 (70% of base total)
strategic contributors share: $1,653.37 (30% of base total)

plugin author earnouts are calculated automatically by a collection of factors including a plugin's age (on live playlists), presence (by % dominance on playlists), and impressions (times displayed on device), relative to all other community plugins. there is a minimum threshold of 50 total connections (installs + forks) to qualify for monthly payouts. see the algorithm in action here.

strategic contributors are those who contribute to TRMNL open source projects. these earnouts are calculated with a mix of automation + human touch. relative to the funding available, below are allocations by category:

Firmware, 6%
3D Models, 0%
BYOS, 52%
Localizations, 5%
BYOD, 34%
Documentation/Resources, 0%
Tooling, 3%

note that these allocations change monthly based on contributions by category.

algorithm?

over time the above weights, revenue share percentages, and minimum thresholds may change. reporting will become more transparent. our goal is an open sourced algorithm and self-service calculations with daily (or faster) resolution.

candid feedback is welcome, email team@trmnl.com.

Model X Progress Report

2026-05-07T00:00:00+00:00

We introduced X on July 30, 2025. Below are live updates since launch.

When will I receive my TRMNL X?

We began assembly + fulfillment on March 18 from our USA warehouse.

Live in USA, Canada, Mexico, or Australia?

Your TRMNL will ship from our USA warehouse. On April 26 this location received strong, N52 magnets which makes it possible to ship devices with the battery upgrade. Prior to this date we only shipped devices with a single battery, which accounted for just 7% of X preorders.

Between May 3-6 we were temporarily out of charging docks due to a supplier mis-shipment. These arrived May 7th. To remain at full capacity we sent other colors, which means that while we dispatch > 100 devices per day, your spot in the order queue may not have reduced by 100+ as we fulfilled slightly out of sequential order based on in-stock colors.

Live in Europe, Asia, Africa, South America, etc?

Your TRMNL will ship from our Berlin warehouse. Due to issues with Customs and theft from suppliers, this warehouse has only received 3x case colors (Clear, White, Gray) and does not have magnets strong enough to support devices mounted to metal surfaces (e.g. refrigerators).* To receive your device sooner it may be possible to change your color or downgrade to a single battery version. Email niklas@trmnl.com to arrange.

Strong (N52 grade) magnet arrival?

New magnets were shipped to our warehouses in March and finally arrived in the USA on April 26. As founder of TRMNL I guarantee we will scale fulfillment to 100s of devices per day once both warehouses have the missing components described above.

*For more details about magnet issues see the "March" and "April" sections at the bottom of this post.

Tech Specs

Highlights below, or see everything here.

10.3" 1872x1404 EPD resolution with 16 shades of gray
Dust and basic waterproofing with a hacker-friendly enclosure
ESP32-S3 with 16MB of flash and 8MB of PSRAM as a core processor with fallback 2.4GHz WiFi
5GHz WiFi support via ESP32-C5 as a modem (external antenna)
Support up to 2x 6000mAh 3.8V LiPo batteries with automatic detection
Battery gas gauge from TI for battery SOC/SOH/capacity tracking
Bosch accelerometer for portrait/landscape orientation
Gesture touch-bar based on Azotech IC
Magnetic pogo pin-based mount for charging and accessories (Coming 2026)
OTG support with 5V 2A output

Dimensions

These values may change as we scale production. last updated December 15, 2025.

X enclosure dimensions (mm)

Weight (device only, no attachments)

1 battery - 362 grams
2 batteries - 448 grams

August 2025

Multiple boards and controllers support touch gestures, battery charging, and 5ghz WiFi
The circular area interfaces with a waterproof "puck" shaped charging connector, and several test points on the motherboard's bottom will let us build a QA jig for our warehouse
Prior to release we'll prototypes to your favorite creators for first-look reviews

September 2025

PCB preview

We ordered 50x more prototypes with stronger magnets so devices can attach directly to a surface (e.g. refrigerator) without mounts
Dual band WiFi will be powered by the ESP32-C5 and we've benchmarked faster speeds + better range with custom modem firmware
Orders with the Battery Upgrade (or Clarity Kit) will now enjoy 10,000mAh versus the announced 7,000mAh variant
Our "charging puck" (name TBD) now has a universal connector for kickstands and other peripheral accessories that will debut in 2026
The same firmware that runs all OG + BYOD devices has been extended and is already running my own X prototype, preview here

October 2025

Grayscale testing with a GOAT

The first batch of screens arrived at our USA warehouse, more en route to our Berlin warehouse
Gesture bar + charging pucks are in small batch production
Received and approved packaging samples. Model X packaging will be more premium and protective than OG packaging.
Consolidating WiFi antennas (2.4 + 5gh) to a single component
Added 3 angle options (degrees) to the kickstand
[Work in progress] battery options may grow another 20% to 6000/12000mAh variants pending more testing

November 2025

Full assembly (3D printed parts, not final)

Fully functional prototype (3D printed case, non-branded silicone pads)

Prototype running latest (public) firmware release

Added extra reset buttons to S3 and C5 MCUs for hacker friendliness, board design is final
Batteries are in production and we can confirm the improved 6k / 12kmAh sizing (announced size: 5k / 7k)
Enclosure injection molds are in production, purchase order placed for thousands of cases in different colors
Magnet deliveries from Chinese factories have been delayed due to recent Critical Mineral Export Bans

December 2025

Battery production complete, shipping to our warehouses next week
EC licenses underway at testing facilities
Packaging in mass production
Magnets in mass production
[New] OTG functionality - power other devices from your TRMNL's charging puck

January 2026

From my desk to yours, a video update.

February 2026

From our warehouse to your desk, a video update.

March 2026

From my desk to yours, a video update.

If you prefer not to watch the video, in summary we're shipping single-battery devices only from our USA warehouse because our magnet supplier ripped us off and sent thousands of weak magnets, following multiple sample shipments with the correct (strong) magnets.

As of Wednesday, March 18:

Berlin warehouse has all 3 types of PCBs
Berlin warehouse should receive device enclosures in 1-2 weeks
USA warehouse has everything and has begun assembly + fulfillment

To check your place in the queue go here:
https://trmnl.com/order-tracker

If you already have a TRMNL, install the Order Tracker plugin to stay up to date:
https://trmnl.com/recipes/260817

How can I estimate the time it will take to receive mine?

Devices will be shipped in the order they were purchased and we intend to scale to 100s of fulfillments per day, as we have done for past releases and back-in-stock periods.

Our 2x warehouses have trained 15+ individuals to flash, assemble, and ship devices. We do not outsource to 3rd party logistics companies. You can learn more about our end to end philosophy and technology here and here.

April 2026

See a live demonstration of strong, N52 grade magnets on various refrigerator surfaces in this video update.

On April 26, N52 magnets arrived at our USA warehouse and assembly/fulfillment pace will increase dramatically beginning Monday, April 27.

On April 27, white + gray cases arrived at our Berlin warehouse and they are building half-assemblies (docks, kickstands) as they await N52 magnets.

May 2026

The USA warehouse has been shipping 100+ devices per day since May 1st. However, between May 2-6th we were out of stock of charging docks for several colors due to a supplier mistake. To mitigate we assembled devices of all colors, but only fulfilled in-stock (charging dock) orders, some of which may sequentially be behind yours.

On May 7, black and sage charging docks arrived, allowing us to mostly ship in sequential order. This ensures the highest throughput overall, as punishing later orders with in-stock colors does not increase the speed of out-of-stock colors arriving.

Featured Community Plugin - Supercars Drivers

2026-05-06T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Supercars Drivers

Community member Sam Sharp created the Supercars Drivers plugin; here are their words on how it was created.

Why did you want this plugin to exist?

I wanted this plugin to exist because Supercars is one of my favorite racing series and I liked the idea of having the standings visible in a clean, simple format while giving me one less excuse to check my phone. It also felt like a good addition to the marketplace because Australian sports had not yet been well represented. More broadly, it became part of a fun hobby of extending the project to cover the sports I enjoy that had not been built yet.

How did you balance look vs functionality?

Primarily wanted a clean and functional design so it's easily readable and makes use of all the screen real estate afforded by each device/layout. As I have begun to branch out and try new designs I've started to increase my use of images and more appealing design elements from the framework.

TRMNL OG

TRMNL X

Were you inspired by any other recipes or plugin creators?

Main inspirations on content and design were Daniel Sitnik's Formula 1 Races and Formula 1 Constructor Standings plugins.

What was your process for creating the plugin?

Was initially writing everything manually and updating static JSON as a PoC and test rendering on a real device. Recently getting a Github Copilot subscription and OpenCode has really sped up the building and testing. Incorporating the preview and API tools in the trmnlp repo has been especially helpful with iterating locally before easily updating all layouts through the API (once instating a beta plugin strategy to prevent over eager agents pushing changes to published recipes).

What, if any, challenges did you face while creating it?

The plugin categories were a bit buried in the docs so took me a while to find which values were allowed. Making changes to layout when they are relevant to multiple layouts/plugins got tedious when performing manually. Only gap I've found is the inability to adjust the custom fields easily through the preview GUI. I've written a wrapper to handle this when launching the preview but would be more convenient through the GUI. Would also be useful to access the Chef linter prior to requesting publishing.

Did you learn anything you want to apply to future recipes?

More rounded backgrounds / info tiles, icons and horizontal/rounded gauges. Also trying to think about more custom fields that may be useful and applying them to more devices and layouts as mine primarily focus on the v3 Full layout.

Is there a tip you would give to a new plugin developer?

Keep as close to the UI Framework as possible as some styling may appear to work in the preview but not once rendered on device. Try to think about how best to use all real estate afforded on each device and what custom fields might be useful/fun to incorporate early as refactoring later on can get tedious.

What is your favorite plugin that someone else created and why?

STRMNL Activity - Has been really satisfying seeing my activities stack as the week progresses and being laid out in a really nice format.

Introducing Typography

2026-04-30T00:00:00+00:00

March 29, 2024. pre-production samples arrived and we tested our first plugin. it looked like crap.

TRMNL OG, March 2024

minutes later, anti-aliasing became a topic of daily conversation. with my colleagues and with my wife. our little consumer grade panel couldn't handle font smoothing, we needed a bitmap option.

MVP

enter Nico and BlockKie. a huge thanks to creators Emily Huo and Joohn for their excellent work and gracious OSS licensing.

soon after we added Inter to the lineup, which is great for brief + large values like numbers and dates.

before Inter:

after Inter:

with fonts mostly figured out we shifted design effort to Framework, our UI library for ePaper displays generally.

whole product

making Framework a viable resource took a couple years and is the brainchild of Lucian. as fewer developers reached for <import tailwind> in their markup, we knew we were on the right track.

just last month we shipped v3.0 with color support, dark mode, and so much more.

Spectra 6 and BWRY palettes

Progress bars, grayscale, dark mode

Framework is part CSS, part JavaScript.

the CSS does what you'd expect: make things pretty. whereas JS modulations do fancy stuff: truncate text, abbreviate large numbers, even bump pixels to the very edge of a frame.

final form

today we're proud to announce Framework v3.1, which ships with 2x font bundles.

Classic includes Nico, BlockKie, and Inter
TRMNL includes three hand-made families in Regular and Bold weights

our starting sizes are 12, 16, and 21pt, optimized for the TRMNL OG 7.5" display.

TRMNL font cuts in tandem

each weight contains 694 glyphs spanning Latin, Western/Eastern European, symbols, operators, even dingbats. see them in action.

Classic → TRMNL

TRMNL font is crunchy but smooth, tight but legible, bitmap-safe but ready to party. it's also going to be open source. friends don't let friends struggle with ePaper readability.

get started

if you build Private Plugins, upgrade to Framework v3.1 from the settings screen.

Pin a version or set to "track latest"

to try the TRMNL font on specific plugins, navigate to your Playlist and hover the (•••) icon > Presentation > Font Family > TRMNL.

Switch fonts on a per-plugin basis

to upgrade all your plugins to the TRMNL font, visit your Device settings > Palette configuration:

note that if a given plugin (native or otherwise) is pinned to an earlier Framework release (< 3.1), your font family preference will fall back to the Classic bundle until that plugin is updated.

for more information, read the docs:
https://trmnl.com/framework/docs/3.1/font_family

what's next

our first release has a few icons and some non-Latin characters. but we're thinking a native icon pack (trmnl-icon-star) might be useful too. or even Korean, and maybe a bitmap take on emojis.

we look forward to your feedback and can't wait to see what you build.

A Checklist for Turning a Private Plugin into a Recipe for Others

2026-04-27T00:00:00+00:00

I made something great, and now I want to share it with others!

This sentiment has been thought by 100s of plugin authors, willing to transform their work from private benefit to public good. To do that, authors go through our recipe review process. This comes in two steps:

Automated feedback from CHEF, a tool to catch common mistakes or oversights before submission.
Manual feedback from a human, where we look over everything to make sure it meets our quality bar, then provide you with specific feedback and guidance about changes, if needed, that are required before publishing.

While it is ever evolving, here is the steps we go through to make sure your recipe is ready to go, broken down into sections of the plugin. Some quick terminology:

user: Someone who installs or forks a plugin recipe.
author: Creator and maintainer of a plugin recipe.

Plugin Ecosystem

Recipes are evaluated on how they contribute to the plugin ecosystem overall. This includes a few core ideals:

Collaboration over competition. A new recipe should not be seen by a user as indistinguishable from an existing recipe. If there is a similar plugin, it should add easily identifiable value.
Efforts to improve existing plugins should be the first priority, but we understand that if the original author is non-responsive or your suggestions are outside of the goals they have for their recipe, that a new recipe can be appropriate.
Similar topics, but different data sources, are great examples of where competition is valuable and completely acceptable.
Depth, not numbers. Variations on an idea should be encompassed within a single recipe. Whenever possible, a recipe that serves multiple themes, layouts, or even highlights different data from the same data source by using form fields is more valuable than multiple recipes creating noise in the search results. We consider omnibus plugins like Comic Library strong additions to the ecosystem.
TL;DR We want higher quality, not just more.
Family friendly. The default option is always family friendly and non-offensive. If content (language, images) that wouldn't be appropriate for a 13-year-old could appear, it should be default filtered off. If a recipe cannot be, you can publish it as unlisted, which makes it available to others, but will not show up in any search results.
Additionally, we have special categories (set in Form Fields), for things that are on the edge. For instance, the morbid category is searchable as a #category, but recipes are excluded from search results using normal terms.

Form Fields

Make sure the author_bio offers at least one way that a user could get in-touch with the author and that appropriate categories are chosen.
Check that default and placeholder is being used appropriately and there are no erroneous fields like optional: false (you only need to include it if it is true).
Update any plain-text links to use HTML href links and include <br/> when it was clear the author intended a line break.
Test each of the form fields to make sure the functionality offered is actually working. This involves making adjustments, saving, and looking within edit markup to see the changes.
This also includes making use of "key":"value" pairs for options if it improves readability to the user and usability for the author. Also check that truthy values like yes, true, 1 are evaluated properly in Liquid logic.
Validate no personal information will leak and that, if necessary, demo data is used.

Plugin Strategy

Polling

We use the parse feature to make sure the URL is processing logically and to understand if the endpoint is privately hosted or a public API. If public, but requiring authorization, that appropriate links and instructions are included in the Form Fields. Usually this isn't a source for problems, but more of an opportunity for improvement because Liquid logic is supported in this field.

We also will look to see if it is forcing "fresh data" by calling a URL that returns randomized data every time. If it's external, we recommend switching it to ours: https://trmnl.com/custom_plugin_example_data.json.

Webhook

A webhook requires extra steps by the user that need to be outlined or linked to in the author_bio section of the Form Fields. Most commonly this is to a Github project page which has a detailed ReadMe (which we'll review for clarity and may even try).

Static

Rarely requires review unless other issues require us taking a look.

Plugin Merge

Make use of the plugin_instance_select form field to help the user select the proper plugin easily and that instructions are included in author_bio's description.

Markup

For maximum compatibility, we require recipes authors to prioritize using our design Framework and Liquid markup for logic first, only followed by CSS and Javascript when these reach their limit. Javascript-driven recipes can be unique and amazing when a recipe goes beyond text and images, so we don't want discourage that creativity.

Red Flags

These are items that will cause problems.

async API calls. Renderer will not wait more than 5 seconds; consider using Serverless or your own hosted middleware. 99% of the time, any API calls should be in your POLLING URLs section (you can have multiple URLs, one on each line).
Charting without using a unique class identifier.
Javascript that is waiting for page load rather than the event listener DOMContentLoaded.
Using the inline CSS property opacity, which gives a false sense of "working" in preview, but will not work well when rendered in 1-bit (black and white). Instead, use Framework classes like text--black 2bit:text--gray-30 4bit:text--gray-20 to target grayscale.
Custom fonts. For certain aesthetics, fine, but 9 out of 10 times you should stick to the fonts we provide and use for different Framework elements automatically. This ensures great legibility at different sizes.

Layouts

We preview every view (e.g. Full, Quadrant) across both TRMNL OG and TRMNL X in landscape mode, as well as TRMNL X in portrait mode, to verify the screen is mostly content, not whitespace. We also check if any data is getting cutoff horizontally or pushed off vertically unintentionally.

Most recipes that fail at larger sizes haven't taken into account our responsive classes (e.g. lg:or portrait:) as outlined in our TRMNL X Framework Guide or are not using Framework. Here are some of our favorite Framework tricks for great layouts.

Content Overflow

Make use of automatic length limiting with:

Variable level Liquid truncate
Line level data clamping
View level overflow, including table overflow

Charts

Rather than using a fixed height for your chart, setting height to null will let it fill its container, so you can control it using your other markup.

Using Liquid Templates

Liquid templates offer a great way to re-use content. However, any data used in the template needs to be passed into the template. This means that the trmnl native variables need to be passed in as well if you are using them in your template. For example: {% render "my_template", trmnl: {{ trmnl }} %}.

Flexibly Rearranging Content

Adjust the layout or flex direction in portrait mode. For instance, flex flex--row portrait:flex--col can quickly reflow your content. You can even stack responsive classes lg:portrait as noted in our docs.
Using grid and the grid--cols-# feature to reflow content. Here is an example:

<div class="layout">
  <div class="grid grid--cols-3">
    <span class="value value--small lg:value--base">Column One</span>
    <span class="value value--small lg:value--base">Column One</span>
    <span class="value value--small lg:value--base">Column One</span>
  </div>
</div>

Landscape mode looks fine.

Switch to portrait and we have collisions.

A quick fix could be to shrink the text in portrait mode using portrait:value--xxsmall, but that increases the whitespace dramatically.

But instead by using portrait:grid--cols-2 we get to actually increase the size and reduce the whitespace.

<div class="layout">
  <div class="grid grid--cols-3 portrait:grid--cols-2">
    <span class="value value--small lg:value--base">Column One</span>
    <span class="value value--small lg:value--base">Column Two</span>
    <span class="value value--small portrait:col--span-2 portrait:value--large lg:value--base">Column Three</span>
  </div>
</div>

The Little Things

We don't always notice these, and mostly they are nice-to-haves and not required for publishing.

If you use a title_bar, don't use the default TRMNL logo that is in our example docs, but instead use an image appropriate for the data source. Be careful with emoji, they often don't render as expected.
Using a static image inserted via a src URL? If you want to make sure that it always renders, you can encode it within the page rather than calling an external URL. Use our guide to inline images.
Keep things DRY [Don't Repeat Yourself]. The Shared view is a great way to accomplish this.

Featured Community Plugin - Today: Beautiful Date & Countdown

2026-04-21T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Today: Beautiful Date & Countdown

Community member med created the Today: Beautiful Date & Countdown plugin; here are their words on how it was created.

Why did you want this plugin to exist?

installing a date plugin on a TRMNL is almost a rite of passage. it’s one of the first things people reach for when they set up the device. if you’re going to look at something every single day, it makes sense today's date should be there. on a more personal level, i build because i'm obsessed with UX. i can’t not refine things. so taking one of the most common, simplest plugins possible and rethinking it through a design-first lens felt great :) a date is a tiny problem, but it’s also a perfect opportunity for my obsession to bring value to the people.

Why were you the person to make it?

you have my obsession to thank (or blame) for that.i can't look at something every day and not want to have it just perfect, especially when it's simple. simplest things are the most dangerous sometimes; they're very easy to accept as good enough.

Were you inspired by any other recipes or plugin creators?

since this was my first plugin, i spent a lot of time looking at what was already out there. there are some really solid recipes and a lot of creative approaches. i didn’t want to reinvent the wheel, i just wanted to reinterpret it through my own design lens.after building it, i joined the discord and was honestly impressed by the level of talent and experimentation happening in the community. great job guys.

What was your process for creating the plugin?

my process for most things creative is to sit down and figure out in an extensive way what problem(s) am i trying to solve and what would be the ideal solution. real life then comes into play and you try to keep and minimize the delta between the ideal scenario and the actual implementation to a minimum. in this example, a big notion for me was context. more than seeing the date, i wanted to get a deeper level of understanding of the context with just one glance.

What, if any, challenges did you face while creating it?

it was honestly pretty straightforward thanks to the awesome trmnlp tool. having live preview during development and being able to quickly switch between device sizes and settings removed almost all the friction from the process.when you have a clear idea of what you’re trying to build, having tooling that stays out of the way makes all the difference. it made the whole experience super pleasant from start to finish.

Did you learn anything you want to apply to future recipes?

the most important thing i've taken from this plugin is the dark mode dotted-matrix aesthetic that i’ve already started incorporating into my other plugins. i now have a daily unix tip, weather glance, and a world map “been there” dashboard; all matching this same visual language. i think it fits the trmnl purpose incredibly well. the high contrast works beautifully on e-ink, the dotted grid feels native to the device, and the whole control-panel vibe matches the audience using it. it’s glanceable, structured, and low noise.and yes… i am absolutely crazed about it right now :)

What is your favorite plugin that someone else created and why?

paperboy is the prime example of a perfect plugin for me. super cool idea, extremely clear signal, zero fluff. it does one thing and does it properly. big props to the author. the design probably looks effortless now, but i’m sure it took serious iteration to get to that level of clarity.

Making a Great Plugin the First Time

2026-04-20T00:00:00+00:00

Creating a plugin is an exciting way to use our Developer Edition license to bring your low-distraction dashboard to life with the content you want to see. Let's cover a few ways to get started; pick the one that fits you best.

The Copycat

You see a great idea, you aim to take it. Great! The spirit of TRMNL's open source core is to share our value with others, building a community on a foundation of generosity. Hundreds of authors have crafted a plugin, honed it, and published it as a recipe for others to install or fork. Here's a quick way to understand the difference:

Preview, Install, or Fork Buttons

Install: Use the plugin in your account, with customizations designed by the author, and maintain a link between your copy and the original recipe, so that any updates made to the original recipe will automatically be applied to your installation. This is similar to how apps in a mobile app store function.
Fork: Make a copy of the plugin, but with the ability to see exactly how it was made and have the ability to change anything, including the markup code that lays out the look and functionality of the plugin. The link to the original recipe is severed. This is the copycat way.

And don't think you need to copy a plugin with similar content. You may just love the way the content is laid out and can imagine your data in that same format. Don't like it after forking? Click Remove Plugin and go hunt down another one. Of course, if you'd rather get a robot to help you...

The AI Builder

Oh, you thought you could escape AI's ever-presence in the conversation?

Actually, you can, just scroll-down to the next section.

But... if you are intrigued, then let me introduce to our AI Builder, a collection of tools, prompts, and a dusting of hubris that takes a one-sentence request and $1 or two and turns it into a plugin that makes you go, "wow."

As mentioned in our helpful AI agent guide, once you opt-in to using the tool and get your API key assigned (so OpenRouter can track your usage and charge you), you can start creating a brand new private plugin, save your settings (e.g. name of the plugin), then head into edit markup. Once there, the shiny new Agent tab will be available.

Edit Markup header with Agent highlighted

Now, while it is ever evolving, it really shines in its ability to give you a great first draft of a plugin, even if you don't know where your data is coming from or exactly what you want it to look like. Just remember, there's a reason we recommend Claude's AI models; less expensive models can do an good job with additional guidance, but you're building your first plugin, so may be worth leaning on the model to do a lot of the heavy lifting.

If you prefer to keep the human completely in the loop, have you considered some light reading?

The Bookworm

You want some documentation. Pages of clear guidance and examples, because you need to understand it, and you know you're on the looooooong road to being a multi-recipe publishing, thought-leadin', creator fund earning TRMNL Expert.

We built our Framework with two core intentions: Create a design language for reliable and innovative rendering on an ePaper display, and give any developer, even the lapsed ones, superpowers. Like mobile-first design lead frontend developers through the mobile/desktop swap, our framework-first ethos can be interpreted as, "Design with Framework and Liquid first, then fallback to custom CSS and Javascript if you reach a limitation."

So dive into the docs or the examples, consume it all, and get building! Remenber that we also use Liquid and even have custom filters available.

Framework v2: Added responsive classes for larger displays and higher bit depths (more grays), redesigned our built-in javascript functionality for clamping, and expanded size variations across elements and components.
Framework v3: Added color through variants, hues, and new utilities, supporting colors beyond black and white.

Of course, maybe you would rather have your docs in more of a just-in-time fashion...

The Maker

You just need a process to get started, and a reference point for how to do the specific thing you want to do right now. You want to get started.

So you jump on our private plugins tutorial, you load the Framework docs in another tab, and you find an open API you can query without any authentication and get to work understanding by doing. Here's a simple set of guidelines to help you get comfortable:

Set your plugin to polling, save, then force refresh.
After a few seconds, click edit markup and scroll down to make sure data is populating in My Variables.
Build in the FULL view; the other views will be derivative of the full view so it's a great place to lock-in before you start migrating. This includes sticking all your Liquid logic (tutorial and advanced tutorial) in the FULL view, for now. In the future, to keep the code DRY [Don't Repeat Yourself], you can move the logic to the Shared tab. All views process Shared content prior to their own.
Start with a basic template:

<div class="layout">
  <div class="column">
  <!-- Show some data here -->
  </div>
</div>
<div class="title_bar">
  <img class="image" src="/images/plugins/trmnl--render.svg">
  <span class="title">Title Bar with Instance</span>
  <span class="instance">Production</span>
</div>

If the data source is an array of objects, then make a quick iteration:

{% for thing in yourVariableName %}
  {{ thing.id }}
{% endfor %}

Look over the data provided from your API and take notes about features you need to include, such as Form Field customization (visual editor), highlighting data, and date transformations.
Make some early layout decisions for the data. Will it be a grid, a list of items, columns (smart columns?), flex... (Framework docs). This can change later, and the easiest way to know it should change is to build something and hate it.

You're building in small pieces, then likely tearing away large chunks. You don't care, because you are learning and having fun.

The Designer

You've lived your life in layers, built elements through drag and drop, and you want that same experience within TRMNL. You want a Visual Editor.

Released in beta in April 2026, our visual editor offers a way to build new plugins or modify existing plugins (hello Copycat) with a design driven view, rather than a programmatic view, while both are available. Using the editor is optional, and the Designer can easily switch back and forth depending on their needs.

Final Thoughts

There is no wrong way to make a plugin... except to use custom css to lay everything out like you're working on your first website in 1998. Ignoring this advice is possible, but will lead to frustrations later. The learning curve is not steep nor is it high, but ignoring it is ignoring an opportunity to learn, which should never be squandered.

Introducing Companion for iOS

2026-04-13T00:00:00+00:00

businesses want portals, consumers prefer apps. it took us a couple years but today i'm proud to announce our new iOS app, TRMNL Companion, built by team member Liz.

Companion is not a mobile version of the web interface, it's a tool belt for Apple power users.

get the app

download Companion on your iPhone or iPad:
https://apps.apple.com/us/app/trmnl-companion/id6752111280

what Companion does

Companion offers a new way to build plugins, tapping into data sources that were previously inaccessible.

let's start with a few quick wins: Calendars, Apple Health, Apple Home, and Reminders.

Calendars

combine calendars without sharing permissions or ICS links. Companion lets you merge unlimited calendars natively through EventKit.

Calendar Sync

Apple data

want to build custom plugins with activity from Apple Health, sensors from Apple Home, or tasks from Apple Reminders? just create a private plugin ("Webhook" strategy), then point to it inside Companion.

Apple Data Sync

TRMNL will automatically push data to the plugin editor where you can design beautiful markup with Framework for a secure, private, personalized Apple dashboard.

Shortcuts

with a simple drag and drop interface inside any Apple product (phone, laptop, iPad) you may now access previously walled garden data from other apps (native or 3rd party) and use it in TRMNL plugins.

TRMNL Shortcut

create a Shortcut, add whatever triggers or data sources you want, then use "Send Data to Plugin" to bring it to life on your ePaper display.

for even more control, set up a Shortcut Automation to expand the triggers which cause new data to be sent to TRMNL.

Note Board by Mark Hopper

get started quickly with Mark Hopper's Note Board Recipe.

what Companion does not do (yet)

Companion does not let you manage Playlists, update your Account, or change Device settings. there is no dashboard or ability to browse community Recipes.

this may be possible in the future, but for now we're focused on what we do best: turning disparate data into dashboards that are calm, aesthetic, and useful.

read the help guide for more details about each feature.

Featured Community Plugin: Trending Recipes

2026-04-07T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Trending Recipes Plugin

Community member ExcuseMe (Discord: ExcuseMe) created the Trending Recipes plugin; here are their words on how it was created.

Why did you want this plugin to exist?

As someone who has published a couple of recipes, I found myself checking installs and forks more than once a day whenever I'd put something new out there. It's always exciting to see whether your idea, and your execution of it, resonates enough to earn a spot on someone's screen. But there was no easy way to see that momentum at a glance: which recipes are gaining traction right now, and how does mine compare? I wanted that feedback loop right on my TRMNL, not buried in a browser tab.

Why were you the person to make it?

I already had experience building a simple backend with a database for TRMNL recipes, and this plugin couldn't exist without one since it needs to take hourly snapshots to calculate deltas over time. But more than the technical side, I think it came down to scratching my own itch. I wanted a better way to track how my published recipes are doing while also keeping an eye on what the rest of the community is building. Once I realized nobody else was surfacing that kind of trending data, it felt like the obvious next thing to build.

How did you balance look vs functionality?

At the start, the data was clear: mainly the current connections and how they changed over the last x hours or days. It became harder to balance once the plugin started extracting statistics that weren't available before, like trending ranks, overall connection rankings, and user-level stats. Had this been just a private recipe, more numbers would have made it onto the screen because their meaning was obvious to me. But you can't expect that from a regular user. You also can't explain every number with just a little icon in front of it, and even if you could, that would look messy in a repeating section.

What was your process for creating the plugin?

It started with a small Python server in a Docker container that fetches all the public recipe data on a regular schedule, plus an endpoint to serve that data to a TRMNL recipe. AI is especially useful for these early steps to get a minimal viable product going, since the goal is to find out as soon as possible whether a recipe idea is even worth the time. From there, I build a simple version of the recipe using TRMNL's framework styling, just displaying the rough data to get a feel for whether it's on the right track. This one borrows from my Network Devices recipe: Columns with the overflow functionality to fill any screen with items, leaving little unused space; especially great when larger screen devices. After that it's refining. Add something, refine again; until you're happy enough to publish.

Did you learn anything that you want to apply to other recipes you create(d)?

One thing worth sharing is an SVG filter I picked up from L #1385, something I didn't even know was possible. Recipe icons are user-uploaded and can be full-color, which can render as muddy gray on a 1-bit or 2-bit screen. This hidden SVG filter converts colors to grayscale and snaps them to discrete levels, keeping icons crisp on e-ink:

<svg width="0" height="0" style="position: absolute">
    <defs>
        <filter id="binarize">
            <feColorMatrix
                type="matrix"
                values="0.0722 0.7152 0.2126 0 00.0722 0.7152 0.2126 0 00.0722 0.7152 0.2126 0 00 0 0 1 0"
            />
            <feComponentTransfer>
                <feFuncR type="discrete" tableValues="0 0.25 0.75 1" />
                <feFuncG type="discrete" tableValues="0 0.25 0.75 1" />
                <feFuncB type="discrete" tableValues="0 0.25 0.75 1" />
            </feComponentTransfer>
        </filter>
    </defs>
</svg>

Then apply it conditionally with CSS so it only kicks in on e-ink screens:

.screen--1bit .binarize, .screen--2bit .binarize {filter: url(#binarize);}

Any element with the "binarize" class gets its colors crunched down to 4 levels on the device, but renders normally in the preview.

Is there a tip you would give to a new developer?

Use a main template so you don't have to duplicate your code in each view for maintainability. What works well for me is to start by designing the full view of the recipe, then strip down the data as the views get smaller, or maybe change the layout between horizontal and vertical depending on the view. One of the best ways to achieve that is defining a template in your shared.liquid and calling render from each view. For example, in the full view of this plugin I just have this code:

{% render "main", trmnl:trmnl, recipes:recipes, user_recipes:user_recipes, user_stats:user_stats, global_stats:global_stats, timeframe:timeframe, columns:3, compact: false%}

All the data is passed as arguments (including the global {{trmnl}} variable), along with view-specific parameters.The columns argument defines the maximum columns per view, and the compact flag decides whether I need to limit the text inside the title bar.

What is your favorite plugin that someone else created and why?

Having recently set up a home media server, at the moment I would say it's Servarr Dashboard. A mashup combines Radarr and Sonarr into a single status report that's also useful for the rest of the family.

Creator Fund - March 2026

2026-04-06T00:00:00+00:00

for more context see the Creator Fund announcement.

our 6th payout rewards community contributions between March 10, 2026 and April 5, 2026.

source of funds

each payout period, a portion of developer-specific revenue goes directly to creators.

source	revenue	share	amount
Stripe Developer Edition TRMNL+ Shopify Developer Edition Clarity Kit (X) Clarity Kit (OG) BYOD	$3,420 $490 $931.84 $115,874.50 $19,717.98 $24,325.24	15% 80% 15% 15% 10% 10%	$513 $392 $139.78 $17,381.18 $1,971.80 $2,432.52
	$164,759.56		$22,830.28

source

revenue

share

amount

Stripe

Developer Edition
TRMNL+

Shopify

Developer Edition
Clarity Kit (X)
Clarity Kit (OG)
BYOD

$3,420
$490

$931.84
$115,874.50
$19,717.98
$24,325.24

15%
80%

15%
15%
10%
10%

$513
$392

$139.78
$17,381.18
$1,971.80
$2,432.52

$164,759.56

$22,830.28

note that Clarity Kit (X) sales were combined with all previous Clarity Kit (X) sales in celebration of Model X fulfillment which began on March 18. these additional funds are allocated to Plugin Authors only.

by the numbers

total payout: $22,830.28
plugin author share: $21,195.54 (70% of base total, plus accrued Clarity Kit (X))
strategic contributors share: $1,634.73 (30% of base total)

Firmware, 18%
3D Models, 6%
BYOS, 46%
Localizations, 7%
BYOD, 23%
Documentation/Resources, 0%

note that these allocations change monthly based on contributions by category.

algorithm?

candid feedback is welcome, email team@trmnl.com.