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

products lies in their architecture, design philosophy, and how they leverage cloud infrastructure. Let’s break down the key distinctions:

A Cloud Native product is specifically built for the cloud from the ground up. It is designed to fully utilize cloud computing capabilities such as scalability, elasticity, and high availability.

Microservices / Distributed Architecture:

 The application is often broken down into microservices and/or leverages Cloud-Provider managed services, with each service independently deployable, scalable, and manageable.

: They can automatically scale up or down based on demand, making them more efficient in handling fluctuating workloads. Also, the scaling can be more fine-grained, to specific parts of the service/platform

: Cloud-native applications are built to use cloud-specific databases (e.g., AWS Aurora Postgres, DynamoDB or Google Cloud Spanner etc) and services designed to take full advantage of cloud features. They are “Infrastructure Aware”.

: Cloud-native appliications typically support rapid development cycles, using CI/CD pipelines to automate deployments seamlessly with zero downtime. This means faster updates, releases, improvements and fixes.

Example: A cloud-native SaaS product like Netflix or Slack is architected specifically for dynamic cloud environments, offering high availability, multi-region support, and easy scaling.

A Cloud Hosted product is typically a legacy or traditional software application that was originally built for on-premise environments but has since been moved to the cloud. Instead of being designed with cloud-native principles, it's hosted on virtual machines or cloud infrastructure and usually does not fully leverage cloud-native features.

: These products are often built as large, single applications that run as an instance rather than being divided into smaller, scalable services.

: Rather than using containers or orchestration, these apps may be hosted on traditional virtual machines or cloud servers (e.g., AWS EC2 or Azure VMs).

: Cloud Hosted products may not scale as efficiently or dynamically as cloud-native products, requiring the entire instance to be scaled up or additional whole instances spun up and clustered/replicated, making them less responsive to real-time demand compared to cloud-native apps.

: These products often still rely on traditional infrastructure or databases (Like MySQL or Oracle), with those databases hosted in the cloud on a virtual machine.

An example could be older CRM systems like SAP or older ERP software moved to the cloud but without restructuring/re-architecting the core software to fully utilize cloud-native principles.

In essence, "Cloud Native" means that an application is inherently designed to take full advantage of cloud computing, whereas "Cloud Hosted" applications are more of a legacy or traditional application that's been minimally adapted to run on cloud provider infrastructure. Cloudsmith is a true Cloud Native Artifact Management product.

It’s just not easy to take a traditional application and make it Cloud Native, it’s much less development effort just to host that application on a cloud provider’s infrastructure. To be truly Cloud Native requires Cloud technologies and services to have been considered when an application was architected. To do this with a traditional application that can be installed on a server on-prem or a VM in the Cloud is essentially a rewrite of the application, and that is a monumental effort for a vendor, especially when they have an installed base of users. Ultimately, it would be an entirely new product.

Dan McKinney

Solutions Engineer

"Cloud Native" - Why it matters?

Every business, from startups to established enterprises, feels the urgency to scale their software delivery. Why? Because scaling ensures that as a business grows, its software delivery mechanisms can handle increased demands without compromising on quality or speed. A fast delivery cycle is especially crucial for businesses that experience spikes in traffic, and they must respond to user needs promptly, ensuring timely assistance and resolution.

However, scaling isn't just about handling increased demand. It's about agility, security, and efficiency. Businesses that can't scale effectively risk security breaches, delayed product launches, and operational inefficiencies.

Let’s take a look at some of the challenges behind scaling software delivery, best practices when it comes to scaling, and see how Cloudsmith stands out as first-in-class as an industry leader.

Continuous Delivery (CD) is a culmination of years of refining software development practices. It's not just a methodology; it's a culture. From the days of the Waterfall model, where software development was linear and often rigid, to the Agile era, where flexibility and adaptability became the focus, we've come a long way. CD takes it a step further. It's about ensuring that software is always in a deployable state.

This adaptability means businesses can swiftly respond to market changes, customer feedback, or any unforeseen challenges. The essence of CD is to reduce the gap between development and deployment, ensuring a seamless flow of software updates to the end-users.

Scaling software delivery is like preparing a business for growth spurts. It's about foresight and readiness. When software delivery is scaled effectively:

: Businesses can roll out features or fixes in response to market trends or demands swiftly. This agility can be a competitive advantage, allowing companies to stay ahead of the curve.

: With frequent updates and improvements, customers feel heard and valued. It leads to better user experiences and can significantly boost brand loyalty.

