<p>Redeploying with <code>docker-compose up --build -d --remove-orphans</code> did not correctly deploy the updated code, due to the caching during the build process to speed up subsequent builds. This could lead to situations where changes in your source code are not reflected in the built image because Docker is using the cached layers.  Running <code>docker-compose down --remove-orphans</code> followed by <code>docker-compose up --build -d --remove-orphans</code> effectively forces Docker to start from a clean slate, ensuring that any potential issues with caching, volume mounts, or Dockerfile changes are addressed.</p>
<p>In summary, while <code>docker-compose up --build -d --remove-orphans</code> should rebuild your images and redeploy your application with the updated code, but there are scenarios where additional steps may be necessary to ensure that changes are properly applied. Using options like <code>--no-cache</code> and explicitly rebuilding images with <code>docker-compose build</code>, as well as removing containers and volumes with <code>docker-compose down --remove-orphans</code>, can help mitigate these issues.</p>

CC BY-SA 4.0
2024-04-24T00:53:40.980Z
Are you saying the layers that are cached during the build are not used after a `docker compose down`? If so, then this answer is wrong. If I run `docker compose up --build -d` after `docker compose down` it will still use the cached layers and start almost immediately.
AndreKR
CC BY-SA 4.0
2024-04-24T04:10:47.857Z
I mentioned using the flag `--no-cache` along with the `docker-compose down` command to remove the cache. Here, in your case, only using the `docker-compose up --build -d` sometimes won't notice the small changes that have been made to your code. So when you use the `docker-compose down` command, it will pick up the change and rebuild the image for you.
Ajay
CC BY-SA 4.0
2024-04-23T04:20:29.680Z
2024-04-23T04:20:29.680Z
Ajay
<p>I'm running an application with docker compose.</p>
<pre><code>version: '3.8'
services:
  php:
    build:
      context: .
    ports:
      - &quot;[::1]:${BACKEND_PORT}:80&quot;
  frontend:
    build:
      context: .
      dockerfile: Dockerfile.frontend
    ports:
      - &quot;[::1]:${FRONTEND_PORT}:80&quot;
</code></pre>
<p>Whenever I change the source code I redeploy the application with <code>docker compose up --build -d --remove-orphans</code> and I am relatively sure that it often works.</p>
<p>I just had a situation where the deploy didn't work, it would continue to run the old code. Come to think of it, I had this happen in the past but I never paid much attention and just continued making changes and re-deploying and in the end it always worked.</p>
<p>But this time there was only one change that I wanted to deploy and this time I'm absolutely sure that <code>docker compose up --build -d --remove-orphans</code> did not correctly re-deploy the application. I ran it several times, cleared client-side caches, etc.</p>
<p>I then ran <code>docker compose down --remove-orphans</code> followed by <code>docker compose up --build -d --remove-orphans</code> and finally the application got deployed correctly.</p>
<p>Is <code>docker compose up --build -d --remove-orphans</code> not enough to re-build the image and run it?</p>

<docker><docker-compose>
How did docker compose down update the running image?
AndreKR
# How did docker compose down update the running image?

(Asked by: username_0 on 2024-04-19)

I'm running an application with docker compose.
version: '3.8'
services:
  php:
    build:
      context: .
    ports:
      - "[::1]:${BACKEND_PORT}:80"
  frontend:
    build:
      context: .
      dockerfile: Dockerfile.frontend
    ports:
      - "[::1]:${FRONTEND_PORT}:80"

Whenever I change the source code I redeploy the application with docker compose up --build -d --remove-orphans and I am relatively sure that it often works.
I just had a situation where the deploy didn't work, it would continue to run the old code. Come to think of it, I had this happen in the past but I never paid much attention and just continued making changes and re-deploying and in the end it always worked.
But this time there was only one change that I wanted to deploy and this time I'm absolutely sure that docker compose up --build -d --remove-orphans did not correctly re-deploy the application. I ran it several times, cleared client-side caches, etc.
I then ran docker compose down --remove-orphans followed by docker compose up --build -d --remove-orphans and finally the application got deployed correctly.
Is docker compose up --build -d --remove-orphans not enough to re-build the image and run it?

**Tags:** docker, docker-compose


---

## 1 answers

### Answer by username_1 on 2024-04-23. Score: -1

Redeploying with `docker-compose up --build -d --remove-orphans` did not correctly deploy the updated code, due to the caching during the build process to speed up subsequent builds. This could lead to situations where changes in your source code are not reflected in the built image because Docker is using the cached layers. Running `docker-compose down --remove-orphans` followed by `docker-compose up --build -d --remove-orphans` effectively forces Docker to start from a clean slate, ensuring that any potential issues with caching, volume mounts, or Dockerfile changes are addressed.

In summary, while `docker-compose up --build -d --remove-orphans` should rebuild your images and redeploy your application with the updated code, but there are scenarios where additional steps may be necessary to ensure that changes are properly applied. Using options like `--no-cache` and explicitly rebuilding images with `docker-compose build`, as well as removing containers and volumes with `docker-compose down --remove-orphans`, can help mitigate these issues.

> **Comments:**
> **username_0**: Are you saying the layers that are cached during the build are not used after a `docker compose down`? If so, then this answer is wrong. If I run `docker compose up --build -d` after `docker compose down` it will still use the cached layers and start almost immediately.  
> **username_1**: I mentioned using the flag `--no-cache` along with the `docker-compose down` command to remove the cache. Here, in your case, only using the `docker-compose up --build -d` sometimes won't notice the small changes that have been made to your code. So when you use the `docker-compose down` command, it will pick up the change and rebuild the image for you.  

---

