Don't just "docker-compose up"

kbariotis profile image Kostas Bariotis Originally published at kostasbariotis.com on ・3 min read

Chances are that you are working on a containerized stack. Whether you built it yourself or joined a company and found one there, you are probably using docker-compose to replicate a local development environment as close to the production as possible. (In case that you are using a different approach, please let me know in the comments. I would love to hear it!)

I am going to guess that you have been probably typing docker-compose up once you are on your desktop early in the morning and then taking a deep dive into an ocean of logs, scrolling up and down often for minutes until you find that single line you have been looking for. In this post I want to share how I have been working with docker-compose that helped me be more flexible and efficient and hopefully will help you too!

docker-compose up example

First, start docker-compose with the -d switch. From the docs:

Running docker-compose up -d starts the containers in the background and leaves them running.

You will notice that the commands exit immediately and you don't see the logs of the standard output anymore.

Let's see the state of the containers now:

> docker-compose ps

The output of the command is similar to the docker ps command. You will see a table with the names, the commands that have been used to start the containers, their state and their exposes ports. If the state of a container is Up, it means that it successfully booted up.

But where are the logs you will be wondering?

> docker-compose logs

and you will see the same output as from when we were not using the -d switch. As your docker-compose stack grows though, those logs will start to become harder and harder to watch. And also, why would you want to watch Redis logs while you are working on refactoring your favorite class?

So, since you are working on one container only and you want to watch its logs, append the container's name at the end of the command as it's written in your docker-compose.yml file. For a container called api:

> docker-compose logs api

logs will dump all logs that docker has been collecting for the whole lifetime of that container are running. These can be long and every time you call the logs command will be taking more and more time to reach the end of the output. As a solution, we can only dump the tail of our logs by using the --tail switch. Let's dump only the last 1000 lines:

> docker-compose logs --tail=1000 api

Great. But now you will have to switch on your terminal and rerun the command every time. We can leave it open with the -f switch:

> docker-compose logs --tail=1000 -f api

Yeah! That's definitely better. Add that as an alias to your shell so you won't have to remember and type it every time.

Thank you for reading this little piece. Let me know of your tips and tricks while working on your local development environment in the comments. 😎

Posted on by:

kbariotis profile

Kostas Bariotis


🖥 Software Engineer @bulbenergy, 📢 Co-organizer @devitconf, 🎤 Host @devastationtv. From 🇬🇷, living in 🇬🇧, often traveling to 🇪🇸 for my ☀️ dose.


markdown guide

First off, don't just docker-compose up cuz that's a lot to type out. Try an alias of dc to docker-compose.

Then you can add -d: dc up -d

I almost always have a production dcoker-compose.production.yml and I will alias dcp to

docker-compose -f docker-compose.yml -f docker-compose.production.yml

Also useful to have a docker-compose.override.yml. It will automatically merge that with your default docker-compose.yml unless you use the -f flag. Very useful for dev-only config (e.g. volumes to aid in development and maybe different port mappings or debug flags, etc).


I don't think docker-compose up is a lot to type, given the frequency with which you're likely to use it and the fact that it'll be in your command history a simple <ctrl-r> away if you're feeling that lazy anyway.

I'm a fan of not making aliases which shadow other commands, too - there's a good chance you have a dc on your system already, even if you don't use it.


It's not just for up, but for any docker-compose command, of which, I use many many times (I do a ton of Docker development). docker-compose is a weird one for me to type, too, and I always feel like I really stutter over it.

But to each their own!

The command docker-compose always comes out docker-compsoe the first time. Try as I might, I can never type it correctly on the first go. I don't use aliases in my shell because I like to remember the commands I'm typing and the flags I use. I feel like it forces me to think through command layout, what flags actually do and helps me remember. But I totally get the frustration of what I like to call "keyboard dyslexia". And the word compose is such that I almost always type it incorrectly the first time.

I probably type doc<tab>-c<tab> in reality. It's hard for me to test since if I just open a terminal I'll be conscious of what I'm doing, but I tab complete a lot.


Whoa, didn't know that about "override"!


Definitely useful. Just remember you'll have to clean up your containers instances manually using this method.

Usually I'll start with the -ti flags instead and use Ctrl+p,q to terminate the shell's attachment once everything is up and stable. It's valuable for me as I tend to muck with the environment a lot. If something fails before ssh inits it's handy to be able to term early. If your images and configurations are stable and rarely change, -d is probably ideal :)


I tend to leave them up and running on the stacks I am working on a daily basis. If not, I will just stop them with > docker-compose stop. Thank you for your comment! 😁


I swap between 2 different containers regularly, so I have little aliases written for aup and bup, one for each project.
For the different containers, they do:

docker-compose down
cd <a or b directory>
docker-compose up -d
docker-compose logs -f fpm

(the fpm because they are both nginx based stacks)
Works nicely and the log tails I see my containers are ready whereupon I ctrl-d and get to work :)

Of course, there is the inevitable "oh look, I have run out of memory" :( rm images, rm containers, rm volumes, restart :(


Something I didn't know I needed but I will use every single day from now on


You could just use Docker command to do all these commands after the container is running instead of using compose. Since it's just more verbose.