Found while reviewing the platform's external service dependencies.
1. The deployment image is hosted outside the organisation
docker-compose.server.yml pulls the backend image from a registry account that sits outside lobx-platform. The back service in that file has only an image: key and no build: section, so the image cannot be produced on the deployment host — that registry is the sole source of the running program.
This means deployment depends on an account the organisation does not control.
2. A failed pull does not fail the deploy
deploy.sh currently reads:
docker compose -f "$COMPOSE_FILE" pull back || echo "Backend image pull failed; continuing with any existing local image"
If the pull fails for any reason, the script continues with whatever image is already present and exits successfully. A deploy that shipped nothing looks identical to one that worked: the service keeps running and CI stays green.
This matters more than it looks. Most deployment failures are loud and get noticed immediately. This one is quiet and could persist across several releases before anyone spots that a change never took effect.
3. The build context bypasses the repo-root ignore rules
The image is built with ./back as the context, so the repository-root .dockerignore does not apply to it. back/.dockerignore covers .env and config/auth/ but not every credential-file pattern the root file covers, so the two are inconsistent.
CI is not affected, since the files in question are gitignored and a fresh checkout does not contain them. Local builds are.
Suggested fix
Publish the image to ghcr.io under lobx-platform, which already owns this repository. That puts the registry under the same ownership as the code and removes an external account from the deployment path.
Make a failed pull fatal, and align back/.dockerignore with the root file.
Found while reviewing the platform's external service dependencies.
1. The deployment image is hosted outside the organisation
docker-compose.server.ymlpulls the backend image from a registry account that sits outsidelobx-platform. Thebackservice in that file has only animage:key and nobuild:section, so the image cannot be produced on the deployment host — that registry is the sole source of the running program.This means deployment depends on an account the organisation does not control.
2. A failed pull does not fail the deploy
deploy.shcurrently reads:If the pull fails for any reason, the script continues with whatever image is already present and exits successfully. A deploy that shipped nothing looks identical to one that worked: the service keeps running and CI stays green.
This matters more than it looks. Most deployment failures are loud and get noticed immediately. This one is quiet and could persist across several releases before anyone spots that a change never took effect.
3. The build context bypasses the repo-root ignore rules
The image is built with
./backas the context, so the repository-root.dockerignoredoes not apply to it.back/.dockerignorecovers.envandconfig/auth/but not every credential-file pattern the root file covers, so the two are inconsistent.CI is not affected, since the files in question are gitignored and a fresh checkout does not contain them. Local builds are.
Suggested fix
Publish the image to
ghcr.iounderlobx-platform, which already owns this repository. That puts the registry under the same ownership as the code and removes an external account from the deployment path.Make a failed pull fatal, and align
back/.dockerignorewith the root file.