%%LARA 10:%% Double Kubernetes Jump, Bottlerocket by Default & GitOps That Scales

If this is your first time hearing about it: LARA [Labyrinth Labs Reference Architecture] is our cloud-native platform built on AWS EKS. It bundles everything a production Kubernetes platform actually needs: networking, autoscaling, observability and security into a versioned, battle-tested product that we continuously develop and roll out to our customers. Instead of every team solving the same infrastructure puzzles on their own, LARA solves them once, properly, at the platform level.

And that platform level just moved forward again. LARA 10.0.0, codenamed Tuaddon, is out.

Fun fact: LARA 10 was originally planned as a quick-turnaround maintenance release. Bump a few versions, keep the engine warm, save the fireworks for later. It didn't stay that way for long - because the ecosystem doesn't sit still, and neither do our customers. What shipped instead is a release built around a double Kubernetes jump to EKS 1.34 and 1.35, foundational upgrades of the AWS and Helm Terraform providers, and a switch to Bottlerocket as the default operating system for EKS managed nodes.

Quick Recap: The Numbers Behind the Release

• 67 issues closed: 12 bugfixes, 15 upgrades, and the rest features and improvements
• 845 hours of engineering effort, roughly one engineer working full-time since January
• Shipped just 3-4 months after LARA 9 - our release cadence keeps tightening

Here is the part we like to point out to anyone evaluating a platform like this: if you didn't have LARA, this is the effort your team would need to find somewhere - every few months, forever - just to keep an equivalent platform current, secure, and out of paid extended support. With LARA, it comes with the subscription. It becomes our engineering problem, not yours.

The Double Jump: EKS 1.34 and 1.35

LARA 9 ran on Kubernetes 1.33. LARA 10 jumps two versions at once, landing on EKS 1.35 - with standard support running until March 2027. That gives us, and you, a comfortable runway to focus on features instead of scrambling to dodge AWS Extended Support fees.

Kubernetes at this stage of maturity is a proven, robust platform, and the interesting changes are increasingly the quality-of-life kind. For example: Image volumes: you can now mount an OCI image directly as a volume. Need to get a binary or a dataset into a workload? You no longer have to bake it into the application image - mount it alongside instead. A small feature that opens up genuinely new ways to package applications for Kubernetes.

Of course, an EKS upgrade is never just the control plane. A bare EKS cluster is - to simplify only slightly - empty. What makes it production-ready is the matrix of addons LARA ships on top: ingress, autoscaling, DNS, secrets, observability, and more. Every one of them has to be reviewed for breaking changes, tested for compatibility, and evaluated in the context of what our customers actually run. That work - going addon by addon, version by version - is the single most demanding part of any release. This double jump, addons included, consumed 19 man-days on its own. We've even built internal AI tooling that analyzes upgrade paths across versions and flags what needs attention, which is speeding this up considerably.

You get all of it as a finished, validated upgrade.

Bottlerocket Is Now the Default Node OS

Managed node groups in LARA 10 default to Bottlerocket - the minimal, security-focused, container-optimized Linux from AWS - instead of Amazon Linux 2023.

This brings managed nodes to feature parity with our Karpenter-provisioned nodes: registry mirrors, registry authentication via the bootstrap helper, node-local DNS, and instance-store disks for container data. A smaller attack surface, faster boots, and one consistent node model across the platform.

Argo CD Moves to Server-Side Apply

All EKS addons and services deployed through Argo CD now default to server-side apply. Instead of packing the entire manifest into the last-applied-configuration annotation, Argo CD now tracks field ownership natively in Kubernetes.

In practice this means better drift detection, cleaner diffs, and no more hitting annotation size limits on large manifests. If you've ever watched an Argo CD app flap between Synced and OutOfSync for no visible reason, this class of problem just got a lot smaller.

Foundational Terraform Provider Upgrades

LARA 10 moves the AWS provider from v5 to v6 and the Helm provider from v2 to v3 across all modules and integrations. AWS provider v5 is no longer supported upstream, so this is about staying current and avoiding technical debt before it accumulates interest.

These providers touch nearly every Terraform state in the platform, so expect provider-driven plan changes during the upgrade - all mapped out in the migration guide.

