Cloud-native isn't a label for the team at Cloudsmith and me; it’s why we can hit 700K requests per minute without waking anyone up. By leveraging multi-region deployment, built-in edge caching, and elastic scaling, Cloudsmith delivers a highly available ‘invisible in the right ways’ artifact management experience for teams of all sizes out of the box.

 When traffic surges and your artifact platform can’t keep up, it’s not just a few slow requests: builds fail, deploys become backlogged, and engineers lose confidence. We’ve seen it all: 502s from overloaded infrastructure, minutes-long pulls, and pipelines grinding to a halt. That’s why we built Cloudsmith to scale by default; no one should have to firefight with their registry at 2 a.m. Our cloud-native capability is 

the difference between confidence and chaos

Here at Cloudsmith, we recently validated our capacity to scale to 700K requests per minuteand beyond, thanks to the DNA of our genuinely cloud-native architecture. This article will share our thoughts on that high-volume test, how our architecture works, and why being cloud-native matters. We’ll also compare our model to so-called “cloud-hosted” solutions that rely on inferior approaches like manual replication or special edge nodes.

High-Volume Validation Without Advance Preparation

We regularly work with organizations that demand massive throughput from their artifact platforms. Enterprise customers migrating from legacy tools ask, "Can you handle our peak CI traffic?”. Some customers push over 12K requests per second, as in the case of this recent test, and that’s just business as usual.

These customer-run tests often combine short bursts (to simulate traffic spikes) with multi-hour soak sessions at high sustained rates, and we handle them without any special preparation from our operations team. Cloudsmith scales automatically across all regions throughout these testing cycles, delivering consistent performance.

We only ask for some notice before performance tests. This notice is so we can ensure that they are utilizing the tests to maximum effect and are “testing the right things” rather than needing it for preparation time or other biases that we try to avoid introducing. We’ll often suggest additional or alternative tests to demonstrate the power of Cloudsmith.

Speed at Scale with Edge Caching and Global Points of Presence

One of the most important (and often invisible) parts of Cloudsmith’s infrastructure is how we distribute packages globally. We think of it like this: no matter where in the world you’re working, downloading a package from Cloudsmith should feel like you’re pulling it from a machine in the next room.

, a cloud-native evolution of the traditional content delivery network, purpose-built for artifacts. Under the hood, it leverages hundreds of fully managed Points of Presence (PoPs) distributed across the cloud. These edge locations bring packages and metadata physically closer to your developers and your CI runners.

, anywhere in the world. Faster builds. Happier teams.

Built-In Resilience and Custom Storage Regions

Because this is baked into the platform, there’s nothing to configure: no manual replication, no edge node setup, and no high-availability add-ons. Everything is automatic, including failover. If there’s an issue in one part of the network, we route around it, and the end user never notices. Valid packages continue to flow from the nearest healthy location.

Some customers go a step further, asking for things like custom storage regions and connectivity, whether for compliance, performance, or proximity. That’s also built-in. You can pin a repository to a specific country or region while benefiting from global distribution.

: real-time global delivery built for speed and resilience without anyone needing to lift a finger. Because artifact management isn’t just about what you store, it’s also about how fast and reliably you can get it to where it needs to be.

How Cloudsmith Scales Automatically Under Sudden Load

David González, a Principal Engineer, held the infrastructure pager for these tests, and here’s that bottom line again: 

. In this particular instance, he was notified that the test was going to happen, and being curious, he followed along by watching the wealth of observability capabilities we had built into our platform. If you’ve met many engineers, you’ll know that many of them subscribe to the so-called church of graphs. 

 need to do during the test:

• No manual scaling out
• No manual config
• No edge node deployment
• No late-night engineer scramble

We're always curious to see how tests are handled in action, knowing that our platform has been designed for horizontal scale since day one. We distribute workloads across cloud-managed services for storage, data, and global caching. 

, so there’s no need for frantic provisioning. It’s addictive to watch the system manage the load: scaling on demand, adapting to the ebb and flow of traffic, and never needing human intervention.

