Skip to content

Lightweight Raspberry Pi / SQLite / Satori direction for Inker #21

@srsatt

Description

@srsatt

Title:
Hi @wojo-o,

First of all, I really like the idea of Inker. It is a very useful project, and it gave me a strong base to build on.

I have been running a fork because my use case is a bit different from the current direction: I want to host Inker on a small Raspberry Pi or similarly constrained homelab device, rather than on a full server setup with Postgres, Redis, and more moving parts.

To make that work for my setup, I’ve done a few larger changes in my fork:

  • Moved the local runtime from Postgres + Redis to SQLite.
  • Added Satori-based rendering, which dramatically reduced resource usage in my local testing compared to browser-based rendering.
  • Added support for more complex widgets based on the TRMNL framework.
  • Added JSX-style widget templates using TRMNL classes, so more advanced layouts can be written directly.
  • Added an MCP server for widget/data-source/screen operations, so AI agents can help create and iterate on more complex widgets faster.
  • Refactored the rendering service away from a large god-object style class into smaller focused services.

There are also several smaller QoL changes:

  • Download TRMNL fonts during init instead of keeping font binaries in git.
  • Add e-ink rendering settings for dithering/threshold behavior.
  • Add date tokens in data-source URLs, for example {today:Europe/Berlin}.
  • Improve custom-widget preview and validation so broken Satori/JSX templates fail earlier.
  • Add a better code editor for framework widgets.
  • Improve Satori compatibility for weather/framework widgets.
  • Add more tooling around debugging data sources and custom-widget rendering.

I think some of this could be useful to the wider Inker community, especially for people who want a lighter single-device/self-hosted setup.

That said, I do not want to maintain a long-running fork if these changes fit your vision for the project. If you are interested, I can open PRs either as one larger proposal or split into separate focused PRs, whatever would be easier for you to review.

P.S. here is the link to the fork https://github.com/srsatt/inker, feel free to take a look at it.

No pressure either way. This started as a pet project to make Inker work for my own setup, and I’m standing on the shoulders of your work here. I’d be glad if any of it is useful upstream, but I completely understand if some parts do not match the direction you want for Inker.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions