How to run Go language programs on DreamHost servers using FastCGI

software development


Ok, so this is not quite a suggestion to DreamHost, but rather a suggestion to the DH users! :grinning:

Recently I’ve been playing with the Go programming language (also known as golang since there are so many things named ‘Go’, starting with the traditional Chinese/Japanese game). If you don’t know what it is, then probably this short guide will be pointless for you. I’m no Go evangelist — so I’ll stick to the basic principles: it’s a programming language developed at Google by a group lead by Ken Thompson and Rob Pike; Thompson is most famous for having developed the C programming language almost half a century ago. Go was designed to be a systems programming language, but even Google was surprised at how it quickly became used by general-purpose programmers as well. It shares some of the syntax of the C/C++/C#/Java/JS/PHP family, although the compiler provides almost all semicolons (so you don’t need to type them). It’s a strongly typed language (think about TypeScript, minus the semicolons) and therefore, unlike JS, you’re not constantly needing to figure out what type a variable is. Nevertheless, you can assign (typed) variables on demand, just as in JS and PHP, and the compiler will figure out what type the variable is — so it sort of combines the best of both worlds, while still avoiding the mess of dynamically typed languages. It’s not strictly an object-oriented language — Thompson et al. never liked the way object-oriented programming has been implemented on ‘their’ family of languages and think that, while the concept is great, the implementation sucks — on all of them. So they came up with an alternative to ‘pure’ object-oriented languages, which retains the best ideas but makes everything conceptually so much simpler. And last but not least, this was a language designed from scratch to deal with distributed computing — as opposed to ‘hacks’ on existing languages (including C!) to deal with that. Sure, semaphores and mutexes are part of the standard libraries, for those loving the traditional approach, but Go goes so much further, into uncharted regions, making distributed computing part of the language itself, and so easy to use that beginners (including yours truly) tend to abuse it — but that’s ok, Go deals with it nicely.

Go does not run on virtual machines; it is not an interpreted language and never meant to be one. Instead, it goes back to the source of systems programming: efficient native compiling, doing it ‘fast and furious’, and pretty much having compilers for all platforms (yes, including Android and iOS!). You can also do cross-compiling for multiple platforms from the same source. And the designers wanted that the resulting code is at least as fast as C. After all, one of the purposes of Go was to allow Google to pretty much replace everything they have as web services and replace it with Go. A tremendous task — there must be billions of lines of code! — but I have been assured by people quite high on the hierarchy that this is exactly what is happening.

Go has a lot of intriguing design concepts, and one of them is that everything is statically linked (no need to worry about if you have the ‘right’ dynamic libraries — DLLs under Windows — installed correctly), and that you can embed a full web server inside the programming language. That’s right: no need for Apache/Nginx, no need for mod_php or php-fpm, or Passenger, or whatever you use to run your favourite application. No need to install ‘frameworks’ either: Go is its own ‘framework’ (even though obviously there are frameworks on top of Go as well). You get everything out of the box. In that specific scenario, Go is a bit like Node.js, Python, or Ruby. There is a difference, though: no ‘emulated’, ‘interpreted’, or ‘compiled-just-in-time’ code. It’s pure, raw, natively compiled machine code.

Anyway, enough of talking about the merits of Go; if it’s the first time ever you heard about it, nothing like visiting one of the many Go tutorials — this one uses the Go Playground, an easy way of learning each lesson while trying out the code associated with it on the same web page, and being allowed to tweak it and see what happens. You’ll be up and running in a jiffy; there is no better way to learn a programming language than by example, i.e. actually writing code instead of looking at code.

So — I wondered, is this something that DreamHost supports?

Well, searching through the many DH search tools failed to get any results. Go is certainly not installed in the shared environment. And there is one key issue which is fundamental here: DreamHost is about Web hosting. So anything stored in your account should be for the purpose of sharing content online. On the other hand, while Go has its own stand-alone, built-in Web server, deploying it goes against DH’s terms of service, since you’re not supposed to have an application running all the time, consuming memory and resources. Do that too often, and DreamHost will take action — even if it’s an application that is serving Web content.

