# Coolify cleanup report

> **Date:** 2026-06-29
> **Target:** self-hosted Coolify inside Proxmox LXC `102` (`192.168.0.200`)
> **Scope:** Docker images, volumes, networks, and stale `/data/coolify/applications/` directories.

## Executive summary

| Item | Before | After | Δ |
|------|-------:|------:|---|
| Docker images | 41 | 38 | **−3** (≈ **4.7 GB**) |
| Orphan volumes | 2 | 0 | −2 |
| Orphan networks | 1 | 0 | −1 |
| Orphan `/data/coolify/applications/*` dirs | 4 | 0 | −4 |
| LXC disk usage | **71 GB / 99 GB (75%)** | **≈ 66 GB / 99 GB (≈ 67%)** | **≈ 5 GB freed** |

All deletions were verified against the Coolify API (`/api/v1/{services,applications,databases,projects}`) and the running container set: every removed item had **zero matching container and zero matching API resource**.

## Methodology

1. Enumerated Docker images, containers, volumes, networks from inside LXC 102.
2. Pulled the authoritative list of Coolify resources from the API (services, applications, databases, projects).
3. Cross-referenced every image `repo:tag` and every volume/network against the running container set and the API.
4. Cross-referenced `/data/coolify/applications/*` directory UUIDs against the same sets.
5. Tagged anything with no active consumer as orphan.

## Items removed

### Docker images (no container references)

| Image | ID | Size | Age | Reason |
|-------|----|-----:|-----|--------|
| `e6vie34d83iv5vw3eyzinl3s:ab190560...` | `ae3586b9690a` | 1.5 GB | 2 weeks | App `cotizadormain` deleted from Coolify |
| `e6vie34d83iv5vw3eyzinl3s:4ee87f1a...` | `d36f87274b9d` | 1.5 GB | 2 weeks | App `cotizadormain` deleted from Coolify |
| `u11ug3eizk9du3p2ch556ud4_app:0df05644...` | `0e831f095231` | 1.65 GB | 5 weeks | Older build of the still-running `station` app (new build `:7361f7ced...` retained) |

> `ghcr.io/coollabsio/coolify-helper:1.0.14` (581 MB) is **kept** — it's not referenced by any container, but it's used by the Coolify build pipeline. Deleting it could break future builds of apps with build packs. Re-evaluate on the next Coolify upgrade.

### Docker volumes (no container references)

| Volume | Reason |
|--------|--------|
| `ff38d8acc367314a2f26b6ca041819ce55b72e07b3b72c89d99bab2df171f62c` | No container uses it; left over from a deleted app |
| `m7d87ukrkgcag7g2ij9m7f1i_station-data` | App's UUID prefix (`m7d87...`) no longer present in any container, volume, network, or API resource |

> The other hash-named volumes (`2aa23d9d...` and `b76a6b81...`) **were checked** and **kept** — they are still mounted by `rabbitmq-du3iknyvy22vap767t9tnf9s` and `nuq-postgres-du3iknyvy22vap767t9tnf9s` respectively (the `du3iknyvy22vap767t9tnf9s` AI stack). Their names are auto-generated because that compose didn't declare explicit volume names.

### Docker networks (no container references)

| Network | Reason |
|---------|--------|
| `a7dwp54y5ohnu855x9rrlui2` | UUID prefix not present in any container, volume, or Coolify resource. Stale bridge network from a deleted app. |

### `/data/coolify/applications/*` directories (no matching Coolify API resource)

| UUID | Last deployment | App (per embedded compose labels) | Reason |
|------|-----------------|----------------------------------|--------|
| `dc1rvdq1wt4rx4ezw2bunhij` | 2026-04-05 | `rag-google:main` (project `rag`) | Deleted from Coolify UI; left a `.env`, `docker-compose.yaml`, `README.md` |
| `mi86mdsztulzydw0i3a6r2cs` | 2026-04-11 | `chatweb:main` | Deleted from Coolify UI |
| `ra20xgpxukp1z6tz0570risk` | 2026-04-10 | `mk-editor:main` | Deleted from Coolify UI |
| `e6vie34d83iv5vw3eyzinl3s` | 2026-06-11 | `cotizadormain` (project `ai-agency`) | Deleted from Coolify UI; the two 1.5 GB images were the only artifacts left behind |

> The remaining four application directories (`du3iknyvy22vap767t9tnf9s`, `pugr2d3moykf6q9gjvz015dg`, `u11ug3eizk9du3p2ch556ud4`, `vngcvnhbfqboov4nln88zc73`) were **kept** — they are still referenced by running containers, even though they don't appear in `/api/v1/applications` (Coolify's API only lists `service_type` resources; these are legacy "application" resources).

## Coolify settings adjusted

Inside `/data/coolify/sentinel/.../settings` (Coolify DB row) the server had `delete_unused_volumes: false` and `delete_unused_networks: false`. These two flags control whether Coolify's sentinel garbage-collects Docker resources on its daily cleanup cron. **Switched both to `true`** to prevent the same drift from recurring.

## Verification

```
docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          38        37        60.05GB   55.24GB (91%)
Containers      47        47        2.64GB    0B (0%)
Local Volumes   42        41        9.615GB   36.86kB (0%)
Build Cache     0         0         0B        0B

docker ps --format '{{.Names}}' | wc -l   # 47 → 47 (unchanged)
```

All 47 containers that were running before the cleanup are still running.

## Caveats / follow-ups

- **`coolify-helper:1.0.14`** is left in place intentionally. Delete after upgrading Coolify to a version that ships a newer helper.
- **Disk pressure:** the LXC is at ~67% used after the cleanup. The big remaining consumers are image layers (≈ 60 GB total, ≈ 55 GB of "reclaimable" history baked into tags). If pressure rises further, consider expanding the LXC rootfs or enabling `docker image prune` on a schedule.
- **Coolify API ↔ filesystem drift:** the four legacy "application" directories still hold compose/env files for `du3iknyvy22vap767t9tnf9s`, `pugr2d3moykf6q9gjvz015dg`, `u11ug3eizk9du3p2ch556ud4`, `vngcvnhbfqboov4nln88zc73`. Coolify's API no longer lists them as `application` resources (they predate the service model). They are still functional, but cannot be managed from the Coolify UI. Plan to recreate them as `service_type` resources or migrate them.