TRMNL: Blog

State of BYOD

2026-05-26T00:00:00+00:00

thousands of people have built their own TRMNL device. last week we shared a survey to better understand the BYOD ecosystem, below are those results and what we're doing about it.

ease of setup

of 230 responses, 135 purchased a BYOD license. this is not necessary if you want to go fully open source (BYOS), but i'm glad we can bifurcate results by this answer. you'll see why in a bit.

1 - difficult; 5 - easy

the majority (54.9%) of license holders said it was easy to set up their device, but i want this metric to be at least 70%.

insight: create smarter (device model specific) onboarding versus general guides.

does size matter?

here it appears we're already in the sweet spot.

Interest by display size

although 43.1% of responses are seeking devices larger than 11", that number drops to 35% when considering only BYOD license holders. i think can be explained by how prohibitively expensive displays become past the ~13 inch threshold.

a license holder is aware of ePaper price jumps, a non license holder may not be and is living in fantasy land. which is OK, we live there too. let's be neighbors?

larger displays are also a lot more complex to set up. as your screen interface jumps from SPI to parallel, driver boards change, so does power consumption, and of course so does the enclosure needed to fit it all. designing a 3D printable case for a large display would be a 20+ hour print and require multiple joints to connect disparate pieces.

insight: focus on 7.5 - 13.3" displays. if you need something much bigger, stay tuned for an announcement later this Summer.

ecosystem compatibility

this was a curious set of answers, inconclusive from a prioritization standpoint and an obvious indication that we (i) do a poor job communicating the myriad devices already supported.

Demand by device

insight: ask this question again after increasing ecosystem visibility.

quickstart wishlist

for the impulsive shopper i wanted to understand which singular optimization might have swayed their purchase decision. we're not in the business of selling things people don't need, but we are in the business of creating aha moments.

What would help you get started?

here we'll look at only non BYOD license holder responses. a whopping 58.8% said a Free Trial would have helped them make a decision, whereas only 41.9% of license holders would have preferred a free trial.

and nearly double the number of license holders (31.8%) prefer better documentation to non license holders (17.6%). this makes sense given you don't know the strength of a guide until you actually try to follow it.

insight: implement a free trial or interactive demo.

open-ended requests

this is the most valuable part of the survey because it's a bummer to read. below are a few random examples, copy/pasted verbatim, along with our reaction.

Request	TRMNL note
Amazon Kindle (jailbroken)	already supported [1, 2]
android tablets	already supported [1, 2]
Inkplate	already supported [1]
Tidbyt	already supported [1, 2]
Apparently the Raspberry Pi repo does not support E-Ink displays last time I checked. If this is still the case, I’d love to see support for that case (please). I’d like to get a Pi and a big e-ink screen and put them together	already supported [1, 2]
Full color epaper displays	already supported [1]

clearly we have an education problem. a deep rabbit hole does no good if it's hard to find.

insight: make it easy (+ fun) to figure out which household devices can run TRMNL.

what's next

Larry Bank leads our BYOD effort. for an introduction to some of his impact at TRMNL see here and here and here.

Larry can reverse engineer and improve just about any device <> display combo, making it TRMNL friendly and power efficient.

for the past several months we've expanded our BYOD offering largely on a set of hunches, mine and his, about what people want. today we're beginning to mix those gut decisions with community feedback.

to the thousands of customers who purchased BYOD licenses, thank you. a portion of your funds go directly to TRMNL Creators and your live chats, public reviews, and emails will continue guiding us.

to prospective DIY-ers, stay tuned for better docs, faster and risk-free demos, and less digging around our website to figure out if the device in your hand is TRMNL compatible.

for all the raw data used in this post, go here.

Featured Community Plugin - Brick Storage

2026-05-19T00: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.

Brick Storage

Community member Daniel Boberg created the Brick Storage plugin; here are their words on how it was created.

Why did you want this plugin to exist?

I built Brick Storage to track my LEGO collection. Market values, ROI, what's gaining value. But I kept opening the app just to glance at my portfolio total. When I got my TRMNL, it clicked immediately: this number belongs on my desk, updating quietly, not behind a browser tab. A passive, always-there glance at your collection's worth. No login, no app, no notification. Just the data, on e-ink, beautiful.

Why were you the person to make it?

I'm a LEGO collector who couldn't find a tool that treated collections like real portfolios so I built Brick Storage myself. It started as a side project for tracking my own sets, and grew into a platform with 25,000+ sets, live market data from multiple sources, and a small but passionate community. When my TRMNL arrived, the first thing I wanted to see on it was my collection's value. I'm not just the developer, I'm the first user. Every feature exists because I wanted it on my own desk first.

How did you balance look vs functionality?