And it's not just LARA's internal modules. The Labyrinth Labs ecosystem includes 46 public, open-source Terraform addons and Helm charts that the community uses and we maintain. Keeping 46 repositories aligned with new provider majors is nobody's idea of fun, but giving back to the open-source community is part of our DNA - so they moved forward too.

Cross-AZ Cost Optimization, Round Two

In LARA 9 we reworked the ingress path with topology-aware routing to cut cross-AZ data transfer costs. LARA 10 continues that work on the newer ingress options: topology-aware routing now covers both Traefik and the Envoy Gateway proxy, with zone-aware Services, NLB client routing policy, and cross-zone balancing controls.

Traffic keeps preferring the shortest, cheapest path - now regardless of which ingress solution you run.

Registry Cache, Expanded

In-cluster registry caches got a meaningful upgrade:

• quay.io mirroring joins the supported registries
• The registry-cache addon now runs one replica per availability zone
• Each registry gets a separate S3 storage directory, mitigating cache-poisoning and supply-chain risks
• Container runtime can now check image metadata against the upstream registry through the mirror, while falling back to the local cache when upstream is unreachable

The result: less external egress, faster pulls, and clusters that keep working even when an upstream registry has a bad day.

Atlantis Is Now Generally Available

Introduced as a preview in LARA 9, Atlantis - pull-request automation for Terraform - has spent the last release cycle being tuned, bug-fixed, and documented on our own infrastructure. In LARA 10 it graduates to GA.

Customers kept asking how to automate Terraform workflows on top of LARA. The answer is now official: plans and applies happen directly in your pull requests, infrastructure changes become part of code review, and nothing important lives in someone's terminal history anymore.

Databases: Staying in Standard Support

The same extended-support economics that apply to EKS apply to AWS RDS. LARA supports three database deployment shapes - Aurora, RDS clusters, and RDS instances - and in LARA 10 we bumped default engine versions across all of them to maximize time on free standard support.

Sounds like "just bumping versions"? Each engine - MySQL, PostgreSQL, MariaDB - behaves differently during upgrades, and the documentation often leaves you guessing. We burned the testing hours so you don't have to. We also optimized the surrounding Terraform so that future engine version changes require far fewer code changes on your side.

Observability Housekeeping

• Grafana was upgraded to patch known CVEs - part of our standing practice of tracking security advisories across the LARA ecosystem, assessing their real impact, and shipping fixes at the appropriate speed (immediately if critical, in the next release if not)
• For our largest customers, Grafana's backing database started showing performance strain - so we went deep, analyzed the bottlenecks, and are contributing fixes upstream
• Alert rules were tuned to eliminate false positives, dashboards and folder layouts were cleaned up for readability
• New alerting coverage landed for OpenSearch, RabbitMQ, and Atlantis

‍

Not headline features - just the steady maintenance that keeps a platform trustworthy under real load.

Looking Ahead: LARA Next

We're also rethinking how releases themselves work. Historically we alternated between maintenance releases and feature releases; going forward, expect a more continuous stream of maintenance and features together. The long-term goal is ambitious but simple: a LARA upgrade should be a regular, boring task - not an event that anyone, on our side or yours, needs to mentally prepare for. We're investing in pre-flight checks, release automation, and rollout automation to get there.

On the roadmap for the next release:

• EKS 1.36 
• Continued cross-AZ traffic optimization
• Network observability - a feature born at last year's internal hackathon
• An expanded testing framework for validating LARA both during development and after deployment at customers

Conclusion

LARA 10 is rolling out to our customers now - dev and staging environments first, then production. Most upgrades are handled entirely by our platform team as part of the subscription; if you manage LARA yourself, the detailed migration guide from 9.1.1 to 10.0.0 is ready and waiting.

And one more thing: if LARA solves a problem for you - especially if you've bent it to a use case we never imagined - tell us. That kind of feedback directly shapes what lands in the next release. LARA is not a closed platform where we dictate the roadmap; customer needs are the roadmap.

Not on LARA yet, but curious what a continuously maintained platform could do for your team? Let's talk.

Reach out at lablabs.io/contact

Let's build something reliable together.