Hello there 👋

It's Ivan, and it's the end of the month again - time truly flies!

Warning: Unusual newsletter issue

As you probably noticed, I haven't published (m)any new learning materials in almost two months now. This is because I was head-down extending the platform's content authoring capabilities and enabling its use by trainers and university instructors.

And it's been going rather well!

Every content catalog on iximiuz Labs now has a new "community" section, and almost every day, a new tutorial, a challenge, or a custom playground is published. And these are all quality materials because one of my main goals for the platform is to keep the bar really high.

However, the more students, authors, and trainers the platform attracts, the more feature requests I receive. And by far the most frequently requested functionality is... persistent playgrounds.

As you probably know, iximiuz Labs playgrounds are fully ephemeral at the moment. You can enjoy up to 8 hours of uninterrupted uptime, but after that, the VMs are terminated and their disks are gone.

For many learning and experimentation use cases, 8 hours of VM lifetime is enough. In some cases, starting from scratch is even desirable, but having the option to "save" the work and continue from the same rootfs state the next day is a must. And the longer I'm postponing this work, the "louder" the user voices become.

Recently, the influx of requests for this (rather challenging to build) functionality has increased x10, and I've come up with a design that can potentially work out without a complete rewrite of the backend:

• For students, it'd allow shutting down VMs persisting their rootfs (in the traditional "Terminate vs. Shutdown" semantics of, say, EC2).
• For playground creators, content authors, and trainers, it'd allow using custom rootfs stored as container images in arbitrary registries (e.g., Docker Hub, GHCR, or even self-hosted).

The default 8h uptime limit will remain in place (because iximiuz Labs is not for production and/or background workloads, and humans rarely work for longer than 8h straight). But by the end of it (or after a long enough period of inactivity), the playground would "snapshot" its rootfs and shut down, allowing the user to restart the session with the exact same disk state later on. And "later on" can be on the next day, after a lunch break, or even right away.

A nice by-product of the design is the ability to use custom pre-baked rootfs (stored as container images) for playgrounds. It'll significantly speed up the startup for some playgrounds and also allow much more flexibility (e.g., more Linux flavors, full control over the playground machine names, users, you name it).

Even though it's a big enhancement that would require a significant engine redesign, I'm pretty sure I can build this in a month (more like in a couple of weeks, but doubling the time estimate for certainty). But this means that I won't be doing much content work for a few more weeks...

Traditionally, my main "marketing" channel has been the tech content I publish, and the fact that I haven't done it in two months has already started negatively affecting premium membership sales. Last month's $7K record revenue dropped to "just" $5K in April:

So, I came up with a wild idea. What if we try to crowdfund this new feature? Everyone who finds it valuable and wants to get persistent playgrounds on iximiuz Labs by this summer can purchase a premium membership, which will allow me to spend more time on feature work.

The deal is simple. If I can raise $3-5K for the persistent playgrounds work by the end of this week(end), I'd definitely go for it, and in a month, we'll have this fancy new capability. And if not, I can refund the premium purchases for everyone who has bought it only because of this particular functionality.

I already "announced" this idea yesterday on Discord, Twitter, and LinkedIn, and to my surprise, it worked out!

I'm keeping my fingers crossed for the successful ending of the campaign, but it's actually not unrealistic at all. To hit the lower end of the range, I only need to sell 10 more lifetime premium memberships. And if we hit the upper end of range, I'll try my best to also ship the second most requested feature - the 6.1 kernel upgrade 🙈

Go, indiehacking, go!

What I was reading

​Cap or no cap - A short note by Rory McCune on peculiarities of Kubernetes' handling of allowPrivilegeEscalation: true|false flag, and different ways to spell (and misspell) capabilities (e.g., CAP_SYS_ADMIN vs. SYS_ADMIN). Interesting, that containerd and CRI-O clusters behave differently! And I’m particularly happy that Rory used my K8s Omni playground to test it - this is one of the canonical use cases I designed it for.

​Kubernetes Multicontainer Pods: An Overview - Kubernetes Blog - A short but helpful post on the multi-container nature of Pods, that in particular touches upon the "native sidecars" and four related patterns: init container, ambassador, configuration helper, and adapter.

​The "S" in MCP Stands for Security - A catchy title and a good set of examples when/why MCP is insecure. But I’m not sure I agree with the conclusion. I’m no AI expert, but my gut engineer’s tells me that no bolt-on security mechanism such as authN/Z, MCP “scanners”, or similar can “fix” MCP. Simply because the issue is much more fundamental and lies in the inherently dangerous idea of “autonomous” agents performing uncontrolled actions on critical systems. Until the prompt injection problem is solved and LLMs stop being so gullible (which may not even happen on our timeline), granting full access to any critical system to an agent is plain recklessness. The more constrained the agent’s execution environment is, the better.

​Model Context Protocol has prompt injection security problems - Simon Willison's response to the above post: "The big challenge here is that these vulnerabilities are not inherent to the MCP protocol itself - they're present any time we provide tools to an LLM that can potentially be exposed to untrusted inputs." Simon's post confirms my gut feeling that the problem has nothing to do with MCP. The post ends with a few recommendations on how to minimize the risks (but unlike Simon, I'm less optimistic and much more paranoid about running any MCP servers on my primary systems and/or with access to sensitive data).

​Everything Wrong with MCP - Even though at this point it may start looking like I'm just bashing the new tech, this article is actually written by an MCP proponent (despite its title). I found it helpful for better understanding the role and limitations of the MCP servers. Yes, they are insecure by design, but you can probably say the same about any technology, including pretty much all programming languages. Even though we can perform insecure system calls or write incorrect programs, it doesn’t stop us from using them. So, there is a justified use for MCP servers, too. You just need to understand how NOT to apply the tech, and this post talks about exactly this.

​How to Build an Agent - The question of how LLMs "call" tools has been puzzling me long enough, and this post, in particular, sheds light on it (in very simple terms): 1) You tell the model what tools are available; 2) When the model wants to execute the tool, it tells you; 3) You execute the tool and send the response back. And it all happens in plain text (via prompts and replies). I should buy some duct tape making company stocks, the world will soon run out of it.

​github.com/lusingander/stu - S3 Explorer TUI. Haven’t tried it yet, but it looks nice. When I need to browse my S3 (or rather R2) buckets, maybe once a quarter, I always feel like a tool like that would be really helpful to have around. But I always end up using the official web console with a traditionally sucky UX.

​A Sneaky Phish Just Grabbed my Mailchimp Mailing List - No one is immune if even Troy Hunt himself got phished. Stay alert and vigilant at all times (and when you start feeling like yielding, better take the rest of the day off or stay away from critical systems and/or comms).

​The Reality of Tech Interviews in 2025 - The Pragmatic Engineer - A very looong article about the apparently much tougher reality of the current job market with good preparation advice (tactical and strategical). Gergely Orosz has always been serious about the quality and trustworthiness of his posts, so give it a thorough read if you're looking for a new job. But IMO, at all times, skills have been the most important differentiator, so if you want to truly stand out, go practice 😉

Wrapping up

That is it for April. It was a fruitful month for the platform, and things are just starting to accelerate! 🚀

Happy hacking!

Cheers

Ivan

​