Both the snap daemon (snapd) and Snapcraft require network access to install, update, build and publish snaps. This page lists the hosts and ports (host:port) that are required to ensure consistent communication.
We are currently migrating some services, and consequently, the above deprecated domains remain active until the transition is complete. We will update the list when they are no longer used.
As of 2021-10-25, the *.snapcraftcontent.com domains are the following:
@ondra / @zyga-snapd / @ogra - Is this list still accurate? We’re about to deploy a Core on a large very conservative network where the network requirements are fixed. If they change, we will have to pay a hefty sum to whitelist another end-point. Hence, they cannot change. As such, I need to know that this is set and will not change for the coming year or two.
I don’t think we can guarantee that will remain static. At the very least it is highly likely that we add additional CDNs. Note we offer Snap Proxy (https://docs.ubuntu.com/snap-store-proxy/en/) as a commercial offering that is meant to handle restricted network deployments as well as other features.
@noise That’s honestly pretty bad. Almost every time we deploy into a large enterprise environment, they require a whitelist. We can’t willy-nilly change this list, as it imposes a major issue for our customers. It is also not viable to setup a proxy as part of every deployment.
This has not changed in core18, nor are there plans for it to change in core20.
Changes won’t happen “willy-nilly”, and I expect we’ll be able to give advance notice of additions to that list (right, @noise?), but when they do happen it won’t be core-dependent: if we add a CDN, whether you’re on core 16 or 18 or 20 makes no difference.
Correct that version of Core does not matter but that things can/will change over time. Incidentally I was about to make additions to this list as we will be adding some new CDN domains shortly. Edits to follow…
Is this list still up-to-date? snapcraftcontent.com is on this list, however I can’t find any reference in the snapd source code. @noise mentioned adding new CDNs, however no edits so far.
Hi all. I’ve updated the post with some new domains, as we’re migrating to new CDN provision.
The old *.cdn.snapcraft.io domains might be used if we need to roll back the migration for any reason, but it’s expected that we will fully remove them in next few months.
The valid domains are listed at the top of this post, and are either API domains, or CDN domains, and grouped as such.
snapcraft.io is a web browser front-end that uses the API domains to present a human friendly view of all things snap. It is not used by snap devices, only by users in a browser.
The snapcraftcontent.com domains are live, but we are not directing traffic to them at the moment, due to the need to communicate this change properly with our customers. However, the plan is still to switch to them, so if you are setting up network controls, you should include both *.snapcraftcontent.com and *.apps.ubuntu.com domains.
FYI, the urls for downloading snaps are generated by the store API, so that’s why you won’t find it in the snapd source code. This is allows us to direct the download to the appropriate place (e.g. cloudfront if you are inside AWS), and balance traffic between CDNs as needed.
Can this list be moved to a more appropriate format (like a wiki or website) with proper changelog tracking? This doesn’t feel like a serious way to track core requirements in a platform.
So it sounds like we should still keep everything in the list above, including all fastly domains, since no traffic is being pointed to any *.snapcraftcontent.com domain as of yet.
That is a bit odd, as I know the domain “https://fastly.cdn.snapcraft.io” gave us a lot of trouble a few weeks ago, when trying to do a required network check on it when installing our software. We basically got an error saying this didn’t exist anymore.
We are currently migrating some services, and consequently, the above deprecated domains remain active until the transition is complete. We will update the list when they are no longer used.