G8KEPR
From 1.0 to 1.5: Reading G8KEPR's Changelog as a Story
Part 20 of the thread Building G8KEPR
- v1.0 went GA on April 14, 2026: the unified four-pillar platform, shipped with a published independent pentest result.
- In under four weeks, releases added more AI gateway providers, a rebuilt 22-page dashboard, a live demo, customer VPC deployment and a VPC security sprint.
- A changelog is a promise you keep in public. It shows what changed, when, and in which direction the product is heading.
- Read in order, it also shows where G8KEPR was going before the September narrowing made that direction explicit.
Changelogs are the least glamorous page on most product sites. Nobody shares them. Nobody screenshots them. I still think they're one of the most honest documents a software company produces, because they're hard to fake after the fact. Either a thing shipped on a date or it didn't.
G8KEPR's changelog is public, and the stretch from v1.0 to v1.5 reads like a short story if you go through it in order. So let's do that.
April 14: v1.0.0, general availability
Version 1.0 was the point where the four pillars (API security, MCP security, the AI gateway and the verification engine) shipped together as one unified platform, generally available.
It also shipped with an independent penetration test result: 0 critical, 0 high, 3 medium. I've written separately about why that got published rather than filed away. For the changelog, the point is simpler. A 1.0 of a security product should say how it held up when someone tried to break it.
April 25: v1.1.0, a wider gateway
Eleven days later, v1.1 expanded the AI gateway with more providers and hardening.
This is the kind of release that doesn't make headlines but matters a lot to someone evaluating the product. If the gateway doesn't support the model provider you already use, nothing else about it matters to you yet.
April 26: v1.2.0, the dashboard rebuilt
The next day brought v1.2: a rebuilt dashboard, 22 pages, with a full dark theme.
A dashboard is where people form their first impression of whether a tool is serious. A security product can be doing excellent work under the hood and still lose someone's confidence if the screen they're looking at feels thrown together. Rebuilding it was about making the product legible, not just prettier.
April 28: v1.3.0, a live demo
Two days after that, v1.3 added a live demo environment running real traffic.
There's a difference between screenshots of a product and watching it work. Screenshots are curated. A live environment with real traffic is a lot harder to stage, which is exactly why it's more convincing.
May 7: v1.4.0, into the customer's VPC
Version 1.4 is the one I'd point to if someone asked which release mattered most for where G8KEPR ended up. It added customer VPC deployment: sensors ship into the customer's own infrastructure, deployed with Helm charts.
That's the release where running in your VPC stopped being a stated intention and became the way the product actually gets installed.
May 9: v1.5.0, the VPC security sprint
Two days later, v1.5 landed as a VPC Security Sprint, a batch of new modules built for that self-hosted setting. Among them:
- Shadow AI discovery: finding AI usage that's happening in an environment without anyone having formally signed off on it.
- API posture scoring: a way of summarizing how well an organization's APIs are protected, so gaps are visible.
- Credential stuffing detection: spotting attempts to log in with username and password pairs leaked from other breaches.
- Adaptive MFA: asking for stronger proof of identity when a login looks riskier than usual.
Those are well-known problems in security generally. What changed was that G8KEPR could now address them from inside the customer's own environment.
What a changelog is for
I think a changelog does three jobs.
It's a record. It's the plain answer to "what changed, and when?" Anyone running the product needs that, especially for a self-hosted tool where they're the ones doing the upgrading. (If you manage upgrades for a living, you'll know why a way back matters as much as the way forward.)
It's a promise kept in public. Roadmaps are promises about the future. Changelogs are receipts. A product with a steady, specific changelog is showing you it does what it says it'll do.
It shows direction. Read these six releases together and a pattern appears. The early ones round out the platform. The later ones push it into the customer's own infrastructure and build around that. When I narrowed G8KEPR in September to a self-hosted, VPC-only correlation engine, the changelog had already been leaning that way since May.
That's the thing I like most about keeping one. It doesn't just tell other people where the product has been. It tells me.