This week I got the willy wonka golden Ticket opportunity of trying the new and shiny EVE-NG Version 7 in my Lab 😀
I promised myself to “just quickly” test some features and see the new UI. Network engineers know exactly where this story is heading… The phrase “just quickly” is usually followed by several hours of troubleshooting, at least three coffees, a browser with twenty-seven tabs open and some completely unnecessary redesign of a lab that was working perfectly fine five minutes earlier.
My original plan was simple:
Boot the new version, click through the interface, deploy a JNCIE-Level Lab with some more nodes (cough cough), see what had changed and then get back to studying. Instead, I found myself spending a significant portion of the evening poking around under the hood because something felt different almost immediately. Not flashy. Just… different. The first clue was the user interface. Now, I know that software vendors love talking about user interfaces. Every second release somehow contains a “modernized user experience” which usually means the buttons have moved to different locations and the thing you need most often is now hidden behind three additional menus because somebody attended a design workshop. This isn’t that.
What surprised me the most about the new clean EVE-NG interface wasn’t how it looked. It was how it behaved inside a VM. Everything felt immediate. Creating links, moving nodes, navigating through larger topologies, opening dialogs, jumping between labs – all of it felt oddly responsive. Not responsive in the way marketing departments use the word. Responsive in the way engineers use it when something reacts exactly when they expect it to. The funny thing is that I wasn’t testing this on particularly impressive hardware. My EVE instance was running on a Proxmox host backed by an aging Gen8 server. That’s not exactly state-of-the-art equipment. In technology years, a Gen8 is old enough to have opinions about spanning tree implementations. Yet the interface behaved as if the whole thing was running directly on a modern bare metal server. Naturally, that made me curious. Whenever software suddenly feels WAY faster, there’s usually a reason. Sometimes it’s optimization. Sometimes it’s luck. Sometimes it’s because developers removed a layer of complexity that nobody actually needed. In the case of EVE-NG 7, the deeper I looked, the more I got the impression that the development team had spent a considerable amount of time identifying friction points and systematically removing them while also relying on a modern software stack.
The platform now runs on Ubuntu 24.04 LTS and adds a modern 7.x kernel, which on paper sounds like one of those release note entries that most people skip over. In practice, however, it explains a lot of what I was experiencing. Better scheduling, improved memory handling, modern hardware support and years of kernel development all quietly contribute to a platform that simply feels more comfortable to use. Most users won’t notice those individual improvements. What they will notice is that their labs feel snappier. The more time I spent with the platform, the more I realized that EVE-NG 7 isn’t really about a ton of new features. It’s about removing pain. And nowhere is that more obvious than the upgrade process.
Let’s be honest for a moment. Upgrading infrastructure software has traditionally been a terrible experience. Not because the software itself is bad, but because the process almost always involves a collection of manual steps that have accumulated over time. Download this file. Mount that image. Copy these packages. Verify those dependencies. Hope somebody documented the procedure correctly. Discover at two o’clock in the morning that somebody did not. Every engineer who has maintained a lab environment for a few years has a story involving an upgrade that went sideways because of a missing file, a forgotten command or a dependency that suddenly decided to become creative.
The new upgrade mechanism is built around a single Go binary. At first that doesn’t sound particularly remarkable. Lots of software is written in Golang these days. What makes this interesting is what the binary contains: everything.
And I do mean everything. The installation ISO is embedded directly into the executable itself. Not referenced. Not downloaded. Embedded!!! The binary literally carries the entire upgrade payload inside its own file structure and knows exactly where to find it. When executed, it locates the embedded image, mounts it locally and presents it to the operating system as a repository source. The first time I understood what was actually happening, I genuinely laughed. Not because it was funny. Because it was genious! Every now and then you encounter an engineering solution where the immediate reaction is simply “of course.” Not because the solution is obvious before you see it, but because it suddenly makes every alternative seem unnecessarily complicated. The implications become even more interesting once you start thinking about air-gapped environments.
Some of us work in industries where “just download it from the Internet” isn’t a valid deployment strategy. Government environments, critical infrastructure, financial institutions and various highly regulated networks tend to become nervous when somebody suggests opening temporary Internet access to perform upgrades. Historically that has always complicated things. With EVE-NG 7, the entire process becomes surprisingly straightforward because everything required already exists locally. The mounted repository becomes the package source. Apt performs the migration. No Internet connection is required. No external mirrors are required. No package synchronization is required. Then, just when I thought the architecture couldn’t become any more interesting, I discovered how the Docker components are handled. The answer, naturally, is that somebody embedded an entire Docker Registry into the upgrade payload as well. At this point we are effectively dealing with a Docker Registry inside an ISO inside a Go executable inside a Linux system that is upgrading itself.
Normally, when a software design starts sounding like a Christopher Nolan movie, I become concerned. In this case it works brilliantly. The temporary registry starts automatically, container images are pulled locally at storage speed and the deployment process remains entirely self-contained. No external registries. No WAN dependencies. No waiting for downloads. Everything happens exactly where it should. What impressed me most throughout the entire process was how much effort had clearly gone into eliminating opportunities for human error. Most infrastructure outages are not caused by technology. They are caused by people interacting with technology. We copy the wrong command. We mount the wrong image. We forget a step. We improvise. Network engineers are exceptionally talented at improvisation. Unfortunately, infrastructure tends to prefer consistency. By reducing the entire upgrade workflow to a deterministic process, EVE-NG removes a surprising amount of risk.
The same philosophy appears to have influenced the licensing model as well. Instead of maintaining separate Community and Professional editions, the platform now operates under a “global” freemium model.
Small Labs can run without a license, VPCs don’t count towards the license, and every feature is available from day one. Small labs can operate freely without friction, which lowers the barrier to entry for everyone – students, home lab enthusiasts, and certification candidates alike. If your labs grow beyond the free tier, then you are getting professional value from EVE-NG – and at that point, paying for Pro is simply fair if you ask me. It’s a clean boundary: you either stay in the “learning and experimentation” space, or you naturally transition into real workload territory. The longer I thought about it, the more sense it made. Students get access to professional functionality. Home lab enthusiasts get access to professional functionality. Certification candidates get access to professional functionality. And the platform itself avoids fragmentation by keeping everyone on a single, consistent experience.
That’s a surprisingly rare outcome in software licensing.
And to be honest: if you consistently exceed this limit, you’re no longer “just labbing”. You’re either running serious simulations, working in a professional environment, or – let’s call it what it is – effectively operating at production scale. At that point, the Pro license isn’t a restriction; it’s the logical next step to support the Solution. The EVE team, once again, did an impressive job. A unified platform, no artificial feature gating, and a model that scales cleanly with real usage — that’s not something you see often.
After spending time exploring the platform and building topologies I kept arriving at the same conclusion: EVE-NG 7 feels extremely mature despite still being in testing at this moment I write this article here. You can now even download the Client-Pack directly from the UI – no need to search it externally anymore 🙂
One feature that stood out during my testing was the new Local Wireshark Capture functionality. Anyone who has spent time troubleshooting protocols inside a virtual lab knows the traditional workflow: start a capture somewhere on the EVE server, download the file, open it locally, realize you need another packet, repeat – or do all of this in EVE. EVE-NG 7 significantly improves that experience. After installing the EVE Client Pack packet captures can be streamed directly into the locally installed Wireshark instance. The result is a workflow that feels remarkably natural. Instead of interacting with capture files, you’re interacting with live traffic exactly as you would on a physical network. Whether you’re analyzing BGP updates, troubleshooting EVPN route advertisements, validating VXLAN encapsulation or simply trying to understand why a protocol is behaving differently than expected, having packets appear directly in your local Wireshark session removes yet another layer of friction from the troubleshooting process. It’s one of those features that sounds small when reading the release notes, but after using it, it quickly becomes something you don’t want to live without.
EVE7 is awesome! Not just because it has 4587695476 more features. Not just because it has a prettier interface compared to EVE-NG 6. Not just because it runs a newer kernel. It feels mature because almost every major change seems to focus on removing friction between engineers and the work they actually want to do. And as somebody who spends a large portion of his life building labs, breaking labs and rebuilding labs for expert-level certification preparation, I can tell you that removing friction is one of the most valuable features any platform can provide.
The routers are still going to misbehave. BGP will still find creative ways to ruin your evening. EVPN will still occasionally make you question your life choices. But at least now the lab platform itself gets out of your way.
And even my personal “bi***” (we all know what I mean), the vQFX from ages ago runs smoothly inside EVE inside Proxmox on a Server so old, that it remembers the days before the IPv4 exhaustion 😉 Get your Servers ready for a treat – I for sure can’t wait to see the final release and I heavily tip my fedora for the EVE-NG Team – you folks Rock! 🙂