How I Ended Up Writing My Own Docker Manager Because Existing Ones Suck

I started using Docker actively to isolate my projects. Each project — its own container, its own dependencies, no version conflicts. Perfect.
But damn, every time having to jump into the terminal, type out docker run with a dozen flags, remember which volumes to mount, which ports to expose — it was pure hell.

At first, my idea was to use Docker a bit like Qubes OS — isolated environments for everything. But doing it manually was torture: I had to keep template containers, remember all the flags, and constantly type out long commands. And all the existing Docker managers? They were awful. None of them fit my workflow. So I started thinking — why not just build my own?

Docker has both advantages and downsides compared to something like the Xen hypervisor used in Qubes OS. For example, Docker containers share the same memory space — that’s a security drawback, but a performance win because you don’t need to pre-allocate RAM for each “virtual machine.” I’ve never seen a real-world kernel exploit escape into the host (assuming you’re on an updated LTS kernel), but hey, that’s up to whoever chooses this approach.

Then it hit me — why even bother looking for libraries or GUI managers? Docker is simple enough. It just talks HTTP over a Unix socket. The API is well-documented and straightforward. So I built my own client — pure Python, zero dependencies. Along the way, I learned how Docker works under the hood — which was actually pretty cool.

Next, I threw together a PyQt6 GUI. Container templates — pick Alpine, hit “Create,” and it’s all set up. Need an isolated Firefox? Launch a disposable container — open it, work, close it, and it deletes itself automatically. Need to browse container files? Built-in file manager. Real-time logs with syntax highlighting.

Then I added a plugin system so you can extend functionality without touching the core. I wrote a few basic plugins: image manager, file browser, log viewer. The plugin API is simple and flexible.

In the end, I got a tool that actually saves time. Before, setting up an environment could take around 10 minutes of Googling and fiddling with images. Now — three clicks and done. Plus, it runs anywhere Docker does.

It’s still an alpha version, and there’s plenty left to implement, but if you’re curious — I’ve published the code on GitHub under GPL v3. It already made my life easier — no more wasting time on container routine.

GitHub: github.com/keklick1337/GhostContainers

I stumbled upon CVE-2025-55182 while skimming through fresh vulnerability reports. React Server Components, Flight protocol, some weird deserialization stuff. At first glance it looked like one of those bugs that sound scary but never really work outside a lab.

Still, something felt off. The description mentioned $@ deserialization, then handling, Chunk states. That combination immediately raised a red flag. This didn’t look theoretical. It looked exploitable.

The public PoC was incomplete and messy, so instead of trying to adapt it, I just opened Go and started writing my own implementation to see where it breaks. It didn’t take long.

The first Next.js 15.x target responded exactly how I hoped. Then another one did. And another. Some of them were clearly production systems. No auth, no crashes, no noise. Just clean code execution inside the normal RSC request flow.

At that point it was obvious this wasn’t an edge case. A lot of real-world apps were vulnerable.

I added a proper check mode to avoid blind exploitation, version detection, batch scanning, proxies, stealth options. Not because I planned to weaponize it, but because testing one URL at a time quickly became pointless.

What surprised me the most was how silent the whole thing was. The servers didn’t panic, didn’t log anything interesting, didn’t even slow down. The exploit blended perfectly into regular React Server Component traffic.

Later I added a memory-only shell that lives until process restart. No files, no disk artifacts. Just because it naturally followed from understanding how deep the bug goes.

In the end, I published a Go PoC for CVE-2025-55182 on GitHub. Strictly for research and authorized testing. But this whole thing is a good reminder - once you mess up deserialization in a framework used by millions, the blast radius is massive.

GitHub: https://github.com/keklick1337/CVE-2025-55182-golang-PoC