Edge Routing, Load Balancing, and Stateless Scaling

Handling over 700,000 requests per minute is not just about having capacity. It is about structuring the system so each component can absorb load, isolate failure, and stay fast under pressure.

At the entry point, everything starts at the edge. We use hundreds of global CloudFront points of presence, but layer them in our custom at-edge logic. That includes more innovative request routing, artifact-specific authentication, authorization, and targeted caching strategies. We handle portions of decision-making and routing at the edge before a request touches our core services. This reduces load, tightens latency, and improves performance for consuming clients no matter where they are.

When a request cannot be fulfilled at the edge, it is passed upstream. The application balances load across multiple regions globally, and application load balancers operate in various availability zones regionally; these are routed by latency and fault-tolerant balancing. These feed into a fleet of reverse proxies and web application containers deployed across AZs for redundancy and concurrency. Each component is independently stateless, so scaling and error handling are straightforward and fast.

Scaling Workloads and Separating Read/Write Operations

Internally, we use various computing models, including ECS with managed Fargate and various managed services. This gives us elasticity with less operational complexity, especially for background task workers that respond to load in bursts. Some workloads are CPU-heavy, others are network-intensive, and we can scale them independently based on demand profiles.

Data access is split, too. Write operations go to the primary database, while reads are distributed across replicas, typically in the same regions as the application servers. This separation of reads and writes avoids contention and gives us flexibility in tuning read-heavy endpoints like index, artifacts, and metadata serving. Traffic for different parts of the application is served separately.

Asynchronous Upload Processing and Cascaded Scaling

The pattern changes for uploads. The frontend API validates the request and returns quickly while the artifact is processed asynchronously. Our sync-to-async handoff is queue-based and uses RabbitMQ and Celery, with a pinch of SQS for different types of work. The key is ensuring that handoff is lightning fast. Many workers pick up tasks like scanning, syncing, or triggering webhooks, which are distributed, plus scale and operate independently across services and regions.

This layered model means scaling is not a single action. It is a cascade. Requests are handled locally. If not, they are distributed intelligently. Reads go to replicas. Writes are isolated. Processing is offloaded. And every stage has horizontal elasticity built in.

The result is a platform that tolerates high load and absorbs it gracefully. We engineered each part to scale with intent, not because we engineered for one specific spike.

This graph shows CDN requests per second by role. Pale blue represents download requests, and purple is API requests.

Monitoring Automation at Scale and Knowing When to Step In

Of course, there’s always a practical limit to what it can do automatically, though it is far more than you might imagine. Examples include soft limits within the cloud provider or outlier instances where we encounter new and novel scenarios.

These are situations in which we ensure the quality of service and monitor for issues. In practice, we haven’t hit an absolute upper ceiling yet, and we work closely with our providers to ensure we don’t.

If anything goes wrong, the system pages us automatically. But we rarely need to intervene because that’s cloud-native in action.

In rare cases, we do step in, and that’s where the value of a fully managed service shines. Customers don’t just choose Cloudsmith for artifact management or software supply chain security; 

they buy Cloudsmith for the team behind it

. That’s what they’re buying in reality, and why it’s “more than just bits and bytes.” It is made with love, because we want you to love it. We, as a team, are great to work with because we want you to love us. Software and service.

We often say that if we were on-prem, we’d be stuck with whatever hardware was on the floor. Because Cloudsmith was designed from day one as cloud-native infrastructure, we don’t just “run in the cloud”; we dynamically adapt, without human intervention, to whatever scale our customers demand. 

We designed it this way from the beginning, 

, but by questioning every “standard” pattern we saw in legacy systems. Did we want a big central cluster with manual failover? No. Did we want static auto-scaling groups that needed tuning per region? Also no. Instead, we leaned into platform-native primitives: distributed queues, serverless orchestration, container elasticity, and, importantly, the idea that 

