Network requirements

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.

Uptime tracking for these end-points can be found on

API access

Download CDNs

:information_source: 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 2020-03-24, the * domains are the following:

Snapcraft also requires:

Devices being provisioned for brand stores will need the following:

Deprecated domains

The explicitly deprecated * domains are:


@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 know. Please escalate to @pedronis

1 Like

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 ( 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.

@zyga-snapd (or anyone else from the snapd team) Do you know if this has changed in Core 18?

I don’t know anything about this. CC @chipaca for help

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.

1 Like

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? 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 * 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.


Thanks! Is this for both Core18 and Core16?

@bloodearnest could you help clarify on this, please?

Are the following URL’s still valid? If so, what are they used for? 443 (TCP) 443 (TCP) 443 (TCP) 443 (TCP) 443 (TCP) 443 (TCP) 443 (TCP)


There is no difference in domains between core versions, same for both.

Hi Eric.

The valid domains are listed at the top of this post, and are either API domains, or CDN domains, and grouped as such. 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 domains (now and (now subsumed into are legacy domains no longer used, but we currently maintain them to support very old clients included in older Ubuntu LTS releases.


Yes, this is still up to date.

The 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 * and * 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.

1 Like

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.

Thank you, @bloodearnest.

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 * domain as of yet.

That is a bit odd, as I know the domain “” 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.

The following domains mentioned above as new requirements:

However, neither of these appear to have proper DNS records:

> $ dig +short
> $
> $ dig +short
> $

Just as comparison, others do work:

> $ dig +short