Made a status page tool, almost no configuration (a few environment variables), ready to drop in compose.yaml. If you run Podman but don’t receive status alerts yet, try setting Yoself up, it should be relatively easy.

1. To monitor Podman, add volume /run/podman/podman.sock:/var/run/docker.sock. To check if an external website is up, add SERVER_EXAMPLE=https://example.org/.

2. To send alerts, set EMAIL_STATUS=admin@example.org and SMTP_{HOST,PORT,USER,PASSWORD}.

3. To generate a static page, set STATIC_HTML=/home/user/public_html/yoself.html. To only monitor containers and/or servers, but not host, set MONITOR_HOST=false.

Intended usage: One instance on each server whose containers you want to monitor. Another one (static page) on the server that checks if your main servers are up.

How it looks like: https://yoself.nykula.com/

Why?

I work with a few servers with Podman containers. Some containers have health checks defined in their Containerfile or my compose.yaml. Some don’t include binaries neccessary to implement health checks; but to see if they work, it can be enough to query their HTTP API.

A server may experience load spikes and is sometimes close to running out of disk. Finally, a server may periodically become inaccessible because of network issues.

My goal is to get emails about server health events, with very little configuration per server. And to have an overview of what stands out, without deep insights (for detailed information, I’ll ssh anyway). Ideally with one tool for it all.

The static page is needed because I only work part-time and don’t have money to rent an extra VPS. For monitoring my main VPS, I use a shared system that lets users run apps in background and publish HTML pages.

Alternatives with similar features:

• Docker/Podman monitoring capability: Beszel, Simon, Uptime Kuma.
• Docker/Podman container auto-discovery: Beszel, Simon.
• Website monitoring: cState + monitorbot, Statping-ng, Uptime Kuma.
• Public, world-readable status page: cState, Uptime Kuma.
• Single container image: Simon, Uptime Kuma.
• Host usage monitoring: Beszel, Simon.
• Periodic refresh but not real-time: Uptime Kuma.
• Powered by Node.js: Uptime Kuma.
• Haven’t researched yet, learned today: Gatus.

Non-goals, their features that Yoself doesn’t have:

• Settings UI: Beszel, cState, Simon, Statping-ng, Uptime Kuma. (I want compose.yaml and/or .env to be the entire config, possible to keep in Git with version history.)
• Split monitoring and overview services: Beszel, cState + monitorbot.
• Large, detailed charts: Beszel, Simon. (Yoself is just two screens.)
• Private dashboard: Beszel, Simon. (Yoself is userless.)
• Key auth between servers: Beszel.
• Multi-user management: Beszel.
• Description of current incident. (If needed, I can make Yoself show recent RSS from Mastodon.)
• TCP, DNS, ping: cState + monitorbot, Uptime Kuma.
• Years of history: cState. (Yoself logs expire after 31 days.)
• Live metrics: Beszel, Simon. (Yoself periodically refreshes, but not every second.)
• Reading container journal on the web: Simon.
• File management: Simon.
• Telegram, Slack, Discord etc: Beszel, Simon, Uptime Kuma. (Plain text e-mail is enough for me.)
• Lightweight, written in compiled language: Beszel, cState, Simon, Statping-ng.
• Custom styling: Statping-ng.
• Regex matching of website responses: Statping-ng. (Yoself supports JMESPath.)
• Frontend using React or Vue: Beszel, Simon, Statping-ng, Uptime Kuma. (I use Preact with my SSR/ORM library EviKit, about which I wrote recently.)

Would be nice, but wasn’t a strong need to implement yet:

• Weblate for continuous translation: Beszel, Uptime Kuma. (For Yoself, I edit Ukrainian .po using Poedit.)

Upd: re-read the rules and added [CBH] to title as per Rule 8. I didn’t use LLMs when coding this project, as evidenced by my commit history on Codeberg. Developers of dependencies do use LLMs, though.

I like the full-stack framework SvelteKit. It inspired me to write something more minimal, even brutalist, based on Preact, a few small focused modules popular in its ecosystem, and Vite.

There’s intentionally not much API. Documentation entirely fits in a long but straightforward README. Like the Django tutorial, it guides you through writing an application using all the primary features of the EviKit framework.

I wanted to use standard modern JavaScript as supported by Node.js 24+ directly. With strict JSDoc type annotations. So no separate language server is needed - you can use Emacs, Kate or any other modern editor of your choice that supports typescript-language-server. Linting using ESLint and Prettier also works without extra plugins.

There’s neither JSX nor a new templating language to learn. There are JS helpers for creating common elements, e.g. you write p({ class: "nav" }, a({ href: "/" }, "Home")). You use JS map for loops and ternary operator for conditional constructs.

I focused on old-school urlencoded and multipart forms, and the app is rendered on the server, so apps should remain partially accessible even when JS doesn’t load. At the same time, an EviKit app is a proper SPA, hydrated with client-side routing (with URLPattern-based server-side counterpart) and conveniently made dynamic with React-style hooks.

I want to ease the writing of bots and interoperability with low-code tools. So apps generate OpenAPI (Swagger) specification for your API.

Input/output validation using Valibot is first-class. Type checking catches if e.g. after an upgrade your API starts returning something different from your declaration. With less need for boilerplate unit tests, you can focus on end-to-end replication of real user scenarios.

Most apps need databases. Why not try the node:sqlite built-in? I made it easy to declare a schema using the same Valibot helpers that I use for API declaration. EviKit keeps the database in a standard location following the XDG specification. You can save file uploads as SQLite blobs.

Translatable strings of your UI can be automatically extracted using GNU Gettext tools, well-known in Django, WordPress and Linux desktop app ecosystems. I recomment the Poedit editor for translating the resulting .po files. Your app is shown in the browser language if there’s a matching translation, with English fallbacks.

For styling, I wanted to avoid non-standard hacks that make Node.js “import” CSS, so I recommend going with daisyUI and the now usual Tailwind CSS.

There’s a real-world FOSS app using EviKit: Lanquiz, that lets you import Kahoot quizzes and self-host them in LAN from a laptop during blackouts.

Non-goals: cloud deployment (I only target VPS and LAN apps), competition with Pracht scope (I guess there are bugs to fix, but the framework is more or less finished).

Last but not least, no “AI” whatsoever was used for writing the framework. I don’t have a hardline stance, it’s more that I don’t see how it could be useful for this tool. LLMs let people come up with ever mode code and boilerplate, while I want radically less of it. If you’d like to contribute, let’s keep it simple and human.