: A faster time-to-market means businesses can tap into new revenue streams quicker than competitors. Whether it's a new feature that users are willing to pay for or an entirely new product line, scaling ensures that businesses are always ready to monetize their innovations.

Challenges in Delivering Software at Scale

Of course nothing in life comes without its hurdles, and scaling software delivery isn’t any different. The following are some common issues that companies face everywhere:

 An inefficient system can push developers to the brink. Imagine a critical bug discovered just before a major release. The pressure to troubleshoot and rectify before the deadline can be immense, leading to overworked and stressed developers.

: In the rush to deliver, teams might opt for quick fixes. These "band-aid" solutions might address the immediate issue but can accumulate as technical debt, leading to bigger problems down the line.

: Speed should never come at the cost of quality. Yet, some teams, in their bid to release rapidly, might overlook crucial quality checks, leading to sub-par software releases.

: Every software release carries a degree of unpredictability. Without a robust system in place, these releases can lead to increased production costs, missed deadlines, and more.

 Errors in the production environment can have dire consequences. From minor glitches to major system crashes, production failures can erode user trust and impact the bottom line.

: Manual monitoring in a high-velocity release environment can lead to increased turnaround times for error resolution.

: Inefficient scaling can slow down product launches, depriving businesses of potential revenue and competitive advantage.


Leveraging Cloudsmith for DevOps Excellence

In the quest to scale software delivery, the tools and platforms you choose play a pivotal role. Cloudsmith emerges as a comprehensive solution, addressing multiple facets of the DevOps journey.

At the heart of any successful DevOps initiative is a culture that allows for collaboration and knowledge sharing. Cloudsmith enhances the developer experience throughout the software development lifecycle. When developers are deeply invested in their work, the entire software delivery process benefits.

Prioritizing security in Continuous Delivery cannot be an afterthought, and it certainly isn’t for Cloudsmith. The platform’s universal, cloud-native solution ensures robust software artifact management and supply chain security. From automated security configurations to tools that detect vulnerabilities, Cloudsmith ensures that security remains front and center.

Simplifying your tech stack is one of the most beneficial things you can do for your organization and team as a whole. Cloudsmith offers a multifunctional platform that streamlines the technology stack, allowing businesses to focus on one comprehensive solution that meets multiple needs, without compromising on quality, security, or control.

Scaling software delivery is a journey, one filled with challenges but also immense opportunities. With Cloudsmith as your partner, businesses can navigate this journey with confidence, ensuring that their software delivery processes are agile, secure, and efficient. After all, building products doesn’t really have an ‘end’— we are constantly learning, evolving, and expanding our knowledge of how to build great products. But with precision and purpose, we can build products that truly matter.

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

The term 'cloud' has become a buzzword in the tech industry, often used interchangeably to describe anything from online storage to complex computing services. But what does it really mean? And more importantly, what is cloud-native, and how does it differ from cloud-based?

“The Cloud” is a concept that has certainly revolutionized the way we store, manage, and interact with data. But as with any technological advancement, the cloud comes with its own set of terminologies that can often be confusing. Two such terms that often cause a confusion are 'cloud-native' and 'cloud-based'. While they might sound similar, they represent different approaches to using the cloud. Understanding these differences is crucial for businesses aiming to leverage the cloud effectively.


In this blog post, we'll look at the differences between cloud-native and cloud-based applications, explore their pros and cons, and help you understand which approach might be the best fit for your business. We'll also introduce you to Cloudsmith (that’s us!) a cloud-native tool designed to streamline your software supply chain management, giving you complete control over how you distribute software.

Understanding Cloud Applications: A Tale of Two Clouds

Cloud-based applications are akin to a well-loved, well-used piece of furniture that you've decided to move into a new house. These applications were originally designed to run on local servers or personal computers but have been relocated to the cloud. While this move offers the benefits of the cloud, such as remote access and reduced physical infrastructure, it also brings along some of the old furniture's quirks.

Cloud-based applications tend to be tightly integrated, meaning their components are interconnected and dependent on each other. This integration can be a strength, providing consistency and reliability. However, it also means that when one part of the application needs an upgrade or encounters an issue, the entire system might need to be taken offline. This can lead to downtime, which can disrupt operations and impact productivity.

Cloud-native applications are like a house built from scratch, designed to fit the specific characteristics of its location. These applications are designed specifically for the cloud environment from the get-go. They're built to be flexible, scalable, and resilient, taking full advantage of the cloud's capabilities.

