Containers, when stopped, are not removed by default. Let's stop our container and list the currently running containers:

Nothing running now. So, where are they? Well, the container is stopped and, while it's not using your processor and memory right now, it's using space. And it's not just that container, either; it's all the containers we ran before.

To see all containers, use the docker ps -a command:

Wow, that's a lot of containers. We can see that we have containers for practically all the images we built, and that means the images are also available and using our disk space:

In the case of images, we can see the size they are occupying. Since we don't need them any more, as they were non-functioning experiences, we can remove them. To do that, we need to use the rmi command and pass the image IDs, or the name and version (the TAG column), as parameters.

But before removing the images, we need to remove the containers, or Docker will deny removing them as they're being used. As a dirty workaround, we can use a useful parameter from docker ps, which returns only the container IDs and passes those to the remove command. Docker won't remove any running containers, so it's safe to run.

Start our latest container (docker start) and then list the containers (docker ps):

As described earlier, Docker will indicate each of the container IDs as it changes state (in this case, it removes them). The final error is our running container, which, as I explained earlier, Docker won't allow to be removed as it's running.

We can now do the exact same thing with the images. Those quickly occupy a lot of space and, when developing, it's easy to make changes to images and forget about non-functional images that we left behind:

The last two errors are expected. First, one of the images is from our running container. Second, the other image is the base image of our image.

You may also notice that there are way more lines than images from the previous list. They're not images; they're the layers of each image (remember the cached steps when building?). Docker stores images in layers, which means that a similar image may have layers in common, and, in turn, some disk space may be saved.

You should now have something like this:

That looks much better; no more garbage from our previous development iterations. We can now move on and focus on another dependency of our service that we still rely on and is not on a container yet.