Clarify use of `hugo server` in Quick Start Guide (was "Does hugo work for normal hosting sites?") #852

suntong · 2015-01-29T05:07:47Z

Does hugo work for normal hosting sites, ie, those sites that offer static html, or dynamic php/mysql hosting? They normally will only give you (s)ftp access. hugo will not work for such home-page hosting sites right?

spf13 · 2015-01-29T05:19:07Z

Hugo works especially well on these hosted platforms.

suntong · 2015-01-29T14:16:31Z

Oh, thanks. In that case, please update either of the following articles, because I only have the impression that "Hugo contains its own ... web server. Simply run hugo server and Hugo will ... run a server with your content".

Hugo Quickstart Guide
http://gohugo.io/overview/quickstart/

Hugo Installation Guide
http://gohugo.io/overview/installing/

thanks

anthonyfok · 2015-01-29T14:25:08Z

Hello @suntong001!

But it does mention on the very first page of the documentation, i.e. http://gohugo.io/overview/introduction/:

Technically speaking, Hugo is a static site generator.

That said, our documentation does always have room for improvement, and welcome any contributions that would improve its clarity and remove obstacles for our newcomers. Would you like to kindly make the necessary edits and submit a Pull Request? 万分感谢！ 🙏

Welcome aboard!

bep · 2015-02-02T20:30:52Z

More questions? http://discuss.gohugo.io/

anthonyfok · 2015-02-16T19:31:16Z

In light of @suntong001's suggestion, as well as questions like the following popping up on our discussion forum:

that are more or less related to URLs with http://localhost:1313/ not working on a public web server, perhaps some kind of clarification in our docs may help remedy the situation.

For example, perhaps adding phrases like "development server" like on http://jekyllrb.com/docs/usage/ would help. While hugo server is certainly capable on a production server, I would say that 99% of Hugo users would prefer to use Apache, Nginx or Lighttpd to serve their static website.

spf13 · 2015-02-17T00:35:54Z

I don't like the term "development server" as it connotes that it's not ready for production usage... as is the case with Jekyll.

Hugo's server is more than powerful enough for production usage and I know of a lot of people using it as such... especially when using it with more powerful needs or when using it with Docker.

I agree we need some clarification. People are just so used to wordpress and the like and are not familiar with our new approach to things where server isn't needed (it's just static files).

anthonyfok · 2015-02-17T07:54:57Z

Good point you have there, @spf13. We should

About a week ago, I actually answered a question at http://discuss.gohugo.io/t/hugo-website-deployment/388/11 about using hugo server as a production web server on port 80:

hugo server runs an actual built-in web server, normally on port 1313, but you may set it to anything, even port 80. With that, you don't even need to have Apache running, and just run:
$ sudo hugo server --watch --baseUrl=http://yoursite.org/ --port=80 --appendPort=false
Note:

Run hugo server -h to see a description of all these options.

sudo alert! Need to be root to serve at port 80.

Running hugo server this way, the links will point to "http://yoursite.org/" rather than to "http://localhost:1313/". Yes, you must specify --baseUrl on the command-iine for this use case. You might want to add --disableLiveReload=true too, as otherwise all your webpages will have the LiveReload JavaScript snippet attached, not only for you, but also for all visitors.

I do have a question myself: Did I give the right command? It actually took me several minutes of reading hugo server -h as well as trial and error before I came up with that whole command line, and apparently, I need at least all three of --baseUrl, --port and --appendPort for hugo server to work properly as a "production web server". It was not too trivial to arrive at that to get hugo server work like e.g. Nginx, especially its use was not spelled out in the official documentation.

I can't help to think: there must be an easier way to this, perhaps by adding a new option called e.g. --production which would use the baseurl setting from config.toml, and automatically set --port 80 --appendPort=false and perhaps --disableLiveReload=true too. What do you think?

spf13 · 2015-02-17T09:54:28Z

correct and I agree, we should make a shortcut to make this easier.

Steve Francia
spf13.com
@spf13

On Feb 17, 2015, at 2:54 AM, Anthony Fok notifications@github.com wrote:

Good point you have there, @spf13. We should

About a week ago, I actually answered a question at http://discuss.gohugo.io/t/hugo-website-deployment/388/11 about using hugo server as a production web server on port 80:

hugo server runs an actual built-in web server, normally on port 1313, but you may set it to anything, even port 80. With that, you don't even need to have Apache running, and just run:

$ sudo hugo server --watch --baseUrl=http://yoursite.org/ --port=80 --appendPort=false
Note:

Run hugo server -h to see a description of all these options.

sudo alert! Need to be root to serve at port 80.

Running hugo server this way, the links will point to "http://yoursite.org/" rather than to "http://localhost:1313/". Yes, you must specify --baseUrl on the command-iine for this use case. You might want to add --disableLiveReload=true too, as otherwise all your webpages will have the LiveReload JavaScript snippet attached, not only for you, but also for all visitors.

I do have a question myself: Did I give the right command? It actually took me several minutes of reading hugo server -h as well as trial and error before I came up with that whole command line, and apparently, I need at least all three of --baseUrl, --port and --appendPort for hugo server to work properly as a "production web server". It was not too trivial to arrive at that to get hugo server work like e.g. Nginx, especially its use was not spelled out in the official documentation.

I can't help to think: there must be an easier way to this, perhaps by adding a new option called e.g. --production which would use the baseurl setting from config.toml, and automatically set --port 80 --appendPort=false and perhaps --disableLiveReload=true too. What do you think?

—
Reply to this email directly or view it on GitHub.

Jared-Prime · 2015-02-20T14:23:12Z

@anthonyfok @spf13 just to clarify: Is the recommendation for the time being to simply specify port 80? Or is there an elegant way to have nginx do a proxy_pass to the application running on another port and avoid printing port numbers in rendered hrefs?

Jared-Prime · 2015-02-20T14:26:57Z

I think I answered my question by giving another try: --appendPort=false works for what I'm looking to do. Thanks!

anthonyfok · 2015-03-04T01:19:33Z

See also #937
(Hope to find time to work on the documentation in a week or two.)

djmattyg007 · 2015-03-04T13:23:17Z

But it does mention on the very first page of the documentation, i.e. http://gohugo.io/overview/introduction/:

Technically speaking, Hugo is a static site generator.

This appears to be the google juice that helped me find hugo, but it was very frustrating to then try and work out how to use hugo as just a static site generator, without the built-in webserver.

Surely I can't be the only one in this situation? I genuinely think the ability to use it as just a generator should be far more heavily emphasised in your documentation.

@alebaffa

The `hugo help` output as shown in http://gohugo.io/overview/usage/ was not yet updated for v0.13. Thanks to @alebaffa for the heads up! Also: - Clarify that, after using `hugo server`, the bare `hugo` command need to be run before deployment. - Add a section on running `hugo` as production web server, and add links to two blog posts of two Hugo users sharing their experience. Partially fixes: #852 and #937

@alebaffa

The `hugo help` output as shown in http://gohugo.io/overview/usage/ was not yet updated for v0.13. Thanks to @alebaffa for the heads up! Also: - Clarify that, after using `hugo server`, the bare `hugo` command need to be run before deployment. - Add a section on running `hugo` as production web server, and add links to two blog posts of two Hugo users sharing their experience. Partially fixes: #852 and #937

@realchaseadams

Fixes gohugoio#922 add finalize command and tests to change draft status of specified content to false and set date to Now() undraft command Allow hyphens in shortcode name Fixes gohugoio#929 Keep trailing slash when baseUrl contains a sub path Before this commit, .Site.BaseUrl ended up as: http://mysite.com/ => http://mysite.com/ http://mysite.com/sub/ => http://mysite.com/sub Now it becomes: http://mysite.com/ => http://mysite.com/ http://mysite.com/sub/ => http://mysite.com/sub/ Fixed gohugoio#931 Improve error message on missing shortcode inner content Fixes gohugoio#933 Allow the same shortcode to be used with or without inline content Fixes gohugoio#934 Update Readme.md with additional contribution guides Added Gitter badge Restructure top of Readme.md Fixing image in readme Using a smaller Header Image Tidying the Readme a bit more Update github-pages-blog.md change `hugo serve` to `hugo server` Add benchmark for the shortcode lexer Apply gofmt -s Avoid panic when pagination on 0 pages Fixes gohugoio#948 Prevent 404.html from prettifying into 404/index.html Restore @realchaseadams's commit 348e123 "Force `UglyUrls` option to force `404.html` file name" which got lost after some refactoring (commit 8db3c0b). Remove the equivalent "force `UglyUrls`" code for `sitemap.xml` because the refactored code now calls `renderAndWriteXML()` which uses `WriteDestFile()` which does not prettify a filename. Fixes gohugoio#939 Fix errors reported by Go Vet Fix some Go Lint errors Apply some more Golint suggestions helpers: apply some Golint rules author: fix doc hugolib: apply some Hugolint rules page: make receiver name on Page methods consistent Apply some Golint rules on Page, esp. making the method receiver names consistent: (page *Page) ==> (p *Page) menu: make receiver name on Page methods consistent Apply some Golint rules on Menu, esp. making the method receiver names consistent. hugolib: apply some more Golint rules source: apply some Golint rules livereload: apply some Golint rules parser: apply some Golint rules There is only one s.PageTarget() - so we cannot change it, even tempoararily. We have to find another solution to this. ... Prevent 404.html from prettifying into 404/index.html Restore @realchaseadams's commit 348e123 "Force `UglyUrls` option to force `404.html` file name" which got lost after some refactoring (commit 8db3c0b). Remove the equivalent "force `UglyUrls`" code for `sitemap.xml` because the refactored code now calls `renderAndWriteXML()` which uses `WriteDestFile()` which does not prettify a filename. Fixes gohugoio#939 (reverted from commit c4c19ad) Handle 404 thread safely Replaces hack that temporarily changes a global flag. Fixes gohugoio#955 Fixes gohugoio#939 Fix UglyUrls on Windows Fixes gohugoio#958 Fix eq and ne tpl function issue `eq` and `ne` template functions don't work as expected when those are used with a raw number and a calculated value by add, sub etc. It's caused by both numbers type differences. For example, `eq 5 (add 2 3)` returns `false` because raw 5 is `int` while `add 2 3` returns 5 with `int64` This normalizes `int`, `uint` and `float` type values to `int64`, `uint64` and `float64` before comparing them. Other type of value is passed to comparing function without any changes. Fix gohugoio#961 Add test cases for Ne and Eq type normalisation See gohugoio#961 Add new min_version field to theme.toml template Switch from fsnotify.v0 to fsnotify.v1 API (watcher) Fixes gohugoio#357 See also gohugoio#761 Do not parse backup files with trailing '~' as templates Fixes gohugoio#964 absurlreplacer: write replacements directly to the byte buffer The extra step isn't needed and this makes the code simpler. And slightly faster: benchmark old ns/op new ns/op delta BenchmarkAbsUrl 19987 17498 -12.45% BenchmarkXmlAbsUrl 10606 9503 -10.40% benchmark old allocs new allocs delta BenchmarkAbsUrl 28 24 -14.29% BenchmarkXmlAbsUrl 14 12 -14.29% benchmark old bytes new bytes delta BenchmarkAbsUrl 3512 3297 -6.12% BenchmarkXmlAbsUrl 2059 1963 -4.66% parser: add some frontmatter test cases Skip directories like node_modules from the watchlist A local `node_modules` directory can easily contain tens of thousands of files, easily exhausting the tiny default max open files limit especially on OS X Yosemite, in spite of the fact that Hugo already had code in place since February 2014 to try to raise the maxfiles ulimit. Also skip `.git` and `bower_components` directories. The file watching situation will improve when https://github.com/go-fsnotify/fsevents become ready, but until then, we will be thrifty. :-) Thanks to @chibicode for the suggestion. See gohugoio#168 for continued discussions. Add some basic tests for doArithmetic We might have to take precision into account for floating point nubers ... at some point. doArithmetic: add test for division by zero Correct initialisms as suggested by golint First step to use initialisms that golint suggests, for example: Line 116: func GetHtmlRenderer should be GetHTMLRenderer as see on http://goreportcard.com/report/spf13/hugo Thanks to @bep for the idea! Note that command-line flags (cobra and pflag) as well as struct fields like .BaseUrl and .Url that are used in Go HTML templates need more work to maintain backward-compatibility, and thus are NOT yet dealt with in this commit. First step in fixing gohugoio#959. Remove trailing space from site build statistics Update press coverage: Fix URL; new tutorial in Chinese [Docs] Update and expand http://gohugo.io/overview/usage/ The `hugo help` output as shown in http://gohugo.io/overview/usage/ was not yet updated for v0.13. Thanks to @alebaffa for the heads up! Also: - Clarify that, after using `hugo server`, the bare `hugo` command need to be run before deployment. - Add a section on running `hugo` as production web server, and add links to two blog posts of two Hugo users sharing their experience. Partially fixes: gohugoio#852 and gohugoio#937 Add deprecated logger Add double checking in Deprecated To prevent possible duplicate log statements. source: add some test cases for File Do not ERROR-log missing /data dir Fixes gohugoio#930 Experimental AsciiDoc support with external helpers See gohugoio#470 * Based on existing support for reStructuredText files * Handles content files with extensions `.asciidoc` and `.ad` * Pipes content through `asciidoctor --safe -`. If `asciidoctor` is not installed, then `asciidoc --safe -`. * To make sure `asciidoctor` or `asciidoc` is found, after adding a piece of AsciiDoc content, run `hugo` with the `-v` flag and look for this message: INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... Caveats: * The final "Last updated" timestamp is currently not stripped. * When `hugo` is run with `-v`, you may see a lot of these messages INFO: 2015/01/23 Rendering with /usr/bin/asciidoctor ... if you have lots of `*.ad`, `*.adoc` or `*.asciidoc` files. * Some versions of `asciidoc` may have trouble with its safe mode. To test if you are affected, try this: $ echo "Hello" | asciidoc --safe - asciidoc: ERROR: unsafe: ifeval invalid asciidoc: FAILED: ifeval invalid safe document If so, I recommend that you install `asciidoctor` instead. Feedback and patches welcome! Ideally, we should be using https://github.com/VonC/asciidocgo, @VonC's wonderful Go implementation of Asciidoctor. However, there is still a bit of work needed for asciidocgo to expose its API so that Hugo can actually use it. Until then, hope this "experimental AsciiDoc support through external helpers" can serve as a stopgap solution for our community. :-) 2015-01-30: Updated for the replaceShortcodeTokens() syntax change 2015-02-21: Add `.adoc` extension as suggested by @Fale Conflicts: helpers/content.go Add Seq template func Very similar to GNU's seq. Fixes gohugoio#552 Conflicts: tpl/template.go Added image support to the sitemap.xml template Conflicts: tpl/template_embedded.go Revert "Added image support to the sitemap.xml template" This reverts commit 3c147bd. Fixes gohugoio#972 removed duplicate word in readme delete finalize files

mdhender · 2015-04-02T03:33:08Z

Would it help to add some text that describes the difference between "hugo server" and plain old "hugo"? Many of the questions that I've seen on the forums boil down to overlooking the lightly-documented hugo-with-no-command command.

Web site generators render content into HTML files. Most, like Wordpress,
Ghost, and Drupal, are "dynamic site generators." That means the HTTP
server (which is the program running on your website that the user's
browser talks to) runs the generator to create a new HTML file
each and every time a user wants to view a page.

Creating the page dynamically like this means that the computer hosting
the HTTP server has to have enough memory and CPU to effectively run
the generator around the clock. If not, then the user has to wait
in a queue for the page to be generated.

Nobody wants uses to wait longer than needed, so the dynamic site
generators programmed their systems to cache the HTML files. When
a file is cached, a copy of it is temporarily stored on the computer.
It is much faster for the HTTP server to send that copy the next time
the page is requested than it is to generate it from scratch.

Hugo takes cacheing a step further. All HTML files are rendered on your
computer and then copied to the computer hosting the HTTP server.
Since the HTML files aren't generated dynamically, we say that Hugo
is a "static site generator."

Not running a web site generator on your HTTP server has many benefits.
The most noticeable is performance - HTTP servers are very good at
sending files. So good that you can effectively serve the same number
of pages with a fraction of the memory and CPU needed for a dynamic site.

Hugo has two components to help you build and test your web site. The
one that you'll probably use most often is the built-in HTTP server.
When you run hugo server, Hugo renders all of your content into
HTML files and then runs a HTTP server on your computer so that you
can view them.

The second component is used when you're ready to publish your web
site to your HTTP server. Running Hugo without any actions will
rebuild your entire web site using the baseurl setting from your
site's configuration file. That's required to have your page links
work properly with most hosting plans.

spf13 · 2015-04-02T04:25:56Z

Please add this to the docs. It's fantastic.

Steve Francia
spf13.com
@spf13

On Apr 1, 2015, at 11:33 PM, Michael Henderson notifications@github.com wrote:

Would it help to add some text that describes the difference between "hugo server" and plain old "hugo"? Many of the questions that I've seen on the forums boil down to overlooking the lightly-documented hugo-with-no-command command.

Web site generators render content into HTML files. Most, like Wordpress,
Ghost, and Drupal, are "dynamic site generators." That means the HTTP
server (which is the program running on your website that the user's
browser talks to) runs the generator to create a new HTML file
each and every time a user wants to view a page.

Creating the page dynamically like this means that the computer hosting
the HTTP server has to have enough memory and CPU to effectively run
the generator around the clock. If not, then the user has to wait
in a queue for the page to be generated.

Nobody wants uses to wait longer than needed, so the dynamic site
generators programmed their systems to cache the HTML files. When
a file is cached, a copy of it is temporarily stored on the computer.
It is much faster for the HTTP server to send that copy the next time
the page is requested than it is to generate it from scratch.

Hugo takes cacheing a step further. All HTML files are rendered on your
computer and then copied to the computer hosting the HTTP server.
Since the HTML files aren't generated dynamically, we say that Hugo
is a "static site generator."

Not running a web site generator on your HTTP server has many benefits.
The most noticeable is performance - HTTP servers are very good at
sending files. So good that you can effectively serve the same number
of pages with a fraction of the memory and CPU needed for a dynamic site.

Hugo has two components to help you build and test your web site. The
one that you'll probably use most often is the built-in HTTP server.
When you run hugo server, Hugo renders all of your content into
HTML files and then runs a HTTP server on your computer so that you
can view them.

The second component is used when you're ready to publish your web
site to your HTTP server. Running Hugo without any actions will
rebuild your entire web site using the baseurl setting from your
site's configuration file. That's required to have your page links
work properly with most hosting plans.

—
Reply to this email directly or view it on GitHub.

mdhender · 2015-04-02T15:53:52Z

Done. It pushes the section on "How fast" to below the fold. If that's important, then the whole overview should be reorganized with one section for serious hand-holding and the other for those that think they know the basic concepts of operations.

One of the first things that new users have to understand is the difference between Hugo as a web server and Hugo as a web site generator. Issue #852 asked for documentation to make that clear. This patch updates the overview page with that information. It will seem repetitive to users that understand the difference. Weigh that against the needs of those that don't. Reference #852

moorereason · 2016-09-20T15:29:37Z

A lot has changed and many things have been rewritten/clarified since the original post. I think we're good now.

@alebaffa

The `hugo help` output as shown in http://gohugo.io/overview/usage/ was not yet updated for v0.13. Thanks to @alebaffa for the heads up! Also: - Clarify that, after using `hugo server`, the bare `hugo` command need to be run before deployment. - Add a section on running `hugo` as production web server, and add links to two blog posts of two Hugo users sharing their experience. Partially fixes: gohugoio#852 and gohugoio#937