Cloud-native applications often employ a microservice architecture. This means they're composed of small, independent services that work together, much like a well-coordinated sports team. Each player (or service) has a specific role and can operate independently of the others. This independence means that individual parts of a cloud-native application can be updated, scaled, or even taken offline without disrupting the entire system.

Comparing Cloud-Native and Cloud-Based Applications

So what's the difference between cloud-native and cloud-based? It all comes down to design philosophy, implementation strategy, maintenance requirements, and cost efficiency

: Cloud-native applications are faster to deploy because there's no need for traditional hardware or software installation.

: Microservices allow cloud-native applications to scale seamlessly, whereas cloud-based applications may struggle due to architectural constraints.

: Cloud-native apps are built for resiliency, reducing the risk of downtime during updates or outages.

: With cloud-native architecture, you only pay for the resources you actually use.

Cloud-based applications, while still offering the benefits of the cloud, can be slower to deploy and more prone to interruptions. Because they weren't originally designed for the cloud, they might not be able to take full advantage of all the cloud's benefits.

The Benefits of Using a Cloud-Native Tool: Introducing Cloudsmith

Enter Cloudsmith, a cloud-native tool, fully managed, universal artifact management platform. Cloudsmith is designed to help you manage your software assets efficiently and securely, giving you complete control over your software supply chain.

Here are some of the key benefits of using cloud-native applications:

: Easily scale applications up or down based on demand.

: Continuous delivery pipelines allow rapid release and updates.

: Built-in fault tolerance and self-healing capabilities.

: Minimal maintenance required with managed services.

: Pay only for the cloud resources you use.

: Developers can work independently on microservices.

: Frequent updates and centralized control reduce vulnerabilities.

But why is artifact management so important? In the world of software development, an artifact is any file or resource that is produced during the software development process. This could be anything from compiled source code and documentation to test data and final software packages. Managing these artifacts effectively is crucial for maintaining the efficiency, reliability, and security of your software supply chain. It allows you to keep track of the different versions of your software, ensure that your teams are always working with the correct resources, and protect your software from potential security threats.

Cloudsmith provides a centralized platform for managing and distributing software packages. It's like having a dedicated, secure, and efficient delivery service for your software. You can track and control your software assets, ensuring they're delivered quickly and securely. It is flexible, scalable, and resilient, and making it the go-to cloud-native platform for modern software delivery.

, Cloudsmith is designed to grow and evolve with your business. It requires no infrastructure management, allowing you to focus on what really matters—building great software. It adapts to your workflows, integrates with your CI/CD pipelines, and scales effortlessly as your needs grow.

Choosing between cloud-native and cloud-based applications often comes down to your specific needs and circumstances. Both have their strengths and can offer significant benefits. But, cloud-native applications like Cloudsmith offer a level of flexibility, scalability, and resilience that's hard to beat. They're designed for the cloud, built to take full advantage of its capabilities, and ready to adapt to your organisation's evolving needs.

If you're looking for a cloud-native tool to help you take control of your software supply chain, look no further. Cloudsmith is built by developers, for developers, and it's ready to support your growth in the cloud era.

Explore the benefits of cloud-native applications today, and see how Cloudsmith can empower your team to move faster, safer, and smarter in the cloud.

1. What is the difference between cloud-native and cloud-based?


Cloud-native is built for the cloud from scratch. Cloud-based is migrated to the cloud but was originally designed for on-premises use.


A cloud-native application is designed specifically for cloud environments, using microservices, containers, and CI/CD for agility and scalability.

3. What are the benefits of cloud-native applications?


They offer faster deployment, high scalability, resilience, cost-efficiency, and better performance in cloud environments.


A cloud-native tool, like Cloudsmith, is built to run in the cloud, offering secure, scalable solutions for modern software development.

5. Why choose cloud-native over cloud-based

?
Cloud-native apps are more agile, resilient, and cost-efficient. They outperform cloud-based apps in speed, updates, and scalability.

6. Can a cloud-based app become cloud-native?


Yes, through re-architecture. Refactoring into microservices and using cloud-native tools helps modernize cloud-based apps.


Yes. Cloud-native platforms offer robust security features, continuous updates, and better isolation through containers.

8. Do I need DevOps for cloud-native development?


Yes, DevOps practices like CI/CD are crucial to take full advantage of cloud-native architecture and automation.

Cloud-Based vs Cloud-Native: What’s the difference?

