Optimizing package storage (and costs!)
With tiered-storage Artifacts billing, paying attention to your artifacts usage obviously… pays off (lame joke). Here are some tips and tricks around artifacts storage, to optimize and ultimately reduce your monthly costs.
With the upcoming billing experience changes, you will only be charged for packages. Pairing that with our upcoming storage breakdown feature, this blog post will focus on optimizing and reducing your packages specifically.
Leveraging automatic retention policies
We strongly recommend using feed-level retention policies to automatically retain and delete packages.
Our retention system will optimize package deletion for the best performance possible. So your feed will continue to operate at full speed, even while processing thousands of delete operations. ✅ If there’s one takeaway from this post, it’s to make sure you’ve enabled this on all your feeds!
Sending packages to the bin
Don’t need a particular feed anymore? Delete it by going to Feed Settings. Or try taking a look at package stats… if it’s not relevant any further, delete the package version!
Deleting from recycling bin 🚮
When you delete either a feed or a package (with the above instructions), it will be moved into your recycling bin. At that point they’ll be marked for hard deletion after 30 days. This gives you flexibility in case you realize that certain package versions or feeds have active dependencies and can’t be deleted! However, these packages remain part of your billable costs. If you don’t want to wait the full 30 days, you can navigate to the recycling bin, and delete them individually.
We’re working on additional helpful tutorials on hard deletion of packages, so stay tuned.
Programatic deletions
- To delete your feeds, you can use our Feed Management APIs
- To send your packages to the recycling bin (soft delete), you can use our protocol-specific packages APIs
- Specify ‘delete’ as the batchOperationType to delete a batch of packages
Setting cost limits
There are upcoming changes around the in-product usage limits for Artifacts. If you want to stick to the free plan, make sure you’re set to the “Up to 2 GiB free” tier within the Organization Settings ==> Billing page.
Another tip here is to leverage the cost and billing management features within Azure Portal. We have Azure DevOps documentation on how to pinpoint specific charges, so take a peek.
Start cleaning up your storage 📦
Hopefully, some of these tips prove helpful in reducing or optimizing your Azure Artifacts storage, starting with packages. Give it a try, and let us know how it goes. Heads up that the deletion for artifacts is processed daily, so you may see a delay in storage size changes. Please be patient, and do reach out to us if there are any issues!
If you have any suggestions, comments, or run into issues, just post a comment below and we’ll get back to you ASAP.
Light
Dark
8 comments
Regarding the cleaning up of storage, it turns out we missed the notification about new billing changes that started on October 5th. We have reached the 2 gig limit and deleted older versions of our artifacts to reduce the storage because we don’t intend to surpass that but builds are still failing and the billing page says that we are using 2GB despite the deletion.
In your last paragraph you say “Heads up that the deletion for artifacts is processed daily, so you may see a delay in storage size changes. Please be patient, and do reach out to us if there are any issues!” Does this mean we have a day to wait before builds can succeed again or in our case we have to start paying for additional storage?
Hey Fadzai,
So the fastest way here to unblock yourselves is to up the Usage Limit. You can use the Azure Calculator to see how much you may end up paying (which shouldn’t be a lot, since again this is a monthly charge). Otherwise though, yeah it can take up to 24 hours before artifacts deletion is fully processed. You should also make sure that you’ve “hard-deleted” your artifacts, and that they are not “soft-deleted” in the Recycling Bin!
Hope this helps!
Thank you very much for the response. That is the route we ended up taking based on an assumption I made regarding the highlighted sentence in your article. Yes the extra cost is negligible so we figured we could take it until we get our space back. In the meantime I implemented a retention policy that will only keep the last 10 versions of each artifact since currently there is active development of both the artifacts and the applications that depend on them.
Thanks again for your response. And it does help a lot.
This change came as a complete suprise to use. We didn’t receive any notification about this pending change. We fixed it by removing upstream sources altogether, because this was causing the bulk of storage usage. We are really missing the feature to have a separate retention policy for packages from upstream sources. We don’t need as much versions for upstream source packages in our feed. Besides this, an option “empty recycle bin” would be very helpful. To permanently delete packages, we now have to delete them one by one. And we literally have hundreds of packages to delete
I fully agree, we have the same problem with upstream sources. Surely Microsoft can have one central cache for these sources (especially nuget.org) instead of it counting towards the size of individual feeds?
I now have approximately 200 packages sitting in the Recycle Bin, all from nuget.org, and no option to remove them all perminantely, other than performing 200 individual deletions. It also took forever to remove them all as you can only delete one version at a time.
We want to keep all of our packages (which are not very large in size) forever, so the package retension option isn’t really usable for us until it can be set for upstream sources only.
Yes, the missing Delete All/Empty Bin option is really not helping with this. Had 1000+ from upstream sources so I created a Selenium test to delete them all one by one. Can’t imagine somebody doing that by hand.
Hi,
I would like to suggest something. it would be really helpful if there is a possibility to make the “Scheduled Permenant Deletion Time” editable. It could be an effective way for optimization of the storage space. Please consider this. Or please suggest an alternative method if any to empty the recycle bin with in a less span of time.
is there any way to configure notifications for billing change or changes in azure services we are using