“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.”

— David González, Principal Engineer at Cloudsmith

 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? 

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

What a year it’s been at Cloudsmith. As we look back on 2024, it’s hard not to feel a sense of pride - and even a little awe - at how far we’ve come. From a scrappy startup to a trusted partner for some of the biggest names in the world, this year has been a turning point, both for our company and the people who make it special.

In this video, our CEO, Glenn Weinstein, reflects on the highs, the challenges, and the moments that defined this year for us. Here’s a little glimpse into what made 2024 unforgettable.

Coffee with Cloudsmith 2024

Growing Up Without Losing Who We Are 🌱🏢

We’ve doubled our count of Cloudsmithers in 2024! It’s exciting, of course, but also a little bittersweet. It’s harder to fit everyone into a room these days - we’d need a really big room! - and keeping up with all the new names can be a challenge. But growth means something important: we’re helping more people, solving bigger problems, and making a real difference for our customers.

Our mission hasn’t changed - to make developers’ lives easier. What’s shifted is our focus. Over the past 18 months, we’ve zeroed in on enterprises, especially those with massive teams using countless tools, languages, and formats. Cloudsmith’s strength is bringing all that chaos together in one place, making it simpler, faster, and more secure to build great software.

A Team That Feels Like Family 👩‍💻👨‍💻❤️

One of the things that sets Cloudsmith apart is the people. Early on, we were all generalists - pitching in wherever we were needed. But this year, we’ve started to mature, hiring specialists with deep expertise who can push us to the next level.

And while our roots are firmly in Belfast, where Cloudsmith began, we’ve expanded to Dublin, London, other locations around Ireland and the UK, as well as India and the United States, too. Belfast, though, holds something special - it’s become home for many of us, including our New York-born CEO, Glenn Weinstein.

Glenn, who splits his time between the U.S. and Belfast, shares in the video how much he’s come to love the city. “There’s something about walking the streets of Belfast, grabbing dinner, or just soaking up the atmosphere that makes you feel welcome,” he says. “As someone from New York, I never imagined Belfast would feel like home, but it truly does.”

Even though we’re a remote-first team, we believe in the magic of in-person connection. That’s why we bring everyone together three times a year for offsites in Belfast. Those few days - full of laughs, ideas, and even a pint or two - are what fuel the trust and camaraderie that make Cloudsmith such a unique place to work.

For our Engineering team, 2024 has been a year of transformation. What used to be a single team now includes specialized squads like Bytebusters, Sentinel, Platform, and Kronos. These groups allow us to go deeper into what we’re building, whether it’s improving security, expanding formats, or creating a sleek new web app that’s already winning over customers.

Looking ahead to 2025, the roadmap is ambitious - and that’s putting it mildly. From digital signatures to advanced policy management tools, we’re diving headfirst into solving some of the biggest challenges in the software supply chain. It’s a big task, but one we’re excited to tackle.

If there’s one thing that’s really hit home this year, it’s this: our customers don’t just need great software - they need a partner. As we’ve worked with Global 2000 and Fortune 500 companies, we’ve realized that onboarding isn’t just about flipping a switch. It’s about walking alongside them, helping them adapt, and making sure every team - whether it’s five people or 500 - feels supported.

This has been a game-changer for us. We’re not just delivering a product; we’re building relationships. And those relationships? They’re built on trust, understanding, and a commitment to helping our customers succeed.

As we close out 2024, we feel like we’re just getting started. Yes, we’ve grown. Yes, we’ve achieved incredible things. But our dreams are bigger than ever. Glenn Weinstein puts it perfectly: “Cloudsmith isn’t just a feature or a niche. We’re building something foundational, something that will change how enterprises everywhere manage their software supply chains.”

We believe Cloudsmith can be a cornerstone for enterprises - a platform that simplifies, secures, and transforms how software is built. We’re still on the journey, still learning, still growing. And we’re so grateful to everyone who’s been part of it - our team, our customers, and our community.

Watch the video above to hear more from Glenn Weinstein about this incredible year and what’s ahead. And if you’re curious about how Cloudsmith can help your team, we’d love to show you.

Here’s to 2025 and everything it holds. Let’s build it together. 💪✨

A Year to Remember: Cloudsmith’s Journey Through 2024  🚀🌍

 is a modern CI/CD platform designed for Kubernetes and microservices applications. It provides developers with fast, powerful pipelines and deep integration with Kubernetes. The platform’s features, such as enhanced caching, parallelization, and flexible triggers, allow teams to optimize their continuous integration workflows.

 to offer a comprehensive GitOps platform for Kubernetes. GitOps helps teams automate their infrastructure and application management, using Git as the single source of truth for deployments. By leveraging Argo within Codefresh, developers can employ advanced deployment strategies such as canary releases and blue-green deployments, improving release quality and reducing risks.

