Recommended approach to using the Netlify CDN with Gatsby?

Hi, what’s the recommended way to deploy static assets in a Gastby app to the Netlify CDN?

My current approach is to set assetPrefix in Gatsby’s config, then override the production build command to use --prefix-paths in the Netlify config.

in file gastby-config.js:

module.exports = {
  // CDN location
  assetPrefix: '',

in file netlify.toml:

  # Gastby requires '--prefix-paths' to read 'assetPrefix' config.
  command = "gatsby build --prefix-paths"

  for = "/*"
    # Necessary to serve json and webfonts from CDN location.
    Access-Control-Allow-Origin = "*"

It still seems a bit complicated and spreads configuration out in severals places. There are now build commands in Netlify’s UI, the package.json of the project, and now another in the netlify.toml.

Is there a simpler approach?

@bradvogel Maybe I’m missing something, but aren’t all Netlify fixed assets on CDN? I thought that there is no server, and static files are pushed to the CDN as a matter of course. I don’t think you have to do anything but allow Netlify to do what it normally does.

1 Like

I should have clarified - we host our site on our apex domain (, so we do not use Netlify CDN to serve the initial page. Only for assets loaded by that page.

@bradvogel Not to be a scold, but this seems to be a violation of Section 4.2 of the Netlify Terms of Use.

How so? We worked with Netlify support on this.

The issue is that we need to own our DNS “A” record so we cannot use Netlify DNS. We also want to keep our website url instead of using a subdomain (eg Therefore, we can’t use Netlify CDN to host the apex domain. We can, however, still use it to host static assets used by our main page. I’d imagine this is a common scenario for many companies.

Let me know if I’m missing something.

@bradvogel Be that as it may, it seems my original point should be correct: If you have static assets available through Netlify, they should be served automatically via the Netlify CDN network. I don’t think there is a non-CDN option for static assets on Netlify.

Yes - the assets are uploaded and served automatically by Netlify. My post was specifically about configuring Gatsby to point to a separate domain for accessing those assets.

I’ll be glad to retitle it to make it clearer. Perhaps: “Recommended approach to configuring Gatsby to point to a different domain for assets?”. Let me know how I can clarify.

Well I suppose to the original question, I don’t think there is a recommended way because I don’t know if anybody else is actually doing this :grimacing:

For the assetPrefix concept, I might recommend using environment variables? Since that could differ per-environment. Since Gatsby only passes environment vars prefixed with GATSBY_ through to the front end, I recommend using gatsby-plugin-env-variables to get ‘normal’ named ones through instead.

You can combine that with the concept of encoding env vars into your netlify.toml for various environment (look at ACCESS_TOKEN in the sample file) if you need to. May help if you’re running deploy previews or branch previews etc. I don’t recommend encoding prod values in the netlify.toml - keep those secure by just using the UI for that.

Generally my take on build commands is this (for js SSGs like Gatsby):

  1. Ignore the UI command if you have a netlify.toml file - it’s better to have version controlled anyway
  2. Don’t call out to a tool directly if you’re using a package.json file, instead:
  3. Make your build command npm run build and tailor the build script in the package.json to be what you’d like

A command specified in the netlify.toml will always override the UI command regardless of what’s in the UI - build logs will show this too :+1:t2:

I’m definitely in this camp as well and would be curious to understand more about the DNS configuration choices instead of trying to use Netlify as just-a-CDN for assets independent from the content… if you need to own your own A record / prefer to run your own nameservers (or just not Netlify’s!) you can point your A record at Netlify’s load balancer or use an ANAME / ALIAS record at your own nameservers (if supported) and that’ll put you on track to have all the ‘automatic stuff’ running smoothly on Netlify… I tend to think that’s a much better and less complicated experience than trying to wire up a CDN interop :stuck_out_tongue:

I guess the whole paradigm just seems like… sort of a lot of work? You’re building the whole site twice in two different places then cleverly using two different domains within the content of the site to determine where the actual bytes are coming from? So even though your apex site container builds all the images in and such, it never actually pulls them from that container? :thinking: seems like a lot of legwork :confused:

Appreciate help in thinking through this with us!

In summary, the following three statements are true for us:

  1. We need to continue to use AWS DNS (vs using Netlify DNS)
  2. We want to continue using as our site URL and not a subdomain (eg
  3. AWS Route53 doesn’t support CNAME flattening for apex domains (note: it supports ALIAS records but they’re only for AWS resources)

So our only option is to point our A record to the Netlify load balancer, which means we can’t use Netlify’s CDN to serve our primary page. We do, however, serve page assets from a subdomain ( so we’re getting some value from Netlify’s CDN. Just not for the initial page load.

All AWS Route53 customers who don’t want to use Netlify’s DNS and want to serve a page from the apex domain are faced with this same challenge. Let me know if we’re missing something.


Hi, @bradvogel, we do not recommend using apex domain for the primary domain for a site for this very reason. There is a blog post with more detail here:

The only exception is if the DNS service supports some variation “CNAME on the apex domain” which is known by many names. If this is possible with a DNS service (and it sounds like it is not with Route 53) then you can safely make the apex domain primary.

If the a) apex domain is primary and b) there is only an A record for the apex, then the site will not use the CDN, high performance or regular. There is no workaround for that configuration (“a” and “b” above).