Monitor your Package Activity and Save on Storage!
With the introduction of the Package Activity API and accompanying CLI command, you can now quickly and easily check your entire repository for packages' activity status or even take a detailed approach and view packages individually (per day/per package).
You can save on your storage costs by eliminating inactive packages and retaining only the packages you or your users derive value from storing and distributing via Cloudsmith.
Check out our blog on how to get started with monitoring your package activity.
Read More
Redirecting your Top-Level Custom Domain
If you're making use of Cloudsmith's custom domains feature, you can now request that the top-level (i.e. root page) of your domain (e.g. npm.example.com) redirects to a location of your choice.
This provides a little more "discoverability" for your users, by sending them to the right place if they go to the domain directly. Whether you want to redirect them to the UI for your repositories, or to your customer support page, we've got you covered.
If you wish to update your domains with this feature, please contact us and we'll be happy to help.
Read More
Vendors Rejoice! Analyse your Bandwidth Usage
As a vendor, understanding your bandwidth usage is an invaluable insight into how packages are distributed across your user base and how specific users have grown over a timeframe.
The easiest way to get started exploring these metrics is to check out the metrics command within the Cloudsmith CLI. Alternatively, to get more fine-grained metrics, you can implement a programmatic solution using our API or one of the API binding libraries published in various languages. Check out our blog for an overview of how to get started analysing your Bandwidth usage.
Read More
Debian Upstream Proxying and Caching now Available
We're very pleased to announce that the Debian package format now supports upstream proxying and caching.
Adding a Debian upstream allows for searching and downloading packages not yet in your Cloudsmith repository using the native apt tooling. Fetches made for packages resolved to an upstream can be cached and synchronised to your Cloudsmith repository - helping to protect your software dependencies from outages, improve visibility, and apply fine-grained access controls for your teams, customers and users.
Debian joins Maven as our second format to support proxying and caching. We are working hard to continue expanding to other supported formats. Watch this space!
Read More
More Storage Regions: Ohio and Oregon
With Cloudsmith, users have the choice to store their assets where they want, whether it's for compliance purposes or to keep them close to your users for maximum performance. We've rolled out two new US regions to give you even more choice: Ohio and Oregon. Try them out today when creating your new repositories, or transfer an existing repository to one of the new regions. If you've already transferred your repository previously, you'll need to contact us to reset it before you can transfer again (but it'll be quick and painless).
Read More
Invalidating Repository Caches, Manually
Introducing the ability to manually and eagerly invalidate a repository cache:
Cloudsmith caches data to be as quick as machine-ly possible when your users need it, but sometimes waiting for a refresh isn't fast enough. If you've made an update to a repository, such as a package republish or editing information for a package, but it doesn't get reflected immediately, it's probably because of caching. Often this is entirely automatic, but only for critical updates (e.g. a brand new package).
If you're in this situation, you can now use the manual cache invalidation function; found in the settings section of each repository. The cache will then regenerate on the next request, or ASAP for caches that are regenerated asynchronously. This affects all package format indexes, so be careful with it if performance is a priority. Invalidation is not intended for frequent use, so it'll be limited to the UI only for now.
Warning: It doesn't (yet) affect customised edge caching, that's a different layer of caching at the Content Distribution Network (CDN) level, but we do have plans for that too. So if you've used the cache invalidation and it doesn't work, check the TTL in the edge caching settings first.
If you'd like to see edge cache invalidation sooner, please let us know! :-)
Read More