Compiling and hosting Hugo on any host?

support
1

Hi everyone, I’m a designer, and I do basic HTML + CSS + jQuery front-end dev, but the documentation for Hugo seems extremely technical.

I’ve managed to install it and created a basic site using the Agency theme. Now I can’t figure out how to host it up on my hosting package with 1and1. It does not have an index.html? How do I host my site? I can preview it fine in localhost.

Is this only for Github? Can I compile my site to a working HTML site I can use anywhere, somehow?

Sorry if this seems like a stupid question, I am new to Static generators like HUGO, but it seems pretty cool and I want to learn. Any help would be appreciated.

Thanks!

2

To generate your site manually just run hugo without any options in your site’s directory. It will create a directory named public which will contain the HTML files. Generally copying whatever is inside and dropping them into the root of your website will work (this is very general advice and you may have to do things differently depending on your host).

With hugo server it is generating the site in memory and usually avoid the disk to speed up updating.

I have not looked at the documentation but it seems like we may not have anything for deployment. I think we may need to have to create a quickstart guide from start to finish.

3

The deployment part of the user guide is here: https://gohugo.io/overview/usage#deploying-your-web-site

There is some discussion about automating deployment here: https://discuss.gohugo.io/t/uploading-directly-from-the-command-line/2531/4

and a few pointers to some tools for deployment towards the end of this: https://gohugo.io/tools/

I recommend you persist with hugo - there’s a small learning curve but for me it made making websites fun again!

1 Like
4

I have separated build paths for preview, publish and project.

This is how you publish to a folder outside your Hugo project: hugo --baseURL="/" --destination= your_public_folder --theme=hugo-bootstrap.

I always having the problem remembering all the commands to use so I built my own automatic deployment tool, that has grown into a full-blown site generator as a service.

GitHub is actually very good for hosting, you can have your own custom domain and GitHub Pages is very robust and fast and you have version control.

5

In this case maybe sitecopy is for you? I use static pages at gmx, which is AFAIK the same company as 1und1. http://www.holgerschurig.de/en/blogging-with-sitecopy/

6

1and1 are the worst hosting company I’ve ever dealt with. There are a lot of better and not expensive options out there. One useful thing with a good (and smaller) hosting company is the support from knowledgable people, not a call centre.

1 Like
7

GitHub and GitLab is free. :sparkles:

8

As others have said, you can host its output anywhere, pretty much. I use Webfaction myself, and I know some are hosting on Amazon AWS S3.

9

This is important.

After running hugo server for local web development, you need to do a final hugo run without the server part of the command to rebuild your site. You may then deploy your site by copying the public/ directory to your production web server.

10

My 2 cents: I also like just publish my sites in a very simple way and I agree that Hugo documentation is a bit scant for that. I prefer to publish with just one “click” so:

hugo && sudo rsync --chown=http:http  -avz --delete --exclude lime --exclude phptest.php  public/ /srv/http/

This publishes on my own computer’s server and sudo is only necessary because that directory belongs to the webserver (hence chown). If publishing remotely it is even simpler:

hugo && rsync -avz -e ssh public/ myLoginName@my.web.host.address:/absolute/path/to/WebDocRoot

you can still use --delete and --exclude options as necessary.
If your hosting company offers only FTP access that is equally easy to set up; however ftp is less secure. My aim is to only need to enter a password when I run the command and then all is done. People sometimes say you need to set up keys - I avoid that. Keys are mainly useful to establish machine trust when you run scripts automatically. In case of SSH password entry is secured and I will run the command only myself.
And 1&1 does offer ssh access, it seems, here

If you have SSH you can use rsync or sftp or scp. And the above assumes you run the command when you are in your usual hugo root directory. And … both SSH and ftp have good graphic clients, such as FileZilla or WinSCP but there is too much clicking for my liking.

1 Like
11

The basic info you need is indeed here,

…but it is not prescriptive due to the sheer number of possible variations. For hosting that has ssh/sftp available, I use rsync, via a zsh function:

For s3, I use a different zsh function or, a circleci script.

Don’t use simple FTP, as it’s so old and insecure. It’s just a bad idea. Always go for the secure variant.

1 Like
12

Important for sure. I spent a while searching up and down for a hugo command that says deploy, build, compile, create, publlsh or whatever. The fact that the creation of the website for deployment happens transparently whenever the hugo command is executed, does not imply that the documentation for that functionality should be equally transparent.

13

Hi @casperl,

The CLI docs on hugo say:

hugo is the main command, used to build your Hugo site.

And the CLI docs on hugo server say:

‘hugo server’ will avoid writing the rendered and served content to disk, preferring to store it in memory.

So to me, the docs are clear.

If you wish to write your rendered site to disk when running hugo server, then do:

hugo server --renderToDisk

Hope this helps.

14

Thanks, it does help.

The documentation in this regard is both clear and not entirely unclear and this is an age-old problem where programmers write the documentation and not the end-users. Even though I now know that hugo is the main command to build the site due to be deployed I fell into the trap yesterday of running hugo server -w assuming that the public directory will contain the most recent version of the site and of course you will know exactly what did happen next.

I discovered that simply running hugo without parameters from the site root directory will build the latest changes to the site. Since executing hugo without parameters is also the command executed in the deploy script within the hugo site root, I presumed that is the recommended way to incorporate the latest changes.

Except that in my case running hugo without parameters it did not update all the changes. Prior to that, I changed parameters in the config.toml file, renamed some content pages for clarity and in order to make it more seo-friendly as well as making changes to a complex section specific menu that is included in a custom shortcode in order to use that specific menu on numerous future pages. Some of those changes was then not presented in the latest site code in the public folder. I then deleted the content of the public folder entirely, running the hugo command without parameters again and up to date content was only then created in the public folder.

This is not a criticism of hugo which is an amazing program but possibly my experiences will provide an insight into the end-user experience and that insight might be carried over to the Hugo documentation.

One of the problems I experience is that I used Middleman as a static site generator previously where everything had to be specified explicitly where in Hugo a number of elements function with relative transparency. Every time I assume something in Hugo without noting an implicit instruction regarding that action in the Hugo documentation, I seem to become unstuck.