One of the first things that new users have to understand is the difference between Hugo as a web server and Hugo as a web site generator. Issue gohugoio#852 asked for documentation to make that clear. This patch updates the overview page with that information. It will seem repetitive to users that understand the difference. Weigh that against the needs of those that don't. Reference gohugoio#852

github-actions · 2022-04-02T02:06:58Z

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

anthonyfok added the question label Jan 29, 2015

anthonyfok added the Docs label Jan 29, 2015

bep closed this as completed Feb 2, 2015

anthonyfok self-assigned this Feb 16, 2015

anthonyfok reopened this Feb 16, 2015

anthonyfok changed the title ~~Does hugo work for normal hosting sites?~~ Clarify use of hugo server in Quick Start Guide (was "Does hugo work for normal hosting sites?") Feb 16, 2015

anthonyfok mentioned this issue Mar 4, 2015

How to build static content without use of built-in webserver #937

Closed

anthonyfok added this to the v0.14 milestone Mar 12, 2015

mdhender mentioned this issue Apr 2, 2015

Add a section comparing the 'build' and 'server' #1034

Closed

mdhender mentioned this issue Apr 4, 2015

Add a section comparing the 'build' and 'server' #1038

Closed

anthonyfok mentioned this issue Sep 11, 2015

Theme not rendering, pathing issues #1421

Closed

anthonyfok removed this from the v0.14 milestone Sep 16, 2015

bep added this to the v0.17 milestone Jul 21, 2016

anthonyfok removed their assignment Sep 18, 2016

moorereason closed this as completed Sep 20, 2016

github-actions bot added the Outdated label Apr 2, 2022

github-actions bot locked as resolved and limited conversation to collaborators Apr 2, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify use of `hugo server` in Quick Start Guide (was "Does hugo work for normal hosting sites?") #852

Clarify use of `hugo server` in Quick Start Guide (was "Does hugo work for normal hosting sites?") #852

suntong commented Jan 29, 2015

spf13 commented Jan 29, 2015

suntong commented Jan 29, 2015

anthonyfok commented Jan 29, 2015

bep commented Feb 2, 2015

anthonyfok commented Feb 16, 2015

spf13 commented Feb 17, 2015

anthonyfok commented Feb 17, 2015

spf13 commented Feb 17, 2015

Jared-Prime commented Feb 20, 2015

Jared-Prime commented Feb 20, 2015

anthonyfok commented Mar 4, 2015

djmattyg007 commented Mar 4, 2015

mdhender commented Apr 2, 2015

spf13 commented Apr 2, 2015

mdhender commented Apr 2, 2015

moorereason commented Sep 20, 2016

github-actions bot commented Apr 2, 2022

Clarify use of hugo server in Quick Start Guide (was "Does hugo work for normal hosting sites?") #852

Clarify use of hugo server in Quick Start Guide (was "Does hugo work for normal hosting sites?") #852

Comments

suntong commented Jan 29, 2015

spf13 commented Jan 29, 2015

suntong commented Jan 29, 2015

anthonyfok commented Jan 29, 2015

bep commented Feb 2, 2015

anthonyfok commented Feb 16, 2015

spf13 commented Feb 17, 2015

anthonyfok commented Feb 17, 2015

spf13 commented Feb 17, 2015

Jared-Prime commented Feb 20, 2015

Jared-Prime commented Feb 20, 2015

anthonyfok commented Mar 4, 2015

djmattyg007 commented Mar 4, 2015

mdhender commented Apr 2, 2015

Would it help to add some text that describes the difference between "hugo server" and plain old "hugo"? Many of the questions that I've seen on the forums boil down to overlooking the lightly-documented hugo-with-no-command command.

spf13 commented Apr 2, 2015

mdhender commented Apr 2, 2015

moorereason commented Sep 20, 2016

github-actions bot commented Apr 2, 2022

Clarify use of `hugo server` in Quick Start Guide (was "Does hugo work for normal hosting sites?") #852

Clarify use of `hugo server` in Quick Start Guide (was "Does hugo work for normal hosting sites?") #852