Trying to access local dev server with a public IP causes all sorts of problems

Hi, I am a new Hugo user. My development setup involves developing on a remote machine and testing it locally. I am able to get Hugo to work in this way, but the absURL function does not written the correct URL.
It returns localhost:1313 instead of my custom baseURL that I setup in hugo.toml
This makes some of the CSS / JS files unavailable and messes up the home URLs.

I tried to set --bind=localhost:1313 --baseURL=
But this adds another random port to it.
The server URL ends up being which breaks things.

Just wanted to know what I am doing wrong and is there a simple way to fix this.

I am able to publish the website and it all works fine. Just my development environment is broken in some places.

I would try to use

Mind the trailing /
Use port if you want a fixed one

Bind is for using a specific network interface not for the url

If 1313 is already in use hugo takes some other free one. So I suppose there was already another running instance on your machine

1 Like

Only if you use fixed URLs to point to your CSS/JS files. Use relative ones, and everything just works out. The forum is full with posts explaining how to do that. Basically:

  • set your baseURL in your configuration to your final site (
  • if you put your CSS, JS, font files in static, refer to them as described here
  • if you put your CSS, JS, font files in assets, refer to them as described here

There’s absolutely no need to use fully qualified URLs when you load CSS, JS, fonts, images from your site. Hugo will make sure that everything works if you run the server locally or use your site on the domain specified in baseURL.

I did try that. The issue is if i use --port=1313 or don’t set one, the final server starts at which is not what I want

I think this is what I will have to do, but these URLs are set inside the theme I am using. So was hoping, I wouldn’t have to change (override) those. But maybe that is the best choice.

Show the code, please, preferably your repository.

and maybe tell what exactly you want.

I’ve never seen a theme that hardcodes these values. … and absURL should respect the settings.

Which theme?

I’m with @chrillek looking at config and code will help

@chrillek My apologies. I was working in a private repo, but no reason to not make it public.

The code that causes problem is in the theme at adritian-free-hugo-theme/layouts/partials/base-foot.html at 5dc88fb3eba7c5d862834a2d494e48ddc040cea1 · zetxek/adritian-free-hugo-theme · GitHub

Currently I was able to solve it by overriding the entire partial in my code and using relative URLs similar to your suggestion. my-resume/layouts/partials/base-foot.html at main · vipulvpatil/my-resume · GitHub

This works, except this is only needed for dev. The solution seems clunky. I am trying to find a solution that does not require this overriding.

@irkode Thats whats boggling me. absURL returns localhost unless i specify a --baseURL when running the server. And even then it adds a port number to it.

If i do, hugo server --baseURL="" I get

Web Server is available at // (bind address

I already have pointing to port 1313, so the additional port breaks the links that use absURL call

It would be helpful if you explained in more detail what you’re trying to do. Why are you even setting the baseURL in your development configuration?

According to the documentation

using absURL should not cause a problem in your setting.

What I’d do is drop the development configuration and just let Hugo do what it wants with a hugo server command. That will publish your site at localhost:1313 (unless the port is already taken).

If you copy your public directory to and point your browser to that URL, everything should work.

So the root cause here is, I am developing remotely. I ssh into my remote instance and run my hugo dev server there. When I do so in vanilla mode (no additional params or configs) everything runs and I can see the site running at port 1313 on my remote machine. Code Server (code-server Docs: Run VS Code Anywhere | Coder) sets up port forwarding such that gets forwared to port 1313 on the instance. I have a DNS setup to take to my remote instance. When I test my website, certain links do not work, because they get populated as localhost:1313. This also affects the CSS and JS being loaded by the theme. So I am unable to fully test while developing.

The production version works perfectly fine. The site can be found on github pages at with all links working correctly.

I am simply trying to fix and/or improve my dev experience.

  1. as i said before: mind the trailing /
  2. your production site is served from a subfolder but your development config not

Change the baseURL to

And an estimated guess:

Your public folder on your dev server machine (and it’s copy u serve from if) contain some old files from some tryouts. This sometimes produces strange results.

Hugo does not remove anything there. It just adds and changes files. So I would start a fresh build with an empty folder and also clear the cache.

hugo server --gc --cleanDestinationDir --baseURL --port

@chrillek @irkode Firstly, thank you for the help so far.
I think I am doing a terrible job of explaining the issue. Please allow me to try again.

I have no problems in production. All links (CSS, JS and internal links) work as expected in production.

My entire issue is in development only.
I created a brand new project @ GitHub - vipulvpatil/me: Personal portfolio build using Hugo.
It has 2 commits. 1. hugo new site 2. Adding the theme.

The command i run for development is hugo server
Last output line is

Web Server is available at http://localhost:1313/ (bind address 
Press Ctrl+C to stop

Outside of Hugo, I have setup to point to localhost:1313 on this instance.
Now when I open this in my browser, I see the following problem.

As you can see, the website opens correctly, but the URL for all the JS files is incorrect. So they do not load.
The line that loads the JS shown in image is inside the theme at, adritian-free-hugo-theme/layouts/partials/base-foot.html at 5dc88fb3eba7c5d862834a2d494e48ddc040cea1 · zetxek/adritian-free-hugo-theme · GitHub

Is there any chance I can fix this, or should I simply find work arounds?

We got that. But hugo is a static site generator and it puts stuff inside because it’s told so.

My last comment was based on the content of GitHub - vipulvpatil/my-resume: A static Hugo based website displaying my resume and maybe more. and listed the issues you have there regarding your development config.

Does your development setup work if you skip the remoting stuff?
If so and the remotig stuff fails…

Seen vscode remoting. You mentioned ssh…
And hugo server… you will have to track that down step by step.

But i would say hugo server does not dynamically rewrite the generated pages

So, you’re on host A and ssh into host B. On host B, you run hugo server. Also on host B, you “set up” to “point to” localhost:1313.

If that’s the case (and I’m still not sure it is, as you use unfamiliar terms like “outside of Hugo” and “point host C to host B”):

  • start hugo server with the correct baseurl, which would be, possibly with the added directory as pointed out by @irkode .
  • also, provide a bind option to the hugo server command, pointing to the public IP address of host B.

Finally: Accessing a HTTP host via HTTPS is a bit uncommon. And your setup is, in my opinion, overly complicated. If host B has a public IP anyway, why all this “pointing to” stuff? Why not use ssh forwarding ( if you’re ssh’ing to host B anyway?

@chrillek Your understanding of my setup is correct.
The setup is new and complicated as you rightly pointed out. I am working to iron it out soon, probably do a simpler port forwarding via ssh.

I will try the --bind with --baseURL option you mentioned.

Thank you and @irkode for the help once again.

To close the loop. I simplified my overall setup as @chrillek mentioned. Port forwarded my local 1313 to the remote instance and everything worked fine.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.