Change path where preview & livereload display

support
1

Hi! I looked at the Hugo documentation pages on Configuration and server but couldn’t quite find what I was after.

How can I change the URL (not just the port) where the preview & live reload appears when you run hugo serve?

I know you can change the port as a one-off with -p

But what if I wanted to permanently change it so that instead of being at localhost:1313 it was always at e.g. http://myActualHosting.com/admin/preview:somePort?

This feels like it’s something that I should be changing in the config.toml, but I can’t see anything in the docs that suggests its possible?

A bit more detail: as a learning exercise I’m thinking of creating a simple CMS for Hugo. I’d like to take advantage of Hugo’s live reload preview feature so that users could edit -> save -> view a preview in another tab/window immediately, before deciding whether to build. This should be doable if the CMS is also local, but it would be great to try and deploy this - so I user could log in to an “admin” section of their site and edit there. Meaning the preview needs to be at some url on the server rather than localhost.

I hope this makes sense - it’s very much a learning challenge for myself, so I may be missing something obvious.

2

Interesting exercise but from what I know Hugo server is not meant for deployment and I suppose even as an admin panel.

There are security issues with such an approach. So unless you really know what you’re doing it wouldn’t be prudent to expose a login box for the backend of your Hugo project to the internet.

3

Chiming in to what @alexandros said, hugo server is not intended for use as a daemon, but rather as a dev convenience. It’s much better to use hugo to build the site in some folder, that you then serve via one of the well-tested web servers, like Apache, Ngnix or even Caddy.

The concept you’re talking about is possible, but depends upon what your host will allow. A few shared hosts, like Webfaction, allow an app to be set up with a custom port, which then is set to proxy forward in to a port on an inside running program. It would definitely possible on hosts that are basically full *nix. I’d avoid it. Too many potential holes, and you’re just inviting trouble by doing it.

4

Thanks both for the feedback. I will look for a more sensible Go programming exercise :slight_smile: