For a long time, my writing focused on Docker, Kubernetes, and CI—the tools that promised to tame complexity.
And they did—at least at first.
Deployment pipelines replaced fragile scripts. Containers replaced snowflake servers. Infrastructure became reproducible.
But the deeper I went, the more something felt off.
We weren’t eliminating complexity.
We were moving it upward.
In frontend development, raw HTML/CSS/JS gave way to frameworks like React, Angular, and Vue. Codebases became cleaner. But applications grew heavier—more tooling, more configuration, more layers.
The same pattern showed up in infrastructure.
Every layer I mastered—containers, clusters, pipelines—shifted the chaos somewhere else:
Fix deployment → integration breaks
Fix containers → config explodes
Fix configuration → observability becomes painful
That was when the silence started.
I wasn’t stuck.
I was investigating.
The Rejected Project That Started It All
I’ve never been satisfied with “it works.”
When I wrote about Docker, I wasn’t just using it—I was digging into how it actually worked. That instinct pulled me away from blogging for almost two years.
The simple answers stopped being enough.
Why did building software feel heavier every year… even though our tools kept improving?
It didn’t start as a big architectural vision.
It started as a rejected diploma project.
During my master’s degree, I proposed building a custom bundler. My professors didn’t accept it—maybe it was too ambitious, maybe too broad.
So I kept going on my own.
I tried to rebuild Vite just to understand how modern tooling really works.
That’s when reality hit:
Bundlers aren’t just complex.
They’re bottomless.
So I reframed the problem.
Instead of replacing Vite, I asked:
What if I built above it?
What if Angular and NestJS—two frameworks that normally live in separate worlds—could share a single build pipeline?
I stopped trying to be the engine.
I started building the glue.
Walking Away—and Coming Back Different
Obsession is rarely linear.
There were months when the glue didn’t stick. I convinced myself I had solved the problem—until I saw how much complexity still sat underneath.
Tooling fighting tooling.
Layers stacked on layers.
I stepped away.
Went back to writing safer DevOps posts.
Tried to convince myself that the industry stack was good enough.
But the satisfaction was gone.
The feedback felt quiet.
Like I was contributing noise instead of signal.
That’s when I realized something:
If I didn’t build this, I would spend my career managing complexity instead of removing it.
So I closed the blog.
Stopped chasing validation.
Went back to code.
This time, with a different question:
Why is DevOps a separate phase at all?
Why does every project require developers to leave business logic behind just to configure Dockerfiles, pipelines, manifests?
Every time we do that, we’re not solving a user problem.
We’re solving the computer’s.
That was the pivot.
What if infrastructure became a side effect of writing software?
What if a system understood your code deeply enough to generate containers, configs, and CI pipelines automatically?
In December 2024, I pushed the first commit.
That was the real beginning.
What Is Velnora?
Before diving into architecture—one confession.
The project wasn’t always called Velnora.
Originally, it was Fluxora.
It sounded… fine.
Too fine.
Like another state management library.
This wasn’t about state.
It was about orchestration.
Velocity.
Systems thinking.
So Velnora was born.
Velnora is a meta-framework for systems.
If React manages the lifecycle of a component—mount, update, unmount—
Velnora manages the lifecycle of an application:
Resolve → Build → Deploy → Run
It sits above frameworks and below infrastructure.
React. Angular. NestJS.
Docker. Kubernetes.
Velnora is the missing layer between them.
At its core is a layered plugin architecture. The kernel understands graphs and lifecycles. Everything else—TypeScript compilation, dev servers, cloud targets—is implemented through adapters.
Today it speaks Vite.
Tomorrow? Something else.
Velnora resolves monorepos into dependency trees, unifies builds across ecosystems, and generates infrastructure automatically.
Once that layer exists, we stop writing glue code.
We start building platforms.
This is where the origin story ends.
Next comes the real work: deep dives into architecture, orchestration engines, and the core runtime.
Let’s make building software lighter instead of heavier.
This post is part of an ongoing series documenting the design and evolution of
• GitHub: https://github.com/Velnora/velnora
• Notion Space (roadmaps, design notes, community):
https://www.notion.so/velnora/invite/476be70c8d26fad67beda510c00fe0b61e4512a5
If you want to see how Velnora is taking shape—from architecture experiments to production-grade tooling—you’re welcome to follow the journey or get involved.
Top comments (0)