It's a good suggestion, meanwhile, you can use a 3rd party solution like this one:
blog: https://marcopeg.com/2019/docker-vacuum
github project: https://github.com/marcopeg/docker-vacuum

In case someone ends up wanting to set up docker vacuum with caprover like I did:

1. Create an app with persistent data
2. Don't expose as a webapp
3. Map /var/run/docker.sock to /var/run/docker.sock as a persistent directory
4. Deploy captain-definition file:

{
  "schemaVersion": 2,
  "imageName": "marcopeg/docker-vacuum"
}

In case someone ends up wanting to set up docker vacuum with caprover like I did:

1. Create an app with persistent data
2. Don't expose as a webapp
3. Map /var/run/docker.sock to /var/run/docker.sock as a persistent directory
4. Deploy captain-definition file:

{
  "schemaVersion": 2,
  "imageName": "marcopeg/docker-vacuum"
}

I had this working. Unfortunately, maybe with a docker update, the image started throwing errors.

Error: "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"

if an application is set to have 0 instances, would it be at risk to be cleaned up by Vaccum(with default settings)?

Yes please!

I think this is one of the last missing pieces to make CapRover a fully setup and forget system

Not sure if it helps, but what I do is set this in my crontab:

0 3 * * * /usr/bin/docker system prune -af

@seiyria, that might be quite dangerous. If for a reason your apps had stopped, that command will remove all your app containers too. Maybe you can redeploy but there is also a chance for Caprover to break.

Not sure if it helps, but what I do is set this in my crontab:

0 3 * * * /usr/bin/docker system prune -af

This is exactly what I do. But I also use continuous deployment model so just in case something goes wrong, I'm only one click away from a quick re-build from last git commit. So far the docker system prune option has not let me down.

Not sure if it helps, but what I do is set this in my crontab:

0 3 * * * /usr/bin/docker system prune -af

This is exactly what I do. But I also use continuous deployment model so just in case something goes wrong, I'm only one click away from a quick re-build from last git commit. So far the docker system prune option has not let me down.

Update: This bit me. I had turned off a service to back it up then it was gone when I tried to scale it from 0 back to 1. So, I recommend nobody does this.

@seiyria, that might be quite dangerous. If for a reason your apps had stopped, that command will remove all your app containers too. Maybe you can redeploy but there is also a chance for Caprover to break.

As I said before, running that command is actually dangerous. As a temporary solution, I use Portainer. I log into it once in a while and remove unused images. That's a safe solution until Caprover develops a better way.

In case someone ends up wanting to set up docker vacuum with caprover like I did:

1. Create an app with persistent data
2. Don't expose as a webapp
3. Map /var/run/docker.sock to /var/run/docker.sock as a persistent directory
4. Deploy captain-definition file:

{
  "schemaVersion": 2,
  "imageName": "marcopeg/docker-vacuum"
}

@grantcodes
getting this error: exec /bin/sh: exec format error

Usually this error happens when the cpu architecture doesn't match. Are you running on an ARM server by any chance?

Yes! I'm on Hetzner ARM64.

You can try forking the project and use buildx, similar to how CapRover build works. We compile for all CPU architectures.

Here are the relevant lines:

Thank you!

However, I just forked the repo and added a captain-definition file to deploy using dockerfile. It seemed faster. :)