 is fast approaching, and it’s a loaded update! Removing enhancements with the status of “

” we have 59 Enhancements in all listed within the 

Kubernetes 1.35 brings a whole bunch of useful enhancements, including 30 changes tracked as ‘

’ in this Kubernetes release. From these, just 

 are graduating to stable, such as the addition of Kubelet option to specify the maximum age an image that will be kept around before it’s garbage collected. This is beneficial to cluster admins because unused images can now be garbage collected in a timely manner, no longer occupying disk space forever.

 features are also listed in the enhancements tracker, one of which introduces some new authorisation rules to restrict impersonation on specified resources with specified actions. We also see support for in-place resizing of pod-level resources, support for restarting all containers within the pod when a container exits as a 

This is the most detailed Cloudsmith release notes to date, and our team is really excited about this release and everything that comes with it! Let’s jump into all of the major features, changes, and deprecations in Kubernetes 1.35.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:

I’m excited to see structured auth config graduate to stable in Kubernetes 1.35 because it marks a major step forward in making cluster authentication both more flexible and maintainable. The current flag-based OIDC setup has long been a pain point, as it’s hard to extend, oftentimes difficult to manage, and is limited in how it maps identity claims. Moving to a versioned, structured configuration not only modernises this critical component but also unlocks long-requested capabilities like supporting multiple client IDs, richer claim mappings, and dynamic reloading of authentication settings without restarting the API server. This enhancement brings much-needed clarity and power to authentication workflows, simplifies life for operators, and sets a strong foundation for future innovations in identity and access control in Kubernetes.

Nigel Douglas - Head of Developer Relations


The feature I’m happy to see graduating to beta status in Kubernetes 1.35 is the binding conditions within Dynamic Resource Allocation. This looks to be a significant step towards making Kubernetes the definitive platform for demanding AI/ML workloads. This improvement provides the critical intelligence for schedulers to handle complex, disaggregated hardware like fabric-attached GPUs robustly, preventing failed deployments and enabling more efficient, dynamic resource allocation. The beta graduation signals that this powerful feature is almost stable and ready for broader adoption within the ecosystem, hopefully paving the way for more resilient, dedicated AI infra in Kubernetes.

#3673 Kubelet limit of Parallel Image Pulls

We are all delighted to see this new Stable update address the existing, ineffective method Kubernetes currently uses to limit container image pulls on a node. The existing QPS (Queries Per Second) and Burst limits are really confusing as they only control the rate of requests to the container runtime, not the number of concurrent pulls. This can sadly lead to an unlimited number of simultaneous downloads, potentially overwhelming a node's disk I/O and network bandwidth. This new change adds a more intuitive kubelet config field called 

. This setting establishes a clear, node-level limit on how many images can be pulled at the same time. Any pull request that exceeds this limit will be blocked until an ongoing pull completes - improving how cluster admins manage their resource consumption.

maxUnavailable for StatefulSets rolling updates

 strategies. Previously, when updating a StatefulSet, pods were terminated and recreated strictly one at a time, which could be very slow. This enhancement allows users to specify the maximum number of pods that can be unavailable during an update, either as an absolute number or a percentage. This means multiple pods can be updated simultaneously, dramatically speeding up the rollout process.


The primary motivation is to make StatefulSet updates faster and more flexible, bringing them closer to the functionality of Deployments. This is particularly useful for stateful applications that can tolerate multiple replicas being down at once (like a cluster with many followers) or for applications with long startup times (like cache loading). By allowing parallel updates, this feature helps users who prefer the stable network identities of StatefulSets but need the faster rollout capabilities typically associated with Deployments. The default value for 

, ensuring backward compatibility and maintaining the safe, one-by-one update behaviour for applications that require it.


 field to the Kubernetes Job specification. Its primary purpose is to delegate the management and status synchronisation of a Job to an external controller, effectively telling the default Kubernetes Job controller to ignore it. This is a lightweight, per-Job mechanism designed to prevent conflicts when another system needs to take control. The main motivation for this is to support 