There is a solution, of course. While a Go application can be deployed on its own, in real time, there are usually some front-ends in front of it. It may simply be an nginx configured as reverse proxy, serving static resources directly while passing the rest to Go itself (Go is very efficient at serving static content as well, but some people nevertheless want something ‘in front’ of Go, fearing that it might not be able to handle the load). It might be several nginxes, concurrently sharing the load; or several Varnish front-end reverse-proxy caches… or CloudFlare… whatever. Go ‘plays nice’ with whatever is placed in front of it, and one particular configuration is, of course, running as a FastCGI application.

Now you may be thinking that having Apache using FastCGI to connect to an application means a lot of resources being wasted, namely, speed (as opposed to, say, running something as a module inside Apache, such as mod_php). But this is not necessarily the case. While the original CGI specs (which were actually developed in Apache’s immediate predecessor in the earlier 1990s) might have some performance issues, FastCGI is another beast altogether. In particular, when handling applications that fully implement FastCGI as they should, when an application is launched by Apache (which is what DH runs on the shared servers) via FastCGI, then there is a part of it that remains ‘resident’, and the rest of the code is the dispatcher/handler which actually handles the request. What this means is that you can do some setup, keep some structures in memory, and handle requests as they come in. If such requests are frequent (i.e. one per second or so), then the Go application will remain as an active running process — using Go’s thread-like goroutines to handle each request concurrently — for as long as traffic justifies it. When eventually the traffic subsides, and no requests come in for a while, then Apache and the FastCGI interface will just safely and cleanly kill the process. This is a very reasonable approach to resource allocation, not unlike what actually happens with, say, PHP. Also, the Go package that implements FastCGI does it in a way that is totally compatible with a standalone Web application (for which you get zillions of examples when googling on the Web) — basically, you don’t need to worry much if your Go application is being called by FastCGI or directly, the handling actually happens in precisely the same way.

Why would you use Go instead of much more popular solutions, such as PHP? Well, learning a new language obviously has a learning curve to overcome; writing code in Go is substantially different from PHP (I use PHP as a reference because it’s highly likely most people around here are familiar with PHP). To give you a personal example, while learning Go, I ported one application I was doing in PHP, which took me about a year to develop until I got ‘stuck’ with handling websockets and a certain degree of parallelism that the application required and that it was extremely difficult to achieve with PHP (it wasn’t impossible, just hard to do). Porting everything to Go took me about four months. The result? An application that is 3x smaller in terms of lines of code (Go is more compact in several different ways, even if at first — being a strongly typed language! — it doesn’t look like it), does some intensely CPU-bound code a thousand times faster (no joking — it’s the difference about an efficiently compiled language versus a good interpreter/compiler, but which nevertheless is nothing more than that), and, although the port was just intended to replicate the same functionality, due to the way Go works, it was so easy to extend it in so many different ways that I ended up with three times the functionality as well — things that had not been part of the specifications at all, but it was just a matter of adding a few bells and whistles as tiny snippets of code, since all the rest was supported by default anyway — it just required activating it.

The logic is therefore different. Go started as a systems programming language which got a few packages so that it became a powerful language to provide Web services quickly and efficiently — Google’s answer to interpreted languages such as Ruby on Rails, for instance. One might argue that Java, Python, etc. would all be appropriate to do the same thing. But Google was reluctant about deploying those for their core business. Facebook, as you know, had to develop their own version of PHP (known as HHVM), a compiled one, to get enough performance to deal with one billion users. Twitter had to abandon Ruby. These are the best-known examples, but there are many more: such environments are great when you start developing simple services and need to extend them quickly without much work. But at some point you’ll be dealing with the reality: millions of users pounding at your Web services, and your server(s) need to handle that amount of load. So sometimes simplifying things is the way to go (pun intended): instead of complex stacks with virtual machines, just-in-time compilers, all sorts of ‘performance enhancement’ tools and libraries, and finally your code on top (in an abstract, high-level, interpreted language), Google decided to strip down those layers and just have efficiently compiled machine code to run stuff. A stand-alone Go application serves content as fast as nginx — and that is no mean feat. Of course, nginx is a general-purpose server which can do a zillion things depending on the configuration (and still do it efficiently at all levels); while a Go application will usually implement some kind of Web service, and just stick to do that well. It works like a charm, and it’s hard to imagine anything faster (until you wish to develop your own web server in machine code!). But it’s way easier to do it in Go than in, say, C (which would certainly give you the same amount of performance) — Go’s compiler is supposed to be as good and as efficient as any modern C compiler, and to prove it, yes, Go is also working with the EFF’s famous and ubiquitous GCC compiler, so that it also compiles Go source code — for those die-hard GCC fans who only trust GCC to generate perfect machine code, the good news is that it can compile Go as well, although, honestly, I haven’t seen yet a benchmark comparing an application compiled with Go’s own compiler vs. one compiled with GCC. I would say that the differences would be tiny.

