Docker for Go application development and deployment

Let’s say you are starting a new project. You have selected the language to be Go and the database Mongodb. You already have both set up in your computer be it a Mac or a Windows or a Linux machine. However, you had installed the tools a long time ago and both are now backdated. You want the new project to use the latest versions; you also need the older versions for the old (still running) projects you need to work on now and then. What do you do?

Buy new computers for each new project?


However, you can imitate a new computer for each project, using virtual machines. We spin up virtual machines for each project to give it its own environment according to the requirements. Docker is one way to achieve this. And currently a very popular one too.

If you don’t know what Docker is or how it works I suggest you to read their own overview of the software here.

Only independent container platform that enables organizations to seamlessly build, share and run any application, anywhere — from hybrid cloud to the edge.

In this article I will show a brief overview of a simple docker setup for Go application development.

To get started, you need Docker installed in your system. Get the community edition here.

Project setup

Creating something too complex for this exercise will take focus away from the Docker configuration to application architecture and business logic. So I’ll stick to a “Hello world” implementation; let’s say everything else other than mainly the Docker part of the application is abstracted away.

Project structure:

├── .env
├── .gitignore
├── main.go
├── go.mod
├── docker-compose.yml
├── dev.dockerfile
└── prod.dockerfile

Initialize a new go module:

Run this in the root directory and it will create the go.mod file.

go mod init

Replace war1oc with your Github username.

This creates a go.mod file with the following contents:

module 1.13


package mainimport “fmt”func main() {
fmt.Println(“Hello, world!”)

If I run the app now, I get “Hello, world!” printed on the console.

Development Docker Environment

This is my go to Dockerfile for development environment:

FROM golang:1.13-busterRUN go get /appCOPY . .ENTRYPOINT [“reflex”, “-c”, “reflex.conf”]

As of writing this, 1.13 was the latest Go version. I also use reflex for restarting the server when files change; this helps a lot during development as the code is automatically reloaded.

The reflex.conf file:

-r ‘(\.go$|go\.mod)’ -s go run .

This means whenever a .go or go.mod file changes do go run .

This is all I need to put in my development Dockerfile.

Build an image and run a container from this:

docker build -t go-docker -f dev.dockerfile .docker run -it --rm -v `pwd`:/app --name go-docker go-docker

This will start the application in a container named go-docker from the image named go-docker and mount current directory on the host to the /app directory on the container. Any changes in the host project directory will be reflected to the container /app directory due to the volume. And if there is a file change, reflex will automatically restart the application.

Docker Compose

I use docker-compose with my projects as there are almost always different components involved (i.e., databases, swagger-ui, etc).

The docker-compose.yml file:

version: “3”services:
context: .
dockerfile: dev.dockerfile
— .:/app

Now run the application using `docker-compose up`. This is how you’ll usually start you app during development.

This docker-compose file is very tiny. Generally you are going to use docker-compose to compose several components together. An example of a more practical docker-compose file:

version: "3"services:
context: .
dockerfile: dev.dockerfile
- 8080:1323 # host:container
- .:/app
image: swaggerapi/swagger-ui
- 8081:8080
image: mongo:4
- mongodb_data:/data/db
image: mongo-express
- 8181:8081

Here you can see we have four components to our system. The server which runs at port 1323 forwarded to port 8080 on the host. A swagger-ui container for api documentation. A Mongodb container and a Mongo Express container for database. The volume of the Mongodb data ensures our data is persisted even if the Mongo container is destroyed.

When running the system using docker-compose, we can access components from inside other components by just referring the service name. For example, to access the mongo container, we don’t need to use the container’s ip address, rather we can just use mongodb://mongo as the connection string.

If we set up auth in our Mongodb database, we could use the connection string as the following:


We can also pass environment variables to our containers as you may have already noticed. We are passing AWS credentials to the server container. You can create a .env file in the root directory and place the environment variables there. Make sure you add the file to .gitignore; you don’t want these secrets to be in the version control.

A sample .env file:


Docker compose will by default look for a .env file in the root directory of your project and pass those to the mapped ones on the docker-compose.yml file.

Production Docker Environment

For production, I build the image in two stages. The first stage builds the app, the built app and required files (i.e., configuration files) are copied to the second stage which runs the app in an alpine linux based container. Alpine linux has a tiny size and reduces the size of the final image drastically.

# build stage
FROM golang:1.13-alpine AS builder
COPY . .
RUN apk add --no-cache git
RUN go build -v -o go-docker .
# final stage
FROM alpine:latest
RUN apk --no-cache add ca-certificates
COPY --from=builder /app/go-docker .
ENTRYPOINT ./go-docker

The final image size is 6.97MB only. This is absolutely fantastic because it reduces cost for storing these images in the cloud.

As a comparison, our development environment image size was 832MB. This is because it was a Debian 10 base image.
We can use Alpine linux for development environment as well if we want to, but it isn’t really necessary. We would also need to add several build tools which will eventually increase the image size.

Deploying to production

You can take your production image and deploy it to a swarm cluster. You can build the image and push it to a remote repository such as AWS’s ECR, and pull it from your server to update the service.

If you want to manage the cluster yourself, I highly recommend you go through the documentation for Docker Swarm; and use it.

Most of the time, I prefer running the cluster in a managed service such as AWS’s ECS. This saves both time and effort in creating and managing the cluster. A managed service also provides a lot of tools off the shelf such as viewing logs and metric. We can create revisions of task definitions and update the services with zero downtime.


I have been using Docker for a while now with multiple stacks and can assure you that it will ease the life of everyone in your team if used well. Getting new team members on-boarded can become a breeze when using Docker.

Find the source code for the above example here:

Tweet me at @war1oc if you have anything to ask or add.

Check out other articles from our engineering team:

Visit our website to learn more about us:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store