Data first. On e-ink you don't have color or animation, so the information hierarchy has to carry everything. I spent most of my time figuring out what to show vs. what to cut. The portfolio view packs a lot into one screen (value, ROI, sparkline, top performers), but it only works because TRMNL's CSS framework handles the typography well. For the random discovery view I let the set image do the heavy lifting and kept the text minimal.

What was your process for creating the plugin?

I already had the full data pipeline running on Supabase. So the plugin was mostly about building a new rendering layer on top of existing data. I wrote the markup endpoint that generates HTML for all four TRMNL sizes. No Liquid, no external template engine. Just raw HTML strings with TRMNL's CSS classes.

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

Start with all four layout sizes from day one. I built the full view first and then had to rethink everything for half and quadrant. If I'd designed quadrant first, the full view would have come together much faster. Small screen first, then scale up.

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

Use the TRMNL CSS Framework classes instead of writing custom styles. I wasted time with inline CSS before realizing the built-in classes handle e-ink rendering way better. Also, test with actual data early. The preview on trmnl.com looks different from the real device, especially with images and contrast.

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

The YouTube Stats plugin. Simple idea, clean execution. Subscriber count and recent video stats on your desk without opening YouTube Studio. It's the same principle I follow: Data you check too often deserves a passive e-ink display.

Do you have a LEGO addiction?

My TRMNL shows my LEGO portfolio at all times. I caught myself rearranging my desk so it's the first thing I see in the morning.

Model X Progress Report

2026-05-19T00:00:00+00:00

We introduced X on July 30, 2025. We began assembly + fulfillment on March 18, 2026. Below are live updates since launch.

When will I receive my TRMNL X?

Live in USA, Canada, India, Mexico, or Australia?

Your TRMNL will ship from our USA warehouse. Due to lost freight this warehouse is short some case components, see ”May” section further down this post for more details.

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

Your TRMNL will ship from our Berlin warehouse. Due to Customs issues and supplier theft, this warehouse has only received some case colors and did not receive magnets until May 21. See “May” section further below for more updates

Magnets are here!

Both warehouses have strong (N52 grade) magnets. USA has been shipping with them since April 26 and is further ahead in its order queue. Magnets arrived at our Berlin, Germany warehouse on May 21.

*For more details about magnet issues see the March and April sections further down this post.

Estimating queue <> delivery timeline

Each warehouse is shipping ~50% of X orders, so if your spot in the queue is 4,000, it's actually spot 2,000 from your respective origin. As of May 20 we’re shipping 400-500+ devices per business day.

So if you're in the USA and your spot is 4000 => 2000, your order will ship in around 10 business days. The (big) caveat here is your device color. USA and Germany have been receiving expedited re-shipments of lost freight which includes charing docks and wall mounts.

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

Between May 2-6th the USA warehouse was 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.

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.

May 19 - USA warehouse is still waiting for white + gray docks and thus cannot ship those colors, despite having all the other parts. These were lost in transit and a new batch has been sent by our supplier.

May 21 - Berlin, Germany warehouse received a batch of N52 magnets. They are now shipping black, sage, clear.

May 27 - Berlin, Germany warehouse received white u-mounts and is now able to ship white devices.

May 29 - USA warehouse received missing white charging docks and is finally shipping white devices.

Vibe Coding a $20k /year Enterprise Logistics Platform

2026-05-15T00:00:00+00:00

most startups are founded in big cities with expensive rents. TRMNL started in a basement in the middle of nowhere and later moved to my barn.

with unlimited space it made sense to fulfill in-house and create an assembly line and open a 2nd warehouse. what did not make sense was writing a bunch of courier API integrations.

so last April we signed an annual contract to use ShipHero's fulfillment software at our warehouses in Georgia and Germany. it worked OK but wasn't great.

support tickets often ignored
mobile layouts are non-existent
web portal is split across 2x domains with poor SSO between them
it's generally ugly (we value aesthetics)
on March 31, 2026 it stopped working at our Berlin warehouse

the last point was our breaking point. for weeks we tried being helpful to our account manager and ShipHero's support team. first they gaslighted us, saying it was normal for postage that usually costs $12 to now cost $140. then a few of my emails landed in their spam. finally they said they're "looking into it." insert the Jennifer Lawrence meme.

when they stopped replying to our messages we decided to replace ShipHero with Claude. and holy crap, it worked.

AI responsibility disclaimer thing

everything you'll see below could have been done by our team, by hand. but what's the point? nobody was put on this earth to read FedEx documentation.

if it ain't broke...

ShipHero provided us 2 essential functions:

adding holds + notes to orders
shipping packages

here's the ShipHero order feed.

ShipHero Orders - we canceled so it's empty

and here's the ShipHero shipping feed. when you click an order it helps you pack + buy postage.

ShipHero Shipping - click an order to pack

each of these interfaces is fine. support engineers use the first one to tweak orders, and the warehouse team leverages those notes while packing.

