Dockerfile: FROM cloudron/ai.librechat.cloudronapp:202610150224320000 → :202610230221180000.
CloudronManifest.json: version 1.4.1 → 1.4.5, changelog → * Update uv to 0.13.5.
README.md: header records the new pin; a short section on how to do the next bump.
I diffed our manifest against the official 1.4.5 one: version, changelog and the appstore's own base-image tag are the only differences that existed. With this branch applied, our copy matches the official manifest field-for-field except dockerImage (and our scheduler block, which is a deliberate addition). Upstream LibreChat is unchanged at 0.8.8 — this is a packaging bump (uv 0.13.1 → 0.13.5), not a LibreChat version change, so there is no member-visible feature delta to explain.
Why now
The daily digest flags "LibreChat upgrade available" every morning until it is done, and the gap only grows. It is also the cheapest moment to do it: no feature change, so the only variable is our own overlay.
The risk is our overlay, not the bump
Changing the base layer re-runs every build-time patch against new content: patch_index.py (title, css/js links, per-build x-coop-build marker), patch_ui_strings.py, the logo cache-bust + precompressed-sibling cleanup, the manifest/theme-color seds, and the logguard supervisor program. All are written to be non-fatal, which is exactly why a silent no-op is the failure mode to look for.
After deploying, run the full branding verification (README → "Verify after every image deploy" / ./release.sh verify) and confirm on the rendered DOM, not from build output.
Sequencing
Land this after the key-sync-in-image branch. If the base layer surprises us, the change under test should be the only one in flight.
Rollback
One-line repoint: set dockerImage back to registry.inference.coop/co-op/librechat-custom:20261023-65a38bb (the currently deployed overlay tag) and run ./release.sh deploy.
Not deployed — same blocker as the other branch: cloudron builder build is a local docker build that pushes to our registry, and no machine I have access to has docker. Ready for whoever does.
## What this changes
- `Dockerfile`: `FROM cloudron/ai.librechat.cloudronapp:202610150224320000` → `:202610230221180000`.
- `CloudronManifest.json`: `version` 1.4.1 → 1.4.5, `changelog` → `* Update uv to 0.13.5`.
- `README.md`: header records the new pin; a short section on how to do the next bump.
I diffed our manifest against the official `1.4.5` one: `version`, `changelog` and the appstore's own base-image tag are the **only** differences that existed. With this branch applied, our copy matches the official manifest field-for-field except `dockerImage` (and our `scheduler` block, which is a deliberate addition). Upstream LibreChat is unchanged at **0.8.8** — this is a packaging bump (uv 0.13.1 → 0.13.5), not a LibreChat version change, so there is no member-visible feature delta to explain.
## Why now
The daily digest flags "LibreChat upgrade available" every morning until it is done, and the gap only grows. It is also the cheapest moment to do it: no feature change, so the only variable is our own overlay.
## The risk is our overlay, not the bump
Changing the base layer re-runs every build-time patch against new content: `patch_index.py` (title, css/js links, per-build `x-coop-build` marker), `patch_ui_strings.py`, the logo cache-bust + precompressed-sibling cleanup, the manifest/theme-color seds, and the logguard supervisor program. All are written to be non-fatal, which is exactly why a silent no-op is the failure mode to look for.
After deploying, run the full branding verification (`README` → "Verify after every image deploy" / `./release.sh verify`) and confirm on the rendered DOM, not from build output.
## Sequencing
Land this **after** the key-sync-in-image branch. If the base layer surprises us, the change under test should be the only one in flight.
## Rollback
One-line repoint: set `dockerImage` back to `registry.inference.coop/co-op/librechat-custom:20261023-65a38bb` (the currently deployed overlay tag) and run `./release.sh deploy`.
Not deployed — same blocker as the other branch: `cloudron builder build` is a local docker build that pushes to our registry, and no machine I have access to has docker. Ready for whoever does.
Not deployed. Diffed against the official 1.4.5 manifest: version, changelog and
the base-image tag were the only differences, so this copy now matches official
field-for-field except dockerImage (+ our scheduler block).
The risk is the overlay, not the bump: every build-time patch runs against a new
base layer, and they are all non-fatal by design, so a silent no-op is the failure
mode. Verify on the rendered DOM. Rollback = repoint dockerImage to
20261023-65a38bb.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What this changes
Dockerfile:FROM cloudron/ai.librechat.cloudronapp:202610150224320000→:202610230221180000.CloudronManifest.json:version1.4.1 → 1.4.5,changelog→* Update uv to 0.13.5.README.md: header records the new pin; a short section on how to do the next bump.I diffed our manifest against the official
1.4.5one:version,changelogand the appstore's own base-image tag are the only differences that existed. With this branch applied, our copy matches the official manifest field-for-field exceptdockerImage(and ourschedulerblock, which is a deliberate addition). Upstream LibreChat is unchanged at 0.8.8 — this is a packaging bump (uv 0.13.1 → 0.13.5), not a LibreChat version change, so there is no member-visible feature delta to explain.Why now
The daily digest flags "LibreChat upgrade available" every morning until it is done, and the gap only grows. It is also the cheapest moment to do it: no feature change, so the only variable is our own overlay.
The risk is our overlay, not the bump
Changing the base layer re-runs every build-time patch against new content:
patch_index.py(title, css/js links, per-buildx-coop-buildmarker),patch_ui_strings.py, the logo cache-bust + precompressed-sibling cleanup, the manifest/theme-color seds, and the logguard supervisor program. All are written to be non-fatal, which is exactly why a silent no-op is the failure mode to look for.After deploying, run the full branding verification (
README→ "Verify after every image deploy" /./release.sh verify) and confirm on the rendered DOM, not from build output.Sequencing
Land this after the key-sync-in-image branch. If the base layer surprises us, the change under test should be the only one in flight.
Rollback
One-line repoint: set
dockerImageback toregistry.inference.coop/co-op/librechat-custom:20261023-65a38bb(the currently deployed overlay tag) and run./release.sh deploy.Not deployed — same blocker as the other branch:
cloudron builder buildis a local docker build that pushes to our registry, and no machine I have access to has docker. Ready for whoever does.