That design thinking shaped everything we built. And it’s why, to this day, our scaling story isn’t a hero story; it’s a systems story: 

Legacy, on-prem solutions often require substantial up-front investments in hardware. Even “cloud-hosted” versions frequently rely on pre-sized compute clusters that require manual scaling or reconfiguration. By contrast, because we’re 

, each layer, whether network, compute, storage, or caching, can expand on demand when requests spike. It’s the difference between a system that quietly scales vs. one that triggers a 3 a.m. scramble for you to deal with.

Designed for the Toughest Enterprise Demands

Enterprise scale isn’t just about high request volumes; it’s about 

. You’ve got massive engineering teams, aggressive automation, exploding dependency trees, compliance obligations across regions, and AI generating more code than most humans can audit in a lifetime.

“But this is about more than just scale. We believe in a fundamentally important mission: securing the world of software by redefining software supply chains. Secure software delivery has become a critical capability; every company globally relies on it.”

— Lee Skillen, Chief Technology Officer at Cloudsmith

At Cloudsmith, we’ve seen what happens when infrastructure isn’t built for this kind of pressure: manual scaling, delays, missed release windows, and security incidents from misconfigured distribution; it's the often hidden cost of platforms that rely on a dedicated ops team for management and tuning. So, we designed a platform that 

and never slows down when it matters most.

We've seen some of the world’s largest enterprises trust Cloudsmith to deliver artifacts for thousands of developers across the globe every hour of the day, and it is easy to see why: it’s because of that multi-tenant SaaS approach and any performance or resilience improvements made for one enterprise, ripple out to all, startups included.

There’s no “special enterprise-only tier” for fundamental platform capability, no hidden high-availability modules or add-ons, and no need for bespoke edge deployments. Have we said it already? Probably. But it’s worth repeating: it just works… by design.

One thing we always find fascinating is how 

failover feels… boring. And that’s by design. 

When an issue hits a particular region, which does happen because 

, it’s already too late to start reacting. Instead, we route around it instantly. It’s surreal to watch: 

, CI jobs don’t pause, and the problematic regions, zones, or nodes are being isolated and replaced behind the scenes.

“We run in multiple geographic locations worldwide, including North America, Europe, and Asia-Pacific. Our servers auto-scale and have full redundancy for failover, so if something goes down, capacity’s already waiting, and even if entire regions have an issue, traffic routes around. Our customers rarely notice, and we aim for zero downtime.”

Paddy Carey, Principal Engineer at Cloudsmith

That worldwide presence and "cloud in our DNA" is part of what makes us 

 cloud-native. Many so-called "cloud solutions" are on-premises architectures repackaged into virtualized environments, and even when they're not, if you have to think about 

 it is run, then it is leaking details to you that turn you into the ops team for artifact management. Cloudsmith? We don’t lift and shift. 

. It’s boring, in all the precisely right ways, just as critical infrastructure should be.

Not all cloud-based systems are created equal. While many tools claim to be "cloud-native," the reality spans a spectrum, from basic cloud hosting to entirely abstracted, self-managing platforms. Understanding where a system falls on that spectrum helps explain the experience it delivers under load.

 These platforms are typically adapted from on-premises software. They are lifted into the cloud, often running within virtual machines or managed clusters, but maintain much of the original architecture. Scaling is usually manual or semi-automated, replication may require explicit setup, and high availability is an add-on or separate configuration. While these systems can operate in the cloud, they expose significant infrastructure details and operational responsibility to the customer.

Some platforms go further. They adopt containerization, integrate with managed services, and automate parts of the scaling process. These systems may offer better elasticity and availability than purely cloud-hosted solutions, but still surface infrastructure abstractions to the user. Customers may need to consider configuring edge nodes, setting up failover regions, replication, and the latency of artifacts between locations. While these systems leverage cloud capabilities, they don’t entirely hide the complexity behind the scenes; i.e., it's still a leaky abstraction layer.

