Why Use Fig for Docker Automation?



If you’ve been using Docker for a little while, but you’ve not tried out Fig yet, this blog is for you. Like me, you’ve probably either become used to dealing with long and unwieldy Docker commands using dozens of arguments, or you’ve come up with a bunch of shell scripts to start your containers. At its core, Fig is just a simple bit of automation and abstraction to help with this stuff.

It’s easiest to explain by showing an example. We’ll create a simple Python Flask app that shows a timestamp for every time it has been requested. The Python code isn’t really relevant, so feel free to skip it, but if you’d like to follow along, create a file app.py in a new directory with the following contents:

And the following Dockerfile:

Now the bit we’re interested in. We can build and run this application with the following Docker commands:

Or we can use Fig to do much the same. Create a fig.yml file in the same directory with the following contents:

And run fig up:

Fig will build the images (if necessary), launch the containers in the correct order and attach to them. Output from the containers is displayed prefixed with the container name (which by default is a concatenation of the directory name and image name). We can test out the containers in a new terminal:

Great, it works just the same, just with a lot less to remember — 3 Docker commands with multiple arguments have been reduced to two words. Essentially all that has happened is we’ve moved all the annoying to remember config flags out to the fig.yml file.

To stop the containers, just hit ctrl-c. You can use fig rm to remove them completely. Most of the time, you won’t want the output from the containers, so you can use fig up -d to start Fig in detached mode. You then need to use fig stop to stop the containers.

There’s really not a lot more to Fig, most commands map one for one to their docker run equivalents. There are some things you should be aware of though:

  • There is currently no syntax checking of the YAML file. This means if you make a typo, such as forgetting a character, you can end up with very confusing errors.
  • Fig has confusing behaviour with regard to volumes. When fig up executes, it will attempt to mount any previous volumes using –volumes-from. This leads to problems when the volumes statement in a fig.yml is changed, as it will often conflict with the previous volumes — generally the solution is just to make sure you always remove previous containers with fig rm. Part of the problem here is that Docker itself needs more tools for dealing with volumes.
  • Fig is largely designed to be used in development, but I’ve also found it very useful in testing and it could potentially be used in small scale deployments.

Finally, it’s worth pointing out that docker compose is in the works, which will be a successor to Fig. I would still recommend using Fig now though, as docker compose will re-use the existing Fig code and is very likely to have similar syntax and commands. Also, it’s so quick to get going with Fig that you are likely to pay back your time investment almost immediately.


  1. Thanks for posting this. I’ve been playing with Docker by deploying an ELK stack in multiple containers. The command line syntax and long list of arguments to docker is indeed a pain. After getting the stack running, I wrapped it all in a fig.yml file. Oh, my: what a pleasant change — just like you describe.

    For yucks, I also tried a Vagrant approach to running the Docker containers. Certainly do-able, but Fig is much more straight forward.

    Fig may not be Earth-shattering OMGoodness, but it certainly makes things easy with minimal new learning required.

Leave a Reply

Your email address will not be published. Required fields are marked *