Benefits of Using Codefresh and Cloudsmith Together

, a cloud-native artifact management platform, with 

 enhances your CI/CD workflows in several significant ways. This powerful combination automates artifact handling, simplifies deployments, and enables the adoption of GitOps practices for Kubernetes deployments.

By automating artifact publishing within Codefresh pipelines, developers can significantly reduce manual steps, minimizing errors and ensuring artifacts are securely available for deployment. Cloudsmith’s support for multiformat repositories ensures that microservices using different package formats—such as Docker, npm, Helm, and Maven—can be managed and retrieved consistently.

Integrating Cloudsmith with Codefresh streamlines deployment processes by allowing developers to pull artifacts directly into their Codefresh pipelines. Whether deploying Docker images or Helm charts, this integration ensures consistency across all environments, from development to production, reducing deployment discrepancies.

, developers can ensure that only approved and secure components are used in their pipelines. Features like quarantine and upstream proxying add further control over unapproved or vulnerable dependencies. This guarantees a secure, compliant software supply chain.

Adopting GitOps for Kubernetes Deployments

Combining Cloudsmith and Codefresh enables teams to fully adopt GitOps practices for Kubernetes deployments. GitOps ensures that deployments are automated and aligned with the desired state defined in Git repositories. With Argo built into Codefresh, continuous reconciliation of your Kubernetes clusters keeps your infrastructure consistent with what’s declared in your codebase.

By integrating these platforms, you automate artifact handling, simplify deployments, and enhance security—all while adopting GitOps practices for Kubernetes deployments. This empowers your team to focus on delivering value—writing code, innovating features, and improving products—while the integration handles the complexities of artifact management and deployment.

How to Set Up a Pipeline with Codefresh and Cloudsmith

Setting up a CI/CD pipeline that integrates Codefresh and Cloudsmith is straightforward. Below is a guide to configure your pipeline for seamless artifact management and deployment using either 

 and create repositories for your artifacts.

: Ensure you have access to a Kubernetes cluster connected to Codefresh for deployments.

Open your Codefresh pipeline and go to the 

Name the variable (e.g., CLOUDSMITH_API_KEY), input your API key, and toggle 

Reference the API key in your pipeline YAML using ${{CLOUDSMITH_API_KEY}}.

 in Cloudsmith (required for OIDC to work with Cloudsmith).

Claims: For example add your Codefresh account ID to restrict access. For more information on claims consult the 

Assign the service account you created earlier.

In Codefresh, set up OIDC authentication by configuring your pipeline to request OIDC tokens during execution.

Add steps in your pipeline YAML to obtain and use the OIDC token for authenticating with Cloudsmith.

Modify your pipeline YAML to include steps that push build artifacts to Cloudsmith after successful builds.

To publish Helm charts, you need to use the Cloudsmith CLI. Ensure that the CLI is installed in your pipeline environment. For more details, refer to the Cloudsmith Helm documentation.

Deploying Artifacts from Cloudsmith Using Codefresh

Codefresh offers several ways to deploy your Docker images and Helm charts to your Kubernetes cluster using artifacts stored in Cloudsmith:

Using the Codefresh GUI to Deploy on Demand

: Choose Docker images from your connected Cloudsmith Docker registry.

: Select Helm charts from your added Cloudsmith Helm repository.

: Use Docker images stored in Cloudsmith within your pipeline steps.

: Utilize the Helm step in your pipeline to deploy charts from your Cloudsmith Helm repository.

Kubernetes Templating (cf-deploy-kubernetes)

: Employ templated deployments for consistent configurations.

: Execute custom kubectl commands within your pipeline, referencing artifacts from Cloudsmith.

: Directly deploy Helm charts to your Kubernetes clusters.

: For advanced GitOps deployments, integrate 

 with Codefresh. This allows automated deployment of applications to Kubernetes clusters using Cloudsmith as your artifact source.

Example of Pulling a Docker Image Using OIDC

Below is an example pipeline demonstrating how to authenticate with Cloudsmith using OIDC and deploy a Docker image:

: Retrieves an OIDC token required for authentication.

: Uses the OIDC token to obtain a Cloudsmith-specific token.

: Logs into the Cloudsmith Docker registry using the obtained OIDC token and pulls the desired Docker image.

: Verifies the successful pull by checking the Docker image's history.

: Ensure that the Cloudsmith CLI is installed in your pipeline environment if you plan to publish Helm charts or perform other CLI-based operations. Refer to the Cloudsmith Helm documentation for more details.