A crucial part of effective package management is package distribution. Whether you are dealing with distributed development teams, deploying a distributed application or even if you are a software vendor, you need efficient, performant and reliable delivery of your software packages or artifacts.

And for that, you need infrastructure. Lots of infrastructure. To deliver software globally, at low latencies, you’ll need infrastructure in many regions, preferably as many as possible. There is no beating the laws of physics; it still takes a finite amount of time for packets to travel a distance, which means that the closer your users/systems are to where your infrastructure is, the better.

So, to accommodate all these distributed users and systems, you’ll need infrastructure in as many data centers or points of presence as you can, ideally co-located alongside or within internet exchange points, giving you the best possible network access.

A Content Delivery Network (CDN) is precisely that. It is servers and infrastructure at many locations globally which are used to deliver content quickly. Many websites and services use a CDN to deliver assets such as pictures, HTML and javascript files to users, without the request for these assets having to go back to the primary hosting infrastructure.

A CDN caches this content at the network edge; it doesn’t host it. And typically, the CDN infrastructure has direct connectivity to internet backbones and exchanges, delivering these assets in the most performant way possible.

So instead of building out, managing and maintaining all this infrastructure yourself, you can use a CDN to distribute your software artifacts and packages, right? Yes, you can, but that’s only going to get you so far.

Well, software package management can be a “mucky” business. Each language, OS, framework or platform has its own package format, client tooling, APIs and communication protocols. It’s not unusual for a modern software development process to use many of these package types, which introduces the problem of managing all these different concerns.

Simply dropping a CDN in front of your package hosting will not accommodate all these differences effectively. It may help, but it’s not optimal. Distributing packages to client tooling is very different from distributing JPEGs or HTML via plain old HTTP.

Introducing the Package Delivery Network: a CDN evolved.

It’s a problem that Cloudsmith was built to solve. From the beginning, Cloudsmith was made with package distribution in mind. We don’t believe that package distribution is a different problem from package management – it’s an essential part of it.

The ability to efficiently distribute software artifacts globally is a fundamental core component of effective package management. It’s more important now than ever, with the rise of distributed teams, working from home, and distributed cloud-native applications.

It’s simply no longer acceptable that your geographic region determines the performance of your development, deployment, or commercial distribution processes. The world has moved on, and we need to adapt to keep up.

And that’s where the Package Delivery Network (PDN) comes in.

Well, the TL:DR is that it’s a highly customized CDN. It’s a CDN that is specialized in the delivery of software artifacts. It knows that it is serving software packages, it’s context-aware, it’s not just blindly serving assets and treating them all as equals. It’s an intelligent CDN.

A primary example of this is our edge caching rules feature.

The first benefit of our package delivery network is that your software packages and artifacts are cached at the edge, reducing the need to retrieve them from primary storage locations and then deliver them to the consumers.

Of course, that’s great that your artifacts and packages are cached at the PDN edge nodes; it’s straightforward to understand how that can improve performance. But what about control? Who decides how this caching is performed? What level of caching do you need? You are best placed to make these decisions, and edge caching rules give you the ability to do so.

You get to define the Time-To-Live (TTL) for packages cached at the edge, and you can cache packages and metadata differently. Maybe you want a very short TTL for something frequently updated, like a Maven snapshot repository. Conversely, you can set a very high TTL for packages that infrequently change, perhaps a new software release or update.

And you can do this on a per-package-format basis as well – as we said previously, the PDN is context-aware.

Also, thanks to the continued improvements in CDN offerings, we can now run some of our application logic directly on the CDN edge nodes themselves. This effectively means that Cloudsmith, as a distributed cloud-native application, is distributed right out to the network edge. Our code can run next to our users and across all the CDN points of presence, giving us greater reach than would be possible with multiple cloud provider regions alone.

This goes above and beyond the basics of caching software packages and metadata at the edge nodes and has brought particular benefits, like authentication at the edge (among others).

Securely storing packages and controlling access to those packages is of paramount importance. With the focus now on software supply chain security, you must ensure that your package repositories are secure and tightly controlled. Private repositories and reducing your reliance on public package repositories are an absolute must.

Cloudsmith Blog

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

"Cloud Native" - Why it matters?

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

Cloud-Based vs Cloud-Native: What’s the difference?

Package Delivery Networks: How They Differ From CDNs

Go Cloud-Native or Go Home

Cloud-Hosted or Cloud-Native? Discover Why Cloudsmith Was Born in the Cloud

Product Update: More Global Infrastructure

We’re Making The Cloud Faster With Local Storage And Edge Caching