Taking a Break — See You When I'm Ready

My writing didn’t stop after that first post. For a while, I kept publishing consistently about Docker, Kubernetes, and CI—the "real-world" DevOps stuff. I loved those tools because they felt like answers. They were the first time I felt like I could actually tame the systems I was building, turning "deployment hell" into something controlled and precise.

But the more I learned, the more I saw a pattern of displacing complexity rather than solving it. It wasn't just in the infrastructure; it was in the code itself. Think about how we used to write web apps: raw HTML, CSS, and JS produced ugly, unmanageable code. Then React came along and voila—it fixed the ugly code. But in exchange, it made the applications themselves significantly more complex.

The same thing was happening with my infrastructure. Each new framework seemed to make the underlying machinery heavier. Every time I mastered one layer—containers, clusters, pipelines—the chaos didn't disappear; it just moved higher up the stack. I’d fix the deployment, but the app integration would break. I’d fix the container, but the config management would spiral. That is where the silence started. I wasn't lost; I was in the lab.

I have never been satisfied with "voila, it works." It’s just not how I’m wired. When I was writing about Docker, I wasn't just using it; I was tearing it apart to see how the engine ran. That drive to dig deeper is what pulled me away for almost two years. I stopped writing because the simple answers stopped feeling like enough. I needed to understand why building modern software feels heavier every year, even when the tools keep improving.

It didn't start as a grand architecture. It started as a rejected diploma project.

For my master’s degree, I pitched a custom bundler. My professors didn't accept it—maybe they didn't see the value, or maybe they just thought it was too broad. So I went deep on my own. I tried to build my own version of Vite to understand the magic, but once I got inside, I realized that the bundler world is its own kind of hell. The complexity isn't just "hard"—it's endless.

That’s when the question shifted. I realized I didn't need to replace Vite; I needed to build something on top of it. I imagined a tool that could take two things that shouldn't talk to each other—like Angular and NestJS—and force them into the same build, seamlessly. I stopped trying to be the bundler and started deep-diving into the Vite API to be the glue.

Obsession isn't a straight line, however. There were moments I almost quit. Early on, the "glue" wasn't sticking. It was messy, and at one point, I naively told myself I had achieved what I wanted. Looking back, I realize I had built something, but it was just the tip of the iceberg. The weight of the real complexity underneath—the endless fight against tools that weren't designed to work together—almost crushed me. So I stepped away for a while, returning to writing standard DevOps posts to convince myself that the standard tools were enough.

But the satisfaction wasn't there. The feedback was quiet, and it felt like I was just adding to the noise rather than finding the signal. I realized that if I didn't build this, I would just be managing complexity forever, not solving it. So I put the blog away, stopped looking for validation, and went back to the code for good.

This time, I came back with a different perspective. I stopped asking 'How do I make the DevOps pipeline better?' and started asking 'Why is DevOps a separate step at all?' Why does every project need to be cluttered with config files that force developers to step out of the business process? Every time we stop writing features to configure a Dockerfile, we are solving the computer's problem, not the user's.

I imagined a tool that understands code deeply enough to generate the ready-to-use DevOps assets—containers, configs, pipelines—automatically. That was the pivot. I wasn't just building a meta-framework for frontend anymore; I was building a machine that treats DevOps as a side effect of writing code.

In December 2024, I pushed the first commit. That was the start of the endless fights—first against Vite, then against the AI models trying to understand the architecture, and now against all of them together.

What is Velnora?

Before explaining the architecture, I have a confession: it wasn't always called Velnora. In the beginning, I named it Fluxora.

I thought it sounded cool. "Flux" like flow, "Ora" like... well, it just sounded like a tech product.

But names matter, and Fluxora sounded like just another state management library. Since this project wasn't about state but about velocity and orchestration, Velnora was born.

Velnora is a Meta-Framework for Systems.

Think of it this way: if React handles the lifecycle of a Component (mount, update, unmount), Velnora handles the lifecycle of an Application (resolve, build, deploy, run). It sits above your framework (Angular, React, NestJS) and below your infrastructure (Docker, K8s), connecting and orchestrating them.

At its heart is a Layered Plugin Architecture. The core is minimal—it only knows about Graphs and Lifecycles. Everything else, from compiling TypeScript to running a dev server, is just an Adapter. This means Velnora isn't locked into one tool; today it uses Vite, but tomorrow it could use anything else. The orchestration stays the same.

It resolves your monorepo as a dependency tree, unifies the build across different frameworks, and generates the infrastructure automatically. It is the missing layer that turns a messy collection of micro-apps into a coherent, manageable platform. Once this layer exists, we stop building glue code. And we start building systems.

This is where the origin story of Velnora ends. Next begins its ascent—deep dives into the architecture and working on the core.

You can watch the ascent happen live on GitHub (if you contribute with tasks I'll be happy! 😊) and follow the updates by joining the Notion Space.

I look forward to your comments, new ideas, and close participation in the project's development.