One thing that might interest DreamHost fans (just like me!) is the handling of databases. You see, in my own experience, the biggest performance hit that I get on my PHP-based things (namely WordPress, but not only that is) comes from having MySQL as a bottleneck. Of course I’m aware of all the tricks that you can do to limit the amount of MySQL calls made by a PHP application. W3 Total Cache, for instance, already includes a lot of such tricks (caching frequent MySQL requests for specific areas of the site that will not change much over time). Among other caching plugins I’ve tried out, WP Fastest Cache (which has a free and a cheap ‘premium’ option) also uses MySQL query caching on WordPress to achieve better results. Note that I’m not blaming DreamHost for their MySQL solution — it’s probably the best one they can offer considering their shared server setup. But what is the alternative? Sure, you can use sqlite3 — it does its job well enough, and at least it won’t require hitting the main DH MySQL database servers. But Go is so much more flexible in that regard — people have developed all sorts of embedded databases, some running in memory, some running from disk (this is important, since DH limits the amount of memory each process consumes). And these days there is a new trend, the concept of ‘no database’ content-management systems, where basically everything is done with static files on disk — which the user can manage directly by writing Markdown, or access through a backend. There are zillions of applications doing that — Grav, for instance, is a very popular one that runs on top of PHP. Go has its own templating system (similar to the powerful Smarty templating system for PHP), so lots of people have developed solutions on top of Go to accomplish that (Hugo is perhaps Go’s most famous zero-database CMS, or static website generators as they are known, but there are many, many more).

Anyway, enough ‘proselytising’ from someone who claimed at the beginning not to be a Go evangelist :slight_smile:

Installing Go on your DreamHost account is actually quite simple. Go to and copy the link to the latest Linux version (as I type this, it’s

Now login to your DH account. The first thing to do is to download Go:


This should leave you with a directory called go, but we’re going to change its name:

mv go go1.X (where X is the current version, e.g. go1.9; this allows you to have several Go versions side-by-side and quickly fall back to an earlier version if something doesn’t work for you on a newer one, although Go’s maintainers promise to keep backwards compatibility)

The reason for this is that Go assumes a lot of things, one of which is that your own applications will be developed under ~/go/src/my-wonderful-project-name. This directory layout for actual development would conflict with the place where the Go compiler and tools are installed, so we rename the directory with those (and in case you’re wondering: yes, Go will check that the development directories are separate from the directories where the Go compiler resides, and it will complain and refuse to run if you merge them together).

We can also prepare our first project by creating the necessary directories, e.g.:

mkdir -p ~/go/src/my-wonderful-project-name

Now we just need to make sure that our $PATH is correctly set up on the shell, as well as some environmental variables for Go to find what it needs. Open your favourite editor and add to the end of your ~/.bashrc file:
export GOROOT=$HOME/go1.9 export GOPATH=$HOME/go export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

Do a . ~/.bashrc (or log out and log in again) and you should be set up. You should be able now to run the go compiler with

go version

And that ought to output something like go version go1.9 linux/amd64 if you have everything set up properly.

Now let’s start with our first project, just to see if we have set up everything properly. Move to ~/go/src/my-wonderful-project-name and create a file called hello.go. As expected, you’ll do your first Hello, World! project here.

package main

import (

func main() {
	fmt.Println("Hello, world!")

Save it, and remain in that directory. Now run

go install

If all goes well, you should now have an executable binary in ~/go/bin/ named hello. Running it should obviously write Hello, world! on the screen (as expected).

To actually do something useful you will need to write some code that handles the FastCGI API. Here is a very simple example:

import (

func handler(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-type", "text/plain; charset=utf-8")
	fmt.Fprintln(w, "This was generated by Go running as a FastCGI app")

func main() {
	 *	Everything that is done here should be setup code etc. which is retained between calls
	http.HandleFunc("/", handler)
	// This is what actually concurrently handles requests
	if err := fcgi.Serve(nil, nil); err != nil {

Save it as before, and do a go install. This time, however, we’ll add an additional step afterwards, which is to copy the application binary to one of your actually existing domains that is being served by DreamHost:

cp ~/go/bin/hello ~/your.real.webserver.tld/hello.fcgi

DreamHost has nicely configured Apache on their shared webservers so that all directories to which the domain name points to are able to run FastCGI applications (I made a few tests and it seems that if they end with .fcgi by default, the webserver will complain the least). So there is no further configuration necessary, just try it out by pointing your web browser to:


And you should get (as expected):

This was generated by Go running as a FastCGI app

That’s it! Note that it is not unusual for the first time you run the Go compiler for it to take some time until it finishes the compilation (it’s a very silent compiler, by the way; it almost never says anything except when it stops with an error). This is normal and the behaviour is consistent among all platforms I tried (Mac OS X, FreeBSD, Ubuntu Linux, and, of course, DreamHost). As you compile more and more times the actual compiling gets faster — there must be some hidden logic behind it (so much happens ‘behind doors’…) which, for the time, still eludes me. But do not evaluate the first time it takes to compile as a baseline for using Go! It’s actually much faster on subsequent runs of the compiler; so fast, in fact, that it doesn’t ‘feel’ like compilation at all.

Of course, the next step would be to extract data passed via GET variables or POST data, which is beyond the scope of this article, but you’re quite welcome to take a look at some of my slightly more complex code at for instance. This is a ‘full’ example, intended for a more complex tutorial I’m currently writing for my own blog, and it includes a lot of bells & whistles, namely, key/value database access, complex logging (FastCGI applications cannot write errors to the console — there is no console! — so they will always need to log errors and warnings to file), parsing command-line arguments, setting things up so that the same code works either as a self-contained web app or as a FastCGI app (and even has a console mode for debugging purposes), extracting headers and parameters from a GET/POST, etc. So it does a lot of stuff… with not that many lines of code. Setting it up properly also requires understanding how to use the command go get to get packages from GitHub or elsewhere to use with your own code. All of that is really beyond this post :slight_smile: which is already way too long, and in case you’re wondering, yes, that Git repository interface on the link above is fully written in Go (and yes, it can also interface with GitHub, mirror things from there and vice-versa) but no, it does not run on DreamHost, because it was not designed to run as a FastCGI application and I couldn’t bother to change the code (it’s open source).

In fact, the major handicap in using applications that others have developed in Go is that almost all, with very few exceptions, were designed to run as self-contained, standalone apps. This is not possible under DreamHost, as explained, unless the application also supports FastCGI. A few do, most don’t.

Anyway, I just wanted to add this topic mostly because there might be people googling for friendly hosting providers that allow people to run their own Go applications, and DreamHost is certainly one of them, even though it doesn’t advertise the fact (most likely because they have never heard of Go before or were not even aware that it was so simple to install and get it running in their own servers).

Happy Go-ing :slight_smile:

Hosting a golang service on a shared server

wow, this is great stuff! I will change the title of the topic a little bit, since the way you’ve written it seems to imply that DreamHost supports Go in an official way (which at the moment is not the case).

I will also move this to a new category (HowTo) I intended to create later but your contribution kinda makes it worthwhile to accelerate plans :slight_smile:

Go language support on shared hosting

Now if everyone used Go on Dreamhost servers, they wouldn’t need to be so powerful, but we would have to watch out for the SQLite queries :slight_smile:


Right now, my biggest issue is to keep the footprint of some embedded databases small enough so that DH’s killerbots don’t kill my tiny apps (which however tend to consume a lot of memory). It’s a challenge, but it works. On the other hand, there is always the choice of using external databases, such as SQLite (obviously!) or even DH’s own MySQL servers (slow, painful, but at least the Go apps will not consume too much memory…)