Engineering leader and open source maker. Tech Lead at Meiro. Building tools in Rust, Go, and Python. Zola 2026-08-11T10:00:00+02:00 https://rbas.cz/atom.xml 2026-08-11T10:00:00+02:00 2026-08-11T10:00:00+02:00 Unknown https://rbas.cz/blog/why-i-started-building-fomkee/ <p>I have tried to build monitoring tools several times during my career. Most started with an immediate need, solved part of it, and stopped there. <a rel="noopener external" target="_blank" href="https://fomkee.dev/">Fomkee</a> began in much the same way—but it was far from my first attempt.</p> <h2 id="before-fomkee">Before Fomkee</h2> <p>I have always enjoyed infrastructure. I used to be a co-owner of <a rel="noopener external" target="_blank" href="https://rosti.cz/">Roští.cz</a>, a Czech hosting company, and before Fomkee, I maintained servers for another company. That was where I built my first proper monitoring system.</p> <p>I called it SIMO, short for Simple Monitoring. Its collector is <a rel="noopener external" target="_blank" href="https://pypi.org/project/simocollector/">still available on PyPI</a> under my username, <code>rbas</code>. It was a Python script that ran on monitored servers, collected data about load, disks, processes, and other system state, and sent everything to a central server.</p> <p>The central component was a web application—built with Django. It displayed the collected data and managed notifications and escalation policies. You could configure what should happen when a particular condition was met.</p> <p>That was around 2014. The software is ancient now, but the problem it tried to solve is still very familiar.</p> <h2 id="monitoring-the-monitoring">Monitoring the Monitoring</h2> <p>A few years ago—I honestly cannot remember exactly when—I built a home lab server. Since then, the number of things running around our house has steadily grown: services on the server, ESP devices doing various jobs, sensors submitting data, and small displays showing information we find useful.</p> <p>I have built enough gadgets around the house that debugging our home sometimes feels like being on call for a small company—except the users know exactly where I sleep.</p> <p>At first, my wife said many of these inventions were useless. Then she got used to them. Now, when one stops working, she immediately complains that it is broken. Apparently, a useless gadget becomes critical infrastructure the moment it goes offline.</p> <p>That is not how monitoring should work.</p> <p>Ideally, I should know first and fix the problem before anyone notices. At the very least, when my wife tells me something is broken, I want to say, “I already know,” with the calm confidence of someone who definitely was not about to discover it for the first time.</p> <p>So I installed <a rel="noopener external" target="_blank" href="https://uptime.kuma.pet/">Uptime Kuma</a>. It is a nice piece of software: ready to use, easy to configure, and good at its job.</p> <p>There was just one obvious problem. It ran on the same home lab server as everything it monitored. If the entire server went down, the monitoring disappeared with it—and I knew nothing.</p> <p>That led me to build <a rel="noopener external" target="_blank" href="https://github.com/rbas/fluxa">Fluxa</a>. Fluxa is intentionally small. It runs HTTP checks defined in a configuration file and sends me a push notification through Pushover when something goes wrong. In my setup, its main job is simply to check whether Uptime Kuma is still alive.</p> <p>I had a lot of fun writing it. This was before AI-generated code became a normal part of development, so I wrote it by hand in Rust. I also tested it with more than a thousand monitored websites, checking each one every 30 to 60 seconds. Its memory footprint remained very low—even lower than Uptime Kuma’s—and I was genuinely happy with the result.</p> <p>Fluxa did what I needed, but I kept thinking about how I could extend it. I never had enough time, so the idea stayed in the back of my mind. Eventually, it became a slightly different question:</p> <p>What if I built a proper monitoring system in Rust?</p> <h2 id="why-rust">Why Rust</h2> <p>Part of the motivation was simple: I like Rust.</p> <p>I enjoy its strictness and the way it makes error handling explicit. Rust asks you to write more code up front and think about the unhappy paths, not just the happy one. It can feel verbose, but it also makes me trust the result more.</p> <p>One thing I have learned during my career is that production code is mostly about what happens when things do not go according to plan. A network request fails. A service disappears. An input is not what you expected.</p> <p>Rust makes it difficult to quietly ignore those cases, which makes it a great fit for monitoring software.</p> <p>When I started designing Fomkee, I returned to the problem I had with Uptime Kuma: who monitors the monitoring?</p> <p>A single monitoring server can disappear along with everything around it. So I designed Fomkee around multiple nodes. These nodes should be small enough to run on cheap hardware and lightweight enough to deploy in several locations without much effort.</p> <p>The project kept growing from there. Fomkee can now run checks across multiple nodes with a relatively small footprint, and it is getting close to a public beta.</p> <p>For HTTP checks, I also added the option to evaluate responses using JavaScript. I wanted an excuse to experiment with WebAssembly, so the JavaScript checks run inside WASM. It is a useful feature—but it was also fun to build, which remains an important reason why I work on the project.</p> <p>That is more or less how Fomkee began. It grew from a real problem in my house, the enjoyment of building Fluxa, and my curiosity about what a monitoring system designed around Rust and small, distributed nodes could look like.</p> <p>I think it could be useful to other people too. A few people around me have already tried it and told me it helps them, which gives me a good reason to continue.</p> <p>For now, I am working toward the public beta and seeing where the project takes me.</p> 2026-08-11T09:00:00+02:00 2026-08-11T09:00:00+02:00 Unknown https://rbas.cz/blog/why-i-am-starting-this-blog/ <p>I’ve spent more than fifteen years building software, across startups and scale-ups and on teams spread from Prague to London to Singapore. In that time, my work has gradually shifted from writing every line myself to helping teams make good decisions and ship good software.</p> <p>But I’ve never stopped building.</p> <p>I still like turning a small frustration into a useful tool. That is how projects such as <a rel="noopener external" target="_blank" href="https://github.com/rbas/roxy">roxy</a>, <a rel="noopener external" target="_blank" href="https://github.com/rbas/fluxa">fluxa</a>, and <a rel="noopener external" target="_blank" href="https://github.com/rbas/jsonify">jsonify</a> began. I want a place where I can write about what I am building, the decisions behind it, and the things I discover along the way.</p> <p>Some of that will be about open source. Some of it will be about <a rel="noopener external" target="_blank" href="https://fomkee.dev">Fomkee</a>, which I have been working on for quite some time now. I want to share not only what I build there, but also the thoughts, experiments, and technical decisions that shape it.</p> <p>Mostly, though, this blog is somewhere to dump what is on my mind: problems I am thinking about, things I am trying, and lessons from work that might be interesting to other developers. It does not need a grand theme or a publishing schedule.</p> <p>Maybe I will write only a few articles. Maybe I will keep going for years. I honestly do not know yet. For now, I just want to start writing and see where it goes.</p>