now let's rebuild it all with $100 in tokens.

high fidelity mockups

we took screenshots of each portal and fed them to Claude Design the day it launched. here's the Order edit page, with fake data of course. sorry Pat Sterling.

Order management

what's particularly impressive is how Claude figured out the "click item on left, item moves to the right" shipping portal UX. we did not offer before/after states.

ShipHero + Claude Design

this may not win awards but it's perfect for our needs.

part of that need was inertia-friendliness. more than a dozen team members developed UI/UX muscle memory from shipping things the Old Way. for a successful same-day switchover you don't want anything to feel new.

scope creep

if a bunch of people depend on a tool and you replace it overnight, prepare for a barrage of feature requests. to mitigate only a couple of us had permission to file tickets or touch the code.

our ShipHero contract was set to renew on May 1 so D-Day was April 30. after some margaritas and gas station snacks we swerved into the critical path: deploying live API integrations with UPS and FedEx. DHL and USPS came a couple weeks later. until this point we worked in sandbox environments but now we required live postage rates to resume fulfillment the following day without downtime.

some courier JSON payloads are upwards of 1,000 LOC thanks to our "hazardous materials" status and the dozens of countries we ship to. this step was the most supercharged by LLMs. if we had to write these integrations by hand it might have made more sense to pay ShipZero for another year of shoddy service.

GH Issues → Production

filing async tickets for Liz made our rollout as calm as possible. we even had time for Whataburger and a walk around Callaway Gardens.

build methodology

to actually write the code we used Claude (CLI) and the Superpowers skill:
https://github.com/obra/superpowers

Superpowers takes a Socratic approach with seemingly endless loops of clarifying questions to determine exactly what you want. where it really shines is architecture.

i personally enjoy architecture design and admittedly we had a head start: observing ShipHero's nouns and verbs for a year. one of the harrier aspects in my opinion was multi-warehouse support and determining which objects should support null friendly foreign keys.

another great Superpowers feature is tests. lots and lots of tests. there is probably room for a new term like Clanker's Harness which states that slop is 80% as safe as it is tested.

big shout out to Jesse Vincent for creating this systematic approach to turning huge projects into chewable nuggets.

final product

shipping physical products requires 4x6 postage labels. we built a network printer utility in Swift that spits out packing slips and shipping labels from any computer to any thermal printer at either of our warehouses in 1 click.

Setting up shipping stations

next you'll want to filter orders for shipment based on priority, what's in stock, and whatever other logistics challenge you may be contending with that day.

Filtering orders for shipment

once an order is selected, WebSockets lock it to that warehouse team member to prevent another person from creating a double shipment.

if the same person places multiple orders they're bubbled up in a Merge Orders interface where we can save on postage fees and reduce customer confusion.

Merging orders from the same customer

when you're ready to ship, clicking SKUs on the left side loads up a package on the right side. for bulk orders we can instantiate multiple boxes and print unique labels + packing slips for each one.

Packing + buying postage

other wild features

logistics is not as simple as "get money, ship device."

pending the customer's location, line items, or special requests, we may need to adjust details on the fly regarding including where the order is shipped from, which courier/method is used, Incoterms, and many other details.

Automation Rules

for this we built Automation Rules. it leverages the same infrastructure as our Serverless function, allowing us to finesse orders automatically following webhooks from our storefront.

here's one such rule which sets US-origin shipments to either UPS Ground or UPS SurePost pending the SKU and customer location.

Automation Rule - UPS Method

we can write these rules in Python, Ruby, or Node. Clicking "actions" on the right side injects the relevant return values for the parser. it's flexible and easy to simulate outcomes with a Test Rule and Execution Log below the code editor.

even more features not depicted:

SKU and Box management with HS codes, Customs Invoice setters, and weight/dimensions
Carrier and Storefront CRUD with wholesale partner CSV import
User management with roles/permissions
Payroll automation
Firmware flashing and PCB provisioning, detailed further here

by the numbers

we (Liz) spent 80-100 hours building this, then another week on-site to deploy and live debug with the USA warehouse team. our German warehouse was up and running the following Monday.

using ShipHero we sent 30,000+ packages for about $0.76 each. accounting for ongoing maintenance to this platform, that cost should decrease by 2-3x. it's also much, much better than ShipHero. pages load faster, labels print faster, filtering is more powerful, there are no contracts, and we own it.

what this means

from a customer perspective, TRMNL switching logistics platforms is a distinction without a difference. from ShipHero's perspective this should be a wakeup call.

enterprise software providers who don't take their responsibility seriously and rely on 10 page legal contracts to prevent churn deserve every bit of pain that a smart person with a subscription to an autocomplete CLI can incur.

if you have a need for hackable 3PL software, let us know and we might open source ours. it's kind of what we do.

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.

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.