: Prefer OIDC over API keys for enhanced security and simplified credential management.

 when deploying artifacts from Cloudsmith. This ensures that deployment pipelines only have the necessary access to pull artifacts without the risk of modifying or deleting them, thus improving the security of your deployment process.

: Store sensitive information like API keys or OIDC tokens securely using Codefresh's encrypted variables or secret management features.

: Leverage Codefresh pipelines and GitOps practices to automate deployment steps, reducing manual intervention and potential errors.

: Utilize Codefresh's dashboards and integrations to monitor deployment status and health, ensuring quick identification and resolution of issues.

: Maintain your deployment manifests in Git repositories for version control, traceability, and easier collaboration.

Integrating Cloudsmith with Codefresh optimizes your CI/CD pipelines by providing secure, automated artifact management and simplifying deployments. With Cloudsmith’s support for multiple package formats and Codefresh’s robust CI/CD capabilities tailored for Kubernetes and microservices, this integration is ideal for modern, distributed applications.

GitOps Pipelines with Codefresh and Cloudsmith

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.

Optimized for containers, serverless, etc.

Relies on virtual machines or traditional instance-based setups.

Continuous integration and deployment. Frequent updates

Traditional deployment, Slower / less frequent updates.

Limited by original design, can be less responsive to changes.

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.

"Cloud Native" - Why it matters?

It’s a fairly common perception that a package repository is basically a file share or file storage, and perhaps for some of the most simple implementations, this is a reasonable analogy.

However, when thinking of Cloudsmith, this analogy misses a lot of important details that make Cloudsmith package repositories rather unique.

If you have used Cloudsmith, you may have noticed that when you publish/upload a package to Cloudsmith or fetch a package from a public package repository (Like Maven Central or PyPi) into Cloudsmith, the first thing that happens is that the package enters a “Synchronizing” state. What exactly is synchronizing?Put simply, synchronization is where Cloudsmith processes the uploaded/ingested package. But that still belies a lot of the detail. What possible processing could a package need? Well, quite a lot actually!

Some of the steps that synchronization/package processing involves are:

 - Setting up the initial state, tools and environment for synchronization.

 - Getting the package files from the upload storage location.

 - Extracting the package files and package assembly (layers and configs for Docker images, for example)

 - Once we have the complete package file set, we scan the files for trojans, malicious content etc.

 - Verify and generate package checksums and signatures, as well as parse and verify package metadata and licenses.

 - Local and Distributed Storage synchronization.

These processes are automatic, require no user interaction and run asynchronously on Cloudsmith's global infrastructure. They are a large part of what empowers Cloudsmith users to implement effective package controls. As they say, knowledge is power - and it’s by the process of synchronization that we gain the knowledge of packages.

Once a package has been synchronized, we can then use the metadata generated to apply things like Vulnerability, Licence and Package Deny policies, create a scoped access token, add tags to the package, or fire a webhook for specific packages/versions. The data generated from synchronization drives a lot of the subsequent actions and workflows that you can perform.

Also, you may encounter occasions where a package fails synchronization:

This is typically a good thing (contrary to initial impressions!) because it can alert you to a problem with the package itself such as invalid/missing/incorrect metadata (the package not meeting the specification for the package type, for example), the presence of Malware in the package, or that you are attempting to upload/publish a package that already exists in the repository (as above). Package synchronization is an essential step in verifying the “correctness” of a package and It’s always better to catch things earlier in your processes than later, as the cost of remediation rises dramatically the later issues are identified.

Cloudsmith Package Repositories do far more than just store your packages, and they have a lot more functionality than just storing your packages in an AWS S3 bucket or Azure Blob Storage, or spinning up a simplistic instance of a package repository. Packages in Cloudsmith repository are so much more than just “bits on disk”, and treating them as such is really doing them a disservice!

What happens when you upload a Package?

Package promotion workflows are a great way to isolate and protect production repositories, allowing progressive levels of security and permissiveness for development, staging, and production environments.

Cloudsmith blog

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

A Year to Remember: Cloudsmith’s Journey Through 2024 🚀🌍

GitOps Pipelines with Codefresh and Cloudsmith

"Cloud Native" - Why it matters?

What happens when you upload a Package?

How to Manage Your Package Promotion Workflows with Cloudsmith

Cloudsmith Navigator: The Trusted Guide to OSS Package Quality

Re-Imagining Cloudsmith.io

Hi. I'm the new CEO :)

Welcoming new leadership at Cloudsmith - a note from Alan Carson

Cloudsmith's Enhanced Security with Policy Management

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