Why Everything is SaaS: Reclaiming Open Source with Alpine and Distroless

The Grand Absurdity: Why Is My Video Editor a Subscription?

Welcome, fellow digital travelers, to the age of the “Everything-is-a-Service” apocalypse. I was browsing the r/opensource subreddit recently—specifically a thread from November 5, 2025—and the collective frustration was palpable. One user asked a question that hit me like a poorly configured load balancer: “Why is everything a SaaS nowadays?”

It’s madness. Absolute Edan tenan! We’ve reached a point where tools that used to live happily on our hard drives have moved into the “cloud,” which is really just someone else’s computer with a monthly billing cycle. As the Reddit thread pointed out, developers are now asking why they need to host a video editor and open it in a browser just to trim a few frames. Why are we sacrificing local performance for the privilege of self-hosting a Docker container that mimics a website? This is the paradox of modern open source: we are “freeing” our software by putting it into cages that require a high-speed internet connection and 16GB of RAM just to run a GUI.

We’ve been sold a bill of goods. The convenience of SaaS (Software as a Service) has become a velvet-lined trap. But don’t worry, your favorite Wong Edan blogger hasn’t given up hope. To reclaim the spirit of open source, we need to understand the architecture of our chains. We need to talk about the stack, from IaaS to CaaS, and eventually, the minimalist salvation of Alpine and Distroless images.

The Hierarchy of Needs: IaaS, PaaS, SaaS, and CaaS

According to the gospel of Google Cloud, the modern application landscape is divided into several layers of “As-a-Service” models. Understanding these is critical if we want to dismantle the bloat. Let’s break it down before we get into the technical weeds:

• IaaS (Infrastructure as a Service): The raw iron. You get the virtual machines, storage, and networking. You manage the OS, the runtime, and the data. It’s like buying the bricks to build a house.
• PaaS (Platform as a Service): You provide the code; they provide the platform. It’s a bit like renting a room in a hotel where the utilities are handled, but you still bring your own suitcase.
• SaaS (Software as a Service): The entire application stack is provided to you. You are just a user. This is the video editor in the browser. You own nothing, you control nothing, but you pay for everything.
• CaaS (Containers as a Service): This is the middle ground where the magic happens. As Google Cloud notes, the evolution of architectures has led to the emergence of CaaS. It allows developers to deploy and manage containers, which should—in theory—give us the portability to escape the SaaS trap.

The problem is that even our containers have become bloated. We are building “mini-servers” inside our containers that contain an entire operating system’s worth of garbage just to run a single Go binary. That’s not efficiency; that’s insanity.

The Minimalist Rebellion: Alpine Linux

If we want to reclaim open source, we need to stop building containers that look like 2010-era virtual machines. Enter Alpine Linux. For a long time, Alpine has been the darling of the Docker world, and for good reason. It is tiny. We’re talking 5MB tiny.

Alpine achieves this by using musl libc instead of the more common glibc and the BusyBox suite of utilities. It’s lean, it’s mean, and it’s fast. When you use Alpine, you are stripping away the “lifestyle bloat” of Ubuntu or Debian. You get exactly what you need to run your application and nothing more. However, as any Wong Edan practitioner knows, minimalism comes with its own set of headaches. The move to musl can sometimes break applications that expect glibc, leading to those wonderful “file not found” errors that make you want to throw your laptop out the window.

But Alpine is just the first step. If you want to truly shrink your attack surface and reclaim the purity of your code, you have to go deeper. You have to go distroless.

The Ghost in the Shell: Embracing Distroless

What if I told you that the best way to secure a container is to remove the operating system entirely? No, I’m not high on thermal paste—I’m talking about Distroless images. As discussed in recent technical updates (Medium, Dec 17, 2025), Distroless images contain only your application and its runtime dependencies. They do not contain package managers, shells, or any of the standard Unix utilities you’d expect.

Why would anyone want this? Security. Pure, unadulterated security. If a hacker manages to find a vulnerability in your web application, the first thing they usually do is try to spawn a shell (/bin/sh) to look around. In a Distroless environment, there is no shell. There is no ls, no cd, no curl to download more malware. There is nothing but your running binary.

Medium’s technical review highlights a critical point regarding this: if you try to execute a command inside a Distroless container using docker exec, you will be met with a glorious error: “OCI runtime exec failed: exec failed…”. This isn’t a bug; it’s a feature! It means the attack surface has been reduced so significantly that even the administrator can’t easily poke around inside the running container. It forces a “read-only, immutable” mindset that is essential for reclaiming control from bloated, insecure SaaS architectures.

Nix: The Alchemist’s Way to Distroless

Now, if you want to be truly Edan—truly sophisticated—you don’t just use Google’s Distroless images. You build your own using Nix. As documented by Mellow Root (Nov 6, 2022), Nix allows you to create your own Distroless Docker images with surgical precision.

Nix is a functional package manager that treats builds as pure functions. When you use Nix to build a container, you specify exactly which libraries and binaries should be included. Nix then bundles them into an image that contains only those specific store paths. The result? A Distroless image that is even more reproducible and minimal than standard methods. You aren’t just downloading a base; you are composing the reality of your container.

Using Nix to build minimal containers helps solve the “works on my machine” problem once and for all. It allows open-source developers to distribute their tools in a way that is incredibly lightweight, making the “why do I need to host this in a browser?” question redundant. If the container is only 20MB and runs with zero overhead, self-hosting becomes a joy rather than a chore.

Attack Surface and the Philosophy of “Less is More”

Let’s talk about the Attack Surface. Every line of code you didn’t write, every utility you didn’t install, and every port you didn’t open is a victory for your security posture. In the world of “Everything is a SaaS,” we often give up security for convenience. We trust the SaaS provider to patch their systems, but as we’ve seen time and again, they often don’t.

By moving to Alpine, Distroless, or Scratch, we are practicing Digital Asceticism. We are stripping away the distractions. Consider the comparison:

• Standard Ubuntu Image: ~80MB, 100+ packages, dozens of known CVEs (Common Vulnerabilities and Exposures), full bash shell.
• Alpine Image: ~5MB, minimal packages, fewer CVEs, limited shell.
• Distroless/Scratch: ~2MB (binary size), 0 packages, near-zero CVEs, no shell.

The Medium article from late 2025 makes it clear: the trend is moving away from “convenience containers” toward “security containers.” If your video editor is running in a Distroless container on your local machine, it is infinitely more secure than a SaaS platform that could be breached, leaking your private data and metadata to the highest bidder.

The Path Forward: How to Reclaim Open Source

So, how do we stop the SaaS-ification of our lives? How do we get back to the days where “Open Source” meant “I own this software”? It starts with how we build and deploy. We must embrace the following manifesto:

1. Stop accepting SaaS by default. If an open-source project only offers a “Cloud” version, demand a self-hosted container.
2. Optimize for the edge. Use Alpine for development and Distroless for production. Keep your images small so they can run on a Raspberry Pi or an old laptop as easily as they run on AWS.
3. Learn Nix. It’s a steep learning curve, but it’s the ultimate tool for creating minimal, reproducible environments.
4. Advocate for CaaS over SaaS. If you must use the cloud, use Containers as a Service. Keep the application logic—the “brain” of your software—in your hands.

We are currently in a transition period. The Reddit threads of late 2025 show that the honeymoon phase with SaaS is over. People are tired of subscriptions. They are tired of lag. They are tired of the “browser-only” lifestyle. By mastering the art of minimal containerization, we provide the technical foundation for a return to true, decentralized open source.