: Built from the ground up for the cloud. They are designed around declarative infrastructure, service abstraction, stateless scaling, and resilience by default, and they cooperate with a product designed for them. These platforms aim to eliminate the user's operational burden: scaling is implicit, replication is automatic, and infrastructure becomes effectively invisible. Users don’t manage clusters or capacity; they interact with a service that adapts dynamically to load, failure, and geography.

 The more cloud-native a system is, the less the user must understand or manage its underlying implementation. This doesn’t just improve performance at scale; it also reduces operational overhead, increases reliability, and allows teams to focus on delivering software, not managing infrastructure or having to choose a package pre-emptively that suits their geographic needs.

“The DNA of Cloudsmith is built on three deceptively simple things: simplicity in design, security by default, and being genuinely cloud-native. We heard the same frustrations from developers, security teams, and enterprises from the beginning: their tools were challenging to manage, painfully complex, and incapable of scaling to their demands.”

Lee Skillen, Chief Technology Officer at Cloudsmith

Your team shouldn’t have to consider scaling, failover, or geographic location. With Cloudsmith and our genuinely cloud-native approach, they don’t.

Recalling that recent test, what was the outcome, anyway? Even with 700K requests per minute surges arriving at a distributed scale, the platform scaled out, distributing the load across regions and availability zones, and carried on its daily life. No other customers felt a thing: builds, pulls, and pipelines all carried on like usual. It’s all a testament to how authentic cloud-native design copes with high-scale demands. 

Even if you don’t have worldwide scaling requirements today, going cloud-native still offers immediate benefits:

If your artifact or container image demands a spike, Cloudsmith scales automatically, with no reconfiguration or new licensing.

We’ve seen customers caught out by the hidden ceilings in the legacy cloud-hosted tools with scaling limits they didn’t even know existed until things broke.

A platform designed for ultra-high traffic delivers faster artifact pulls, quicker builds, and minimal CI wait time, day in and day out.

No manual replication or confusion about which nodes are updated. Our architecture handles global distribution, letting you focus on development.

Cloud-native isn't a label for the team at Cloudsmith and me; it’s why we can hit 700K requests per minute without waking anyone up. By leveraging multi-region deployment, built-in edge caching, and elastic scaling, Cloudsmith delivers a highly available “invisible in the right ways” artifact management experience for teams of all sizes out of the box.

We’ve seen tests hit us at hundreds of thousands of requests per minute, sometimes with no warning. And every single time, we think the same thing: 

this is what infrastructure should feel like

Cloudsmith isn’t cloud-native by accident

; it’s cloud-native by design. And when the traffic hits, it just works.

Still stuck managing replication add-ons, high availability setups, or surprise downtime? It doesn’t have to be this way. Ditch the complexity and let Cloudsmith show you what actual cloud-native artifact management looks like. Ready to test your scale? 

Lee Skillen

Chief Technology Officer

Scaling up to 1 Million Requests per Minute: How Cloudsmith Delivers Extreme Performance

: KubeCon London 2025 (KubeCon EU) showed a cloud-native ecosystem shifting from fragmentation to unification of policy, security, observability, and artifact management. Wasm is moving from hype to real-world use, OPA is expanding into FinOps, and signing everything (with SBOMs, attestations, and metadata) is becoming standard. Artifact registries are evolving fast, becoming unified platforms for governance, provenance, and automation across the software supply chain.

There’s something unmistakably electric about being at KubeCon in person. Maybe it’s the hallway chats, the animated late-night debates (helped along by the thump of House of Kube), or the shared momentum in the air – this year felt like a shift in the literal sense. Cloud-native isn’t just evolving; it’s maturing, solidifying, and meeting the pace of a world increasingly hungry for scale and simplicity.

, held at ExCeL London from April 1 to 4, brought together thousands of practitioners to explore the state of Kubernetes and the cloud-native stack. Several clear themes emerged across keynotes, breakout sessions, and late-night conversations.

 and cost optimization, and the ongoing reinvention of 

