Is there a way around this?

Still trying to work out the problem with CloudFlare when they munge the mime type of the css for the generated and deployed site. There is actually a question in all of this: skip to Q U E S T I ON below.

Their support is working at cross-purposes with their devs, but that is nothing new. So, they asked me to create a subdomain, say, which will point to one of the dev (non-production) versions.

Sort of like Vercel and Netlify, but without really understanding what they are doing, they keep all of your non-product builds around. Eventually, they’ll have to gc them but for now they leave them around. they look like

For clarity, I named the project “a-view-hugo” so that becomes a subdomain of their standard dev url: .dev.pages. When there are multipe ones they put the hex string in front, but it has nothing to do with SHAs of commits. My custom domain is so that is where you can see the final site. And I use CloudFlare as the dns (though I don’t have to–they are cheap, generate https certificates automatically so and work with https).

Each time you build you get another one of the development subdomains. So, their support people want a set subdomain like But there are fundamental problems with this:

  1. All these site builder things need to know your custom domain. That let’s them stub it into their tooling when they generate some resources that need a url tied to the site–headers that aren’t under Hugo’s control. But, you can only have ONE custom domain for a project–and it is used to point to the production build (naturally, that is what you want users to see at your publicly visible URL). I can stick a CNAME record to point to another project subdomain, but it can’t ever work. Indeed, after about 6 hours, won’t resolve (522 error).
  2. Another result of these somewhat persistent ephemeral, dynamically named subdomains for dev builds is that I can’t set a baseURL so the site css ALWAYS has an incorrect url. Now, if they knew what they were doing–like Netlify, vercel, Render and others–they would use the -b cmdline option with the url they generated. They can do this under-the-hood and it would fix the problem. I can give any hugo command line I want for the build, but I can’t use -b with the dynamically generated url because I don’t know what it will be.
  3. What they need to do is use one of the dev builds to do their debugging. One problem is that it’s a beta still and the support people aren’t well-versed in their own product and certainly aren’t familiar with other build and deploy competitors. But, even if they did understand, I can’t build them a version with properly configured baseURL. See the question below…
  4. Another option is that I just turn off the worker (like an AWS Lambda, Netlify now has something like it) for the custom domain. This is easy and then they could inspect the problem. The site would be broken until I turned the worker back on. The world would keep turning. I promise you there aren’t a lot of people reading my wonderful (if I do say so myself…) Hugo blog. This is probably the simplest way out of the mess for the few days they need to poke at the patient.

Q U E S T I O N: is there a way in Hugo I can set a baseURL that enables the dev site to work properly even though that setting doesn’t match the actual URL of the site? Will either of “/” or “” work? Can I put the site CSS lower than the root level of the site? (I suspect not: browsers need to find that css before they can render any html properly)

If not, option 4 is the answer and I won’t die…

In the end, if they never fix this then I can always go back to Render (or any of the others) that do not munge the mime type of resources. The basics are pretty commoditized (the “icing” varies quite a bit…). I am just trying to help these guys get it right. They won’t be doing anything all that magical in building and deploying SSGs. But, they have their icing: strong security at outer edge of websites, a good CDN (YMMV), and pretty strong “edge” capabilities for doing stuff fancier than I’ll ever need. Ultimately, if they don’t want to get it right then that’s weird and the product “Pages” will have a bad rep and no one will use it. Doubt that is their goal. Problem with a bigg-ish company that shifts devs around is people may be technically ok but don’t always understand what they are working on. But, I doubt AWS, Google Sites or FireBase, or the MS Azure stuff have such a basic problem and they’re big companies.

If no one has an answer, don’t worry. I’ll convince them to use option 4 (I’ll suffer… :slight_smile: ).

Is there a reason for not just removing the <base href="{{ $.Site.BaseURL }}" /> from <head> for the duration? It’s not a hard requirement that you have one and you were asking about "" anyway…

1 Like

Read up about configuration directories:

Make one for the dev site, one for production and call hugo with the dev environment on your dev site.

I looked at that.

That will make it easier to have a different baseURL or any other setting for dev and production, etc.

The build command changes for each use (not linked or automatic given the way CloudFlare Pages works), which is not a big problem. But it still won’t enable the dev site to use the correct baseURL, which is unknown at the time the command is run. This is what makes Netlify, Vercel, Render work—they know the dev site url that works and they can add it to the -b option when they run the build command.

It’s more up to CF to solve but they seem pretty stymied so just trying to help.


This looks interesting. Where does this occur? I just searched the entire project and couldn’t find <base

I looked at , which only occurs in baseof.html, but there is no tag.

Could I change the url for the stylesheet? Might have to change all the layouts so they find the stylesheet…


It’s interesting.

baseURL doesn’t have much impact on content or other resources generated by Hugo.

In all of 4 cases, it generates an href that leads to the site’s url in places where users can click to get back to the top of the site. Certainly needed and annoying if it’s wrong for sure.

So, the key is that the hoster must use it for http headers including where the site style sheet is…