, a multi-cluster job dispatcher that runs a "mirror" copy of a Job on a separate worker cluster while managing the original Job on a central management cluster. The 

 field allows the MultiKueue controller to sync the status from the worker cluster back to the management cluster without the default controller interfering.

, meaning it can only be set when the Job is created and cannot be changed later. This choice was made to avoid complex issues and potential errors, such as "leaking" pods, which could occur if control of a running Job were switched between different controllers. This approach provides clear ownership throughout the Job's lifecycle and follows a pattern already used by other Kubernetes resources, making it a stable and predictable solution for developers of custom batch processing systems.

Mutable Container Resources when Job is suspended


This Kubernetes enhancement proposes allowing users to modify the container resource requirements (like CPU and memory) on a job's template while that job is suspended. Currently, this is not possible. The primary motivation is to give users, particularly those using queuing systems like 

, the flexibility to adjust a job's resource needs before it resumes, which can improve scheduling efficiency. While a proof-of-concept exists for standard resources, the implementation faces a significant hurdle with the newer Dynamic Resource Allocation (

) framework, as its resource templates are immutable, and a clear path forward for DRA support is still under discussion.


Initially, the team considered releasing this feature directly as a 'beta' version, enabled by default, viewing the risk as low. However, concerns arose about completing the necessary comprehensive testing within a short development cycle. Specifically, addressing potential race conditions, such as one user updating resources while another unsuspends the job was deemed critical but complex to test reliably. Given these challenges and the potential for unforeseen consequences when loosening API validation rules, the consensus shifted. It looks like the feature will now be introduced in an 'alpha' stage to allow for more iteration and the development of robust test coverage, ensuring the feature is stable and safe before being promoted.

 aims to address the version skew issues within Kubernetes clusters during upgrades or downgrades by ensuring that clients always interact with a complete view of the cluster's capabilities. To achieve this, the proposal introduces a proxying mechanism where an API server, upon receiving a request for a built-in resource it cannot serve locally, identifies and forwards the request to a peer server that can. This prevents misleading "404 Not Found" errors. Simultaneously, the feature implements 

, which merges resource information from all peer API servers into a unified discovery document. This ensures that clients using the aggregated discovery endpoint receive a comprehensive list of all available resources across the cluster, regardless of which individual server they contact.

This mechanism is critical for maintaining system stability and data integrity during version transitions. Without it, controllers like the 

 might act on incomplete information, potentially leading to the incorrect deletion of objects or operational deadlocks. By ensuring that requests yield either the correct resource or a safe "503 Service Unavailable" (rather than a "404"), the system protects against destructive actions while allowing valid operations to proceed. It is important to note that this peer-aggregation logic applies only to the aggregated discovery endpoint (

) and excludes the legacy core endpoint (

 group's top-level types are considered frozen and will not require dynamic merging.

: AuthorizePodWebsocketUpgradeCreatePermission 

In Kubernetes v1.35, a new Beta security feature for synthetic RBAC CREATE Authorisation checks has been introduced as part of this Stable graduation. This feature enhances security by forcing an additional authorisation check when a user attempts to establish a persistent, two-way connection to a pod using commands like 

. Previously, these actions were authorised with a 

 permission; now, this update adds a check for a 

 permission on the corresponding subresource. This ensures that only users with appropriate creation rights can initiate these powerful, interactive sessions with pods.

This security enhancement is part of a much larger and more significant update: the migration from the outdated 

 for streaming communication. The SPDY protocol has been deprecated since 2015 and is no longer supported by many modern proxies and load balancers, causing connectivity issues. By transitioning to WebSockets, a current industry standard, Kubernetes ensures better compatibility and reliability for essential developer commands. In essence, this update modernises a critical communication pathway in Kubernetes while simultaneously tightening the security around it.


Kubernetes occasionally needs to rewrite stored resource data, a process essential for maintenance activities like upgrading a resource's schema version (example: from 

) or re-encrypting data at rest after an encryption key change. The traditional method for this, using manual 

 commands, is inefficient and impractical, especially for large resources like Secrets, and does not scale as the number of resources grows. This manual process is cumbersome and requires significant automation to be performed reliably across a cluster.