. Below, we’ve curated the significant highlights, with talk titles, speakers, and links to recordings and resources, plus our take on what they mean for the road ahead.

The conference vibe was exuberant and technically charged. CNCF celebrated its tenth anniversary of Kubernetes with a look forward: how to keep bridging cloud-native innovation with real-world production needs. The 

 introduced a fun twist on professional development: the 

 designation (and yes, now we want them too, at Cloudsmith).

This new CNCF program recognizes attendees completing 

all 13 CNCF certifications plus the LFCS Linux admin exam

, showcasing their cloud-native mastery. If you saw folks wearing unique Kubestronaut beanies or jackets, now you know why. The challenging economic climate also underscored a focus on 

: many hallway conversations compared notes on balancing cloud costs and complexity with on-prem solutions, highlighting that sometimes on-prem isn’t worth the trade-offs in agility.

 ~12,000+ attendees, 229 sessions, and countless community meetups and parties (don’t worry, the famous 

 party returned for those who could snag an invite, sponsored again, of course, by Cloudsmith, along with our friends at Humanitec, Tailscale, Sysdig, and Chainguard). Read on for our curated highlights of sessions relevant; we’ve organized the recap into thematic sections for easy scanning.

The Rise of Wasm in Cloud‑Native Applications

: Wasm is no longer experimental — it’s powering plugins, policy engines, and serverless runtimes in real deployments. Tools like wasmCloud and Spin are leading the way.

 emerged as a star of the show, signaling that 2025 is the year Wasm goes from promise to production in cloud-native systems. A standout session was 

"Was I Right or Wasm I Wrong? A Review of the Wasm Ecosystem”

 by Taylor Thomas (Cosmonic) and David Justice (Microsoft). Both are co-chairs of the CNCF TAG Runtime Wasm working group, and their talk gave a whirlwind tour of how Wasm has evolved from a browser technology to a 

portability, sandboxed security, and fast startup

, making it ideal for cloud and edge deployments. Custom ABIs hampered early server-side Wasm experiments, but the new 

 1.0 on the horizon) unlocks true interoperability. The talk highlighted a parade of projects leveraging Wasm today:

 – a CNCF project enabling a cloud-native Wasm application runtime

 by Fermyon – a developer tool for serverless Wasm apps

 – a universal policy engine using Wasm modules for Kubernetes admission control

 – demonstrating pluggable cluster scheduling logic in Wasm

 – extending proxies with Wasm filters (e.g.,

 – an OSS library running sandboxed functions blazingly fast via hypervisor protection

– we’re experimenting with Wasm via OPA-based policy enforcement, a use case we’re watching closely as these technologies converge.

: Wasm is no longer niche; it’s becoming a 

 for extensibility in many systems. Thomas and Justice’s candid discussion of the new 

 (with its strengths and weaknesses) helped the audience grasp 

 and what’s coming next. Keep an eye out for 

 with async support and eventually a stable WASI 1.0 (perhaps 2026) that promises no breaking changes.

 of Wasm content for those hungry for more on Wasm. 

 (Cosmonic) dived into wasmCloud’s road to standards in a talk cheekily titled 

“Wasm Whiplash: wasmCloud's Wild Ride To Standards.”

 And if you blinked, you might have missed a 

 by Joonas Bergius on mixing WebAssembly into Linkerd service mesh (

“Meshin’ With WebAssembly: Taking Linkerd Beyond Containers,”

 10 minutes of intriguing mashup). All these point to WebAssembly’s growing momentum: expect Wasm components powering plugins, microservices, and cloud functions in your architecture soon.

: Security was the dominant theme at KubeCon 2025. Signing, provenance, and secure-by-default registries were front and center. Tools like TUF, Notary, ORAS, and Kyverno are key to verifying that every artifact in your cluster is trusted.

 throughout KubeCon 2025. Nearly every keynote and many sessions hammered on safeguarding the software supply chain and production clusters. Multiple talks provided 

hands-on insights into tools and practices

 for artifact integrity, provenance, and vulnerability management.

“TUF-en Up Your Software Supply Chain”

 by Marina Moore (Edera) and Kairo de Araujo (Eclipse Foundation). This talk focused on 

, a CNCF graduate project aimed at secure software distribution (familiar to many via its use in PyPI, Docker Content Trust, and other systems). Moore and de Araujo highlighted how to distribute container images 

 their SBOMs and attestations in a tamper-evident way. They explained TUF’s core design (multi-signature trust, freshness checks, repository consistency guarantees, etc.) to ensure images and metadata remain current and unmodified in transit.

 for end-to-end verification, illustrating how an image’s SBOM and security attestations could be 

 as part of a secure CI/CD pipeline. The key takeaway is that 

As one of our team noted, the specifics of which signing framework you use (TUF, Cosign, Notary v2, etc.) may matter less than 

 and every organization must be proactive in defense.

Where and how you store signed artifacts matters, especially as OCI 1.1 enables registries to store and reference metadata like SBOMs and signatures reliably. Cloudsmith (like others in the ecosystem) is exploring how to surface this metadata securely and natively inside OCI workflows.

“Signed, Sealed, Delivered – Sign and Verify All the Things”

 by Jeremy Rickard (Microsoft). In this talk, Rickard tackled several scary scenarios (image tampering, unvetted YAML in prod, registry compromises) and then showed how to fight back using an arsenal of open-source tools. He wrote a story involving 

 to ensure every artifact in your cluster is trusted (

KubeCon + CloudNativeCon Europe 2025: Signed, Sealed, Delivered - Sign and Ver...

 – enabling OCI registry storage for arbitrary artifacts (not just container images, but also signatures, SBOMs, Helm charts, etc.)

 (v2) – signing artifacts and storing signature metadata in registries

 – GitOps operator (here, ensuring that only signed/approved configs make it to the cluster)

 – a policy engine that can validate images have known good signatures (at admission time)

Rickard walked through an end-to-end demo repository (promised on GitHub) showing how to set up 

production-grade signing and verification

. Attendees left with a clearer idea of how to put these pieces together to 

 were a common refrain across security talks this year.

Other security-related highlights included:

Project Lightning Talk: ORAS – Create and Distribute a Multi-platform Image with Security Posture

 by Feynman Zhou (Microsoft), covered a 5-minute demo of building a container image with SBOM and signing info as first-class OCI artifacts.

Project Lightning Talk: Protect your Kubernetes Clusters with Ratify and Attestations

 by Yi Zha (Microsoft) covered a quick introduction to 

, a Kubernetes admission controller that checks image signatures/attestations before allowing deployments.

Project Lightning Talk: Notary – Securing Binary Artifacts with Fine-grained Control

 (also by Yi Zha), likely covering the latest on Notary v2 project status and its integration with tooling.

“Notary Project: The Key to Secure Software Supply Chain”

 by Joaquim Rocha and René Dudfield. A longer form talks about how Notary v2 is evolving as a cornerstone to securing artifacts in registries.

These trends emphasize why securing the registry is so important. Cloud-native platforms are expected to handle many formats, not just containers, but Helm charts, Wasm modules, and more, while maintaining integrity, provenance, and policy enforcement.

: Observability took center stage, pushing to unify metrics, logs, and traces via a standard query language and better tooling. Real-time insight is becoming essential for security, performance, and cost optimization.

Everyone at KubeCon seemed obsessed with observability, 

not just having data but also querying it more ingeniously

. The hot topic was breaking down silos between metrics, logs, traces, and other telemetry to derive end-to-end insights.

“From the Observability TAG: Designing a Common Query Language for Observability Data”

 (Netflix). Representing the CNCF TAG Observability, these speakers unveiled progress on a unified query language spec for observability (you could call it “SQL for observability”). The idea is to reduce the 

 engineers face when switching between different query syntaxes (PromQL, LogQL, etc.) across tools. Instead, why not have a 

 with extensions to query metrics, traces, logs, and profiles?

They discussed design principles and their research. The consensus is that 

 (with some “syntactic sugar” for pipes and time-series nuances) is a strong foundation. The Observability TAG’s Query Language workgroup is finalizing a spec in 2025, experimenting with pipelining syntax for more straightforward unknown data exploration. If this converges, we might soon write one query that joins data from Prometheus, Jaeger, and Loki in one go – unlocking 

. The excitement in the room was palpable; many see this as a needed evolution to make observability more accessible and powerful.

At KubeCon, visibility across your entire software supply chain came through loud and clear, something we’ve been thinking a lot about at Cloudsmith. Real-time insight into artifact usage and distribution isn’t just a nice to have; it’s quickly becoming foundational to security, performance, and cost optimization.

Other observability updates included project-specific sessions like the 

 sharing the latest on OTel’s roadmap) and deep dives on newer observability tools. eBPF continued to show its strengths in cloud-native troubleshooting. For example, 

 (an eBPF toolkit) was featured in a contrib session on simplifying Kubernetes observability. Across the board, the message was that 

, another exciting update teased at KubeCon, with an upcoming release on April 23rd, 2025, offers a net new enhancement to Pod Generation. Until this point, pods had a metadata generation field to represent a specific desired state of a pod, but the field is currently unused on pods. With 

, users can allow the pod status to express which pod updates are reflected in the pod status for deeper, improved pod lifecycle visibility.

 Expect the lines between logs, metrics, and traces to blur. Tooling will likely unify, and you should keep an eye on emerging standards (perhaps start with the 

 discussions). It also validates why many vendors (and projects) push 

Open Policy Agent (OPA) Everywhere – Even FinOps

Open Policy Agent remains central to security policy but is now expanding into cost optimization. If you’re already using Gatekeeper, adding custom FinOps policies is an easy next step — and increasingly a product expectation for cloud-native solutions.

 has been mainstream for security for a while (with 

 leading the charge), but KubeCon 2025 showed OPA branching into new domains. The 

 session by project maintainers (Charlie Egan of Styra, Anders Eknert, and others) drew a big crowd, which is impressive for a project that’s been around for years. OPA’s maintainers provided updates on the roadmap:

OPA’s core is stable. However, handy features like a long-awaited logical 

 are high on the wish list (and likely coming soon). These were celebrated since they’ll make writing policies much more ergonomic.

 and test streaming modes are being explored to speed up policy evaluation and CI feedback.

 (a Rego linter framework) saw significant improvements between v0.7 and v1.2, and the VSCode OPA plugin improved with new debugging capabilities.

The most buzzworthy angle was using OPA beyond security. 

“Beyond Security: Leveraging OPA for FinOps in Kubernetes.”

 The vast audience was a testament to FinOps being top-of-mind. The idea: 

if OPA can enforce policies for security, why not for cost optimization, too?

 Venkatesan showed how you can use OPA (with Gatekeeper) to 

Enforce that specific teams or namespaces use only cheaper instance types (e.g., 

Cloudsmith Blog

Scaling up to 1 Million Requests per Minute: How Cloudsmith Delivers Extreme Performance

KubeCon London 2025 Recap: Cloud-Native Insights on Security, Wasm, and More

Cloudsmith is headed to Salt Lake City for KubeCon North America 2024

Level up your private npm registries in Deno with Cloudsmith

5 Lessons on the Evolution From DevOps to Platform Engineering

Kong Entrusts Cloudsmith With Global Distribution

Cloudsmith Shines Bright at Digital DNA Awards

Cloudsmith's Enhanced Security with Policy Management

Why you need an artifact management platform for best-in-class software delivery

Managing Users and User Groups: A Guide to OKTA and Cloudsmith Integration

What Is Universal Artifact Management, and Why Is It Beneficial?

Scaling Software Delivery: Continuous Delivery, Overcoming Challenges, and the Power of Cloudsmith