To address these challenges, this Kubernetes Enhancement Proposal (

 for short) suggests integrating the logic from the existing Storage Version Migrator (

) tool directly into the Kubernetes Controller Manager (

). This would create a native, in-tree controller and API dedicated to storage migration. The primary goal is to provide administrators with a simple, reliable way to trigger these migrations without manual commands. This change would enable infrastructure providers to automate migrations in response to environmental events, such as a key rotation in a Key Management Service (

), and would streamline the process for users who currently rely on the external SVM tool. While the migration process will be simplified, the responsibility to initiate it will remain with the user.

 Remove gogo protobuf dependency for Kubernetes API types


In early October, the Kubernetes development team initiated a significant change by starting the process of removing a dependency called 

. This component is a toolchain that Kubernetes has been using to automatically generate the Go code necessary for handling its REST API data structures. The core of this feature is to replace an unmaintained and outdated part of the Kubernetes system to enhance security, stability, and future maintainability.

The primary motivation for this change is that gogo protobuf has not been maintained since 2021, which introduces several risks. Relying on an unmaintained dependency means that any newly discovered security vulnerabilities or bugs cannot be easily fixed. Furthermore, every developer or business that uses Kubernetes' core libraries is forced to inherit this unmaintained dependency, creating a wider security concern. This change also aims to prevent accidental misuse of the API types with standard 

 libraries, which has caused system crashes in other projects. By removing 

, the generated code will be streamlined to include only what is essential for Kubernetes client and server operations, making the system more robust and secure.


This now merged pull request formalises the behaviour of the 

 field. Currently, clients are meant to treat 

 as an opaque string, only allowing for equality checks. However, the internal Kubernetes API server implements it as a monotonically increasing integer. This enhancement officially defines that 

should be a comparable, monotonically increasing integer

, allowing clients to reliably determine the order of resource updates, which is a growing need. The proposal includes adding a utility function for clients to safely compare two resource versions and adding conformance tests to ensure API servers adhere to this standard.


A key debate in the comments centred on how to handle non-compliant extension API servers. One alternative suggested was an opt-in mechanism where APIs could advertise their 

 comparability through the discovery API. However, the consensus was that this added unnecessary complexity. Instead, the accepted approach pushes API server authors to either use a comparable integer (the preferred state) or a clearly non-integer string. The new client-side utility function would handle the latter case by returning an error, preventing misinterpretation. The enhancement proposal was ultimately approved and merged, strengthening the API contract for all clients.

 Separate kubectl user preferences from cluster configs

, designed to separate user-specific preferences from cluster credentials and server configurations, which are typically managed in 

 files. The primary motivation is to allow users to define consistent client-side behaviours, such as command aliases, default flags, and security policies, that would apply across all clusters without altering the 

 files used in different environments, like CI/CD pipelines. This separation ensures that personal settings, like enabling interactive delete confirmations or coloured output, don't break automated scripts, and preferences remain consistent even when switching between multiple kubeconfig files.

, is a versioned YAML file that enables users to create custom command aliases and set default options for standard 

 commands. For example, a user could create a short alias for a complex 

 command or automatically enable the server-side applies and the interactive deletes. The proposal also includes a new 

 command to help users safely view and manage these settings without manually editing the file. This feature is opt-in and aims to enhance the user experience by making 


Having gone from New State status to Alpha in Kubernetes 1.34, 

 is now graduating to Beta status. If you missed this feature announcement in Kubernetes 1.34, KYAML is a new, opinionated output format for 

 designed to be a stricter, less error-prone subset of standard YAML. It was created to address common frustrations with conventional YAML, such as its sensitivity to whitespace which complicates templating in tools like Helm, and its ambiguous data typing where unquoted strings like "NO" or "On" can be incorrectly interpreted as booleans (a problem known as the "

"). While JSON is an alternative, it lacks crucial features like comments. KYAML aims to provide the best of both worlds by defining a "flow style" dialect that is 100% compatible with existing YAML parsers but enforces syntactical choices that increase clarity and reduce common user errors, making configuration files easier to write, read, and manage programmatically.


The core principle of KYAML is to use syntax that removes ambiguity and reliance on indentation. It achieves this by always using curly brackets (

) for maps and structs, square brackets (

) for lists, and double quotes for all string values. This approach makes the format insensitive to whitespace, similar to JSON. However, unlike JSON, KYAML is more human-friendly, allowing for comments, trailing commas in lists and maps, and unquoted keys where safe. The proposal includes introducing a new 

 command and updating all official Kubernetes documentation and examples to promote this safer, more consistent format throughout the ecosystem.

For example, here is a KYAML output for a Kubernetes 

 Include kubectl command metadata in HTTP request headers

This new enhancement in K8s v.1.35 suggests adding contextual HTTP headers to requests sent from 

. The goal is to give cluster administrators better visibility into how users are interacting with the cluster for debugging and telemetry purposes. Currently, while the API server sees requests from 

, it doesn't know the specific command that initiated them (like 

). This proposal introduces new headers, primarily 

 header will contain the full command path (for example, 

 will provide a unique ID to group all API requests that originate from a single kubectl command invocation.


This added information is intended purely for out-of-band analysis, such as identifying the use of deprecated commands, understanding usage patterns to inform tooling decisions, or simplifying debugging. It is explicitly stated that the API server should not make any decisions based on these headers. Flag values and command arguments will not be included to protect sensitive information.

 command would generate API requests that include the proposed new headers, which could then be seen in the API server's audit logs.

Kubernetes 1.35 – What you need to know

The adoption of artificial intelligence is seen in just about all industries, with software engineering experiencing large benefits from AI assistants. Tools like Anysphere’s 

 are driving a fundamental shift in how engineering teams build and ship software. However, as development teams rush to integrate LLMs and generative capabilities into their products, a critical blind spot is emerging in the software supply chain.

While security teams have spent years fortifying their pipelines against vulnerable Docker images and malicious npm packages, the introduction of AI artifacts (specifically ML models and their associated datasets) has opened a new, largely ungoverned frontier for software development teams. The challenge is no longer just about securing the code you write, but about verifying the provenance and integrity of opaque binary blobs that are often pulled directly from public repositories into production environments.

 has become the de facto standard for discovery and storage, playing a role similar to what 

 for containers. It is a massive, thriving community where developers can easily download pre-trained checkpoints, fine-tune them with 

, and deploy them via inference endpoints. Yet, the very openness that makes these platforms engines of innovation also introduces significant risk. Just as software engineering leaders would never want or allow a developer to pull an unverified executable from the open web directly into their banking application, they must stop treating these ML models as benign assets during this new age of AI software development. These are executable artifacts that require the same rigour, scanning, and governance as any other critical dependency in the software stack.

The most pressing concern facing development teams today is the specific architecture of these models, particularly regarding "

". Pickle files are Python-based modules used to serialise and deserialise code, a standard method for storing trained ML models. However, this format is inherently insecure by design. Threat actors have weaponised this necessity, embedding malicious payloads that execute arbitrary Python code during the deserialisation process. Security researchers have already identified hundreds of malicious models on public hubs that utilise these techniques to deploy web shells or execute remote code evasion tactics. While platforms like Hugging Face are proactively deploying 

 tools and warning users, the sheer volume of community uploads means that reliance on the public source alone is an insufficient security posture for the enterprise.

Furthermore, the security challenge extends beyond the model itself to the ecosystem that supports it. An AI project is rarely just a model file; it is a complex dependency tree involving Python packages, libraries like 

 (tool for building and deploying AI-powered agents and workflows) or 

 (OpenAI's Text-to-Image Transformer), and various system-level binaries. A secure model running on top of a vulnerable version of a Python library offers a wide-open door for attackers. Therefore, true AI supply chain security requires a holistic approach that governs the model, the dataset, and the OSS dependencies simultaneously. If you are scanning your models for malicious pickles but failing to check the 

 of the Python packages they rely on, the supply chain remains broken.

This is where the concept of a centralised system of record becomes non-negotiable. To mitigate these risks without stifling innovation, software engineering, DevOps and security teams must implement some sort of architecture of isolation and control. This involves 

 public registries. By placing a controlled layer between the developer and the public internet, dev teams can ensure that every artifact (whether it is a Docker image, a Python package, or a Hugging Face model) should be scanned for malware, vulnerabilities, and license compliance before it ever enters the internal network. This allows developers to use standard CLI tools and workflows they love, while security teams enforce policies in the background, quarantining suspicious artifacts before they can cause harm.

 approaches this challenge by extending traditional artifact management to include the specific nuances of AI and ML workflows. By providing a single point of control, Cloudsmith allows enterprises to manage ML models alongside their existing software packages, creating a unified source of truth. The platform proxies and caches external sources like Hugging Face, automatically stripping out risks and verifying provenance. This ensures that when a developer runs a command to pull a model, they are receiving a version that has been vetted against enterprise policy and validating trustworthiness. It bridges the gap between the data science team’s need for speed and the security team’s need for governance.

Ultimately, the future of secure AI development lies in consolidation. The separation of "

" is a dangerous dichotomy. As AI becomes intrinsic to application development, the distinction between a code dependency and a model dependency vanishes. By utilising a platform like Cloudsmith to centralise access control, enforce read-only entitlement tokens, and automate policy management, platform engineers can protect their organisation’s intellectual property and their infrastructure. It turns the supply chain from a vector of attack into a controlled, observable pipeline, ensuring that the only thing your AI models deliver is value. If you’d like to learn more about Generative AI threats like Slopsquatting, register for our 

Typosquatting & Slopsquatting: Detecting and defending against malicious packages webinar

Securing the intersection of AI models and software supply chains

In a world where software ships in seconds, teams are still chained to legacy systems built for a different era. What once passed as “good enough” for storing and distributing builds has become a drain on productivity - adding risk, slowing delivery, and quietly inflating costs year after year.

In this post, we’ll break down the hidden cost of legacy artifact repositories, discuss the importance of modernizing through cloud-native artifact management, and demonstrate how you can leave the old infrastructure that has been slowing your software supply chain.

Legacy artifact management involves older on-premise artifact repositories or in-house custom systems. These tools were designed in another era, when teams used monolithic applications and updates were done once a year or even less.

The modern reality is very different. Cloud-native development, continuous CI/CD pipelines, and distributed engineering teams need a modern artifact management approach that delivers scalability, uptime, and built-in security.

This is where legacy artifact repositories fall behind. Many teams assume that on-prem systems are “more secure” because they’re isolated, but isolation no longer protects against today’s threats. Most attacks now originate upstream, through open-source dependencies that already contain vulnerabilities, malicious code injections, or compromised packages. 

With the volume and speed of issues emerging in the open-source ecosystem, an isolated, self-hosted repository cannot keep pace without continuous scanning, real-time visibility, and automated updates. Without these protections, legacy artifact management becomes a blind spot in the software supply chain - quietly storing and distributing unverified or unsafe artifacts.

The hidden costs of legacy or on-premise artifact repositories

Legacy systems can feel safer to stick with - they’re already in place and “working.” But maintaining the status quo often hides bigger costs: outdated infrastructure, ongoing maintenance, and mounting security risks from unpatched or unsupported components.

Legacy repositories need to be manually patched, updated, backed up, and scaled. Teams spend valuable engineering time on server management instead of innovation. Each new project or environment increases the complexity of configuration and slows down the development.

Hosting artifact repositories either in on-prem or in self-managed cloud VMs requires continued expenditure on storage, bandwidth, and compute. The costs increase unintentionally as the size and volume of artifacts grows (especially large Docker images or build artifacts). Beyond infrastructure, many older systems also require costly vendor support contracts for upgrades, patches, and troubleshooting. These fees often increase over time and are non-negotiable.

Legacy systems often lack built-in scanning, access control, or software bill of materials (SBOM) capabilities. Lacking transparency in dependencies leaves teams exposed to vulnerabilities and unmet compliance requirements - something that enterprises will not be able to afford in 2025 and beyond's regulatory environment.

As repositories grow, performance bottlenecks emerge - developers face slower downloads, failed builds, and pipeline downtime, all of which directly slow release velocity and drain productivity.

Why cloud-native artifact management is a change worth making

Legacy tools may have provided the groundwork for early DevOps, but they cannot keep up with the current software landscape. Modern organizations need next-generation artifact management - cloud-native solutions designed for speed, security, scalability, and seamless integration with cloud-native CI/CD pipelines.

 platform is more than just a storage location for packages - it’s a critical pillar of your software supply chain security. It guarantees that every artifact, from source to deployment, is verified, traceable, and instantly accessible, regardless of where your teams are working.

These capabilities are exactly why more organizations are moving to modern, cloud-native platforms that combine speed, security, and scalability to support today’s software delivery demands - reasons we explore in detail below.

With legacy artifact repositories, engineering teams spend hours managing servers, applying patches, and juggling storage. A truly 

cloud-native artifact management platform

 is different from simply hosting a repository in the cloud—it’s built to auto-scale, self-update, and deliver continuous security without manual intervention. There’s no server downtime, no upgrade windows to schedule, and no need to plan for storage expansion - everything is handled seamlessly in the background.

Self-hosted systems cannot keep pace with the growth in artifact volume size. A cloud-native artifact management platform dynamically boosts its capacity to manage millions of artifacts across multiple teams, regions, and projects, 

Using elastic storage and edge caching CDNs, developers are always guaranteed a 

3. Built-in security and compliance from the ground up

In today’s world, threats move faster than ever. With malicious packages and supply chain attacks on the rise, cloud-native artifact repositories integrate vulnerability scanning, access controls, and SBOMs (Software Bill of Materials) directly into your pipelines.

This ensures that all artifacts maintained and shared are validated, trackable, and consistent with the industry regulations such as SOC 2, ISO 27001, and FedRAMP.

No extra patching or standalone security tools - modern artifact management 

 into every phase of your software supply chain.

4. Performance and speed that empower developers

A truly cloud-native artifact repository ensures artifacts are forwarded to the closest edge location, which significantly decreases both the time spent building and deploying, which has a direct impact on increasing developer productivity and CI/CD throughput.

Engineers can focus on building features rather than waiting on downloads or troubleshooting failed builds, making software delivery faster, more reliable, and predictable.

5. Seamless integration with the modern DevOps toolchain

Legacy repositories often require plugins or manual scripting to integrate with CI/CD tools. Cloud-native artifact management platforms offer native integrations with 

This ensures that artifacts flow seamlessly through your CI/CD pipelines, maintaining consistency, traceability, and reliability from development all the way to production.

6. Single visibility and governance between teams

In large organizations, artifacts are often scattered across multiple repositories and sometimes duplicated, making governance and visibility a constant challenge. A cloud-native artifact management system provides a centralized, single platform for managing visibility, audit, and access.

Administrators can also manage published, promoted, or consumed artifacts - to ensure compliance and reduce the risk of unauthorized access or obsolete dependencies.

In contrast to self-managed solutions that have unpredictable infrastructure charges, cloud-native artifact management follows a usage-based pricing scheme, which is predictable.

You pay for what you use. You do not expect to incur costs for hardware, maintenance, or downtime. This will ultimately lead to a reduced total cost of ownership (TCO) and a better understanding of the ROI of engineering time.

Moving legacy artifact management to a new, modern, cloud-native repository is not just a technical choice but a strategic one that enhances both the security, performance, and user experience of developing a product or service, as well as reduces costs in the long run.

Migrating from legacy artifact management to a modern, cloud-native repository improves security, performance, and the overall developer experience while helping reduce long-term operational costs. By centralizing control, simplifying scalability, and strengthening the software supply chain, teams can focus on building software more efficiently and securely.

How to upgrade from escape legacy artifact management (step-by-step)

The idea of moving away from on-premise or legacy artifact systems to a modern, cloud-native solution can be overwhelming, but with the correct plan, it is achievable.

Review what you store (packages, containers, Helm charts, etc.) and where.

Analyze utilization and access patterns -

 Learn which teams, pipelines, and tools rely on which repositories.

Select a modern artifact management platform – 

Seek capabilities such as universal format support, security scanning, policy management, global availability, and automation through integrations.

Migrate critical projects first, automate uploads, and validate integrations.

Once migration and validation are complete, phase out outdated systems to eliminate ongoing maintenance, reduce operational overhead, and free up resources for modern, cloud-native artifact management.

 Toolkit, combined with expert support, makes the transition seamless - preserving your history and metadata while enabling improved security and scalable infrastructure.

The real ROI of leaving legacy, on-premise artifact management behind

Teams that modernize and migrate to cloud-native artifact management see measurable returns:

Reduce infrastructure expenses by up to 60%.

Faster build and deployment times across CI/CD pipelines.

Improved developer satisfaction through simplified workflows.

Better compliance posture with automated vulnerability management.

Time spent maintaining a legacy repository directly impacts productivity and costs. Migrating to a modern, cloud-native artifact repository preserves operational efficiency and supports long-term software delivery improvements.

How Cloudsmith makes modern artifact management effortless

All of these challenges, including scalability, security, automation, and visibility, can be solved with a truly cloud-native approach to artifact management. And if you are planning a migration to the cloud, it is worth doing it right rather than sticking with your existing provider simply because it feels easier. A migration is already a major change, and it is the perfect opportunity to elevate your entire artifact management program. 

Cloudsmith was built from the ground up as a fully cloud-native platform that helps teams break free from the limits of traditional repositories, delivering seamless automation, built-in security, and scalable reliability in a single unified system.

Here’s how Cloudsmith enables that transition seamlessly:

 Cloudsmith is truly cloud-native which means hosting, scaling, and security are built in. Teams can focus on development without worrying about infrastructure maintenance and downtime.

 Whether you manage containers, packages, Helm charts, or custom binaries - with multi-format repositories, Cloudsmith provides one centralized platform for all your artifacts.

 Each artifact is scanned, signed, and tracked. Cloudsmith also has vulnerability scanning, dependency metadata, and SBOM generation built-in to ensure end-to-end security for your software supply chain.

 Artifacts are served over Cloudsmith’s global edge network and minimizing latency and providing fast and reliable builds across the globe.

 Cloudsmith integrates seamlessly with the latest DevOps platforms: GitHub Actions, GitLab CI, and Jenkins - enabling teams to automate artifact workflows, reduce manual errors, and accelerate software delivery.

A modern, cloud-native artifact repository like Cloudsmith simplifies operations, strengthens security, and accelerates software delivery - without the hidden costs or complexity of legacy systems.

Summary: don’t let legacy on-premise artifact management hold you back

Legacy artifact management is not only dated - it’s also costly, risky, and non-sustainable. The emerging generation of cloud-native artifact management platforms, such as Cloudsmith, transcends complexity with confidence, enabling teams to achieve the visibility and velocity required to build securely at scale.

The faster you retire legacy systems, the sooner your organization can build securely, on a truly modern, cloud-native platform.

1. What is legacy artifact management, and why is it a problem?

The management of legacy artifacts encompasses older systems (typically 

) used to store and distribute software packages. Such systems do not offer the automation, scalability, and integrated security that are needed in modern DevOps, resulting in inefficiencies and increased operational costs.

2. What are the unknown expenses of legacy artifact repositories?

Beyond licensing, teams also bear the costs of infrastructure maintenance, downtime, manual updates, and security risks. These hidden expenses can quickly add up, often exceeding the investment required for a modern, cloud-native alternative.

3. How do I migrate to a modern artifact repository?

Begin by auditing your existing repositories, determining dependencies, and automating the migration with the help of migration tools (such as Cloudsmith’s Migration Tool). The advantage is to retain the integrity of artifacts with the purpose of avoiding manual management.

4. Why choose a cloud-native artifact repository over self-hosted options?

Uptime, scaling, and security are automatically managed on cloud-native platforms. They are CI/CD integrated, can distribute faster worldwide, and can eliminate maintenance overhead, allowing your developers to focus on their core tasks

5. How does modern artifact management improve security and compliance?

Modern artifact systems integrate vulnerability scanning, SBOMs generation, and access control. This will ensure artifacts are secure, traceable, and compliant – which is essential to securing your software supply chain.

The true cost of legacy artifact management

You've planned your migration to Cloudsmith: you know you need hybrid

, granular access controls, retention policies and vulnerability scans.

However, there is one foundational decision that must be settled first, because it underpins all subsequent security and distribution configurations: setting up custom domains for your package distribution.

While it may appear to be just another configuration option - custom domains are fundamental to establishing trust, security, and professional credibility in your software supply chain. Let's explore why.

What are custom domains as they relate to artifact management?

By default, when you access packages from Cloudsmith, your URLs follow a pattern that includes Cloudsmith's domain. With custom domains, you replace this with your company's own subdomain - something like docker.artifacts.yourcompany.com or packages.yourcompany.com. It's a simple DNS configuration that creates a profound shift in how your artifact distribution is perceived and secured.

Why would you want to use a custom domain?

When distributing software - whether to internal developers or external customers, using your own domain reinforces your brand at every touchpoint. Consider the developer experience: which feels more trustworthy? A third-party domain with your organisation name embedded in the path, or a clean domain that's clearly part of your company's infrastructure?

The custom domain maintains a professional appearance across all distribution channels and eliminates confusion about software authenticity. Many team members and customers may not even know (or need to know) that you're using Cloudsmith under the hood. Using your own domain reassures they're accessing an authoritative source directly from your organisation.

While branding matters, security is where custom domains truly shine. The benefits span multiple layers:

 is perhaps the most immediate advantage. Custom domains place you on dedicated CDN infrastructure with workspace-specific rate limits. Unlike shared Cloudsmith domains where you're subject to general limits alongside all other customers - custom domains allow you to configure rate limits that match your company's legitimate traffic patterns. This is particularly valuable during migration when transferring large volumes of packages, but it's equally important post-migration, for protecting against denial-of-service attacks with customised thresholds.

 becomes dramatically easier with custom domains. They integrate seamlessly with your security infrastructure, allowing you to monitor traffic patterns specific to your domain in firewall and proxy logs. You can integrate these metrics directly into your SIEM and monitoring tools like Datadog, set up domain-specific alerts and anomaly detection, and track DNS queries in your own logs. This visibility is invaluable for detecting unusual access patterns or potential security incidents before they become problems.

Cloudsmith Blog

Understanding S2C2F: How it strengthens OSS security

What is Software Supply Chain Integrity?

Extend EPM policies to Hugging Face artifacts

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages

The DevOps Guide to Mitigating Software Supply Chain Risks

Shai-Hulud: The Second Coming - What You Need to Know and Do Now

Understanding S2C2F: How it strengthens OSS security

What is Software Supply Chain Integrity?

Extend EPM policies to Hugging Face artifacts

Kubernetes 1.35 – What you need to know

Securing the intersection of AI models and software supply chains

The true cost of legacy artifact management

Artifact distribution: Securing the trust with your own domain

Breaking the "Department of No": Ship fast but also secure

13 sessions not to miss at KubeCon and CloudNativeCon 2025