The previous commit removed the `cms` and `cms-green` services from
docker-compose.yml. That was overreach and it broke two tests:
- src/lib/docker-build-contract.test.ts asserts the compose build passes
NEXT_DEPLOYMENT_ID: ${CMS_RELEASE:-unknown}, so a compose-built image
carries its release id.
- scripts/proxy-config.test.mjs resolves `docker compose config` and asserts
the `cms` service's host networking, volumes, healthcheck and image tag.
Both encode that docker-compose.yml is a maintained deployment surface, not a
leftover. Removing it was not my call to make while fixing a deploy.
Restored verbatim. The stray container that actually blocked port 3002 is
already gone, and nothing recreates it: there is no systemd unit or pm2
ecosystem that runs `docker compose up`, and `restart: unless-stopped` only
applies to a container that still exists. So the blocker is resolved by the
container removal alone, and compose stays intact for manual and reviewed use.
The deploy could not start its candidate because port 3002 was held by
`epicnext-cms`, a `docker compose up` replica built from the `local` image and
serving no traffic. Everything else in the pipeline was healthy: the image
built, the news browser gate passed and migrations were current.
The container was unusable for this pipeline for two reasons. It ran a
different image than any release, and its name did not match the slot the
deploy script manages — docker-compose.yml pinned `container_name: epicnext-cms`
while ci-deploy.sh expects `epicnext-cms-app` for slot A. Slot B happened to
agree (`epicnext-cms-green`), which is why 3003 deployed fine and 3002 never
could. deploy.sh already documents that compose "never managed the release
that actually ran", so the service was stale by its own account.
Removed the stray container and dropped the `cms` and `cms-green` services (plus
the now-unused x-cms anchor) from docker-compose.yml, so a reboot cannot
resurrect a replica that permanently occupies a blue/green slot. byparr is
untouched.
Also fixed the diagnostic from the previous commit, which blamed every running
container. `docker ps --filter publish=` returns nothing for --net=host
containers, so the fallback listed all of them and buried the real holder
among seven innocent ones. It now resolves the listening PID from `ss` back to
its container through /proc/<pid>/cgroup and names only that one, with the
exact `docker rm -f` command to run.
Verified: port 3002 free, live release on 3003 still serving
(status ok, database and redis true), deploy simulation 26 passed, typecheck.
- Update all DragonflyDB references to Valkey in README and docker-compose.yml
- Update install instructions to use Valkey package repository and .deb download
- Update configuration paths from /etc/dragonfly/ to /etc/valkey/
- Update version requirement to Valkey 8.x+ (successor to Redis OSS)
- Use floating node:alpine that tracks the latest supported LTS; pnpm
bootstrap follows package.json's packageManager pin.
- Drop corepack (removed from node:26), install pnpm via npm global.
- Add pnpm fetch + offline install for stable dependency-layer caching.
- Run as non-root nextjs (UID/GID 33 = host www-data) with tini as PID 1
for correct signal handling.
- Open node engines to >=20.9.0 so patches/minors float automatically.
- Add docker-preflight.sh (per-VPS checks incl. --fix) and gate docker-update.sh
so Node major upgrades require explicit review while patches deploy silently.
- update-Nitrov3.sh: build CMS into .next-staging and swap atomically so a
failed build never takes the live site down; auto-merge new variables
from .env.example; validate env for duplicates/broken lines; restart the
emulator/CMS only when rebuilt or unhealthy; fix step renumbering
- next.config.ts: support NEXT_DIST_DIR for staged production builds
- fix all TS errors (unused imports, missing tryDownloadCandidates helper)
so tsc and the production build pass clean
- add Dockerfile/.dockerignore and switch docker-compose to a CMS container
- include prevailing UI/refactor changes (SurfaceCard, ticketing, tsconfig)
- Add FLARESOLVERR_URL env var to .env.example
- Update fetchSourceFurnidata to fall back to FlareSolverr on CF challenges (403/HTML)
- Add docker-compose.yml with FlareSolverr service
- Add scripts/health-check.sh for FlareSolverr readiness check
- Add health:check script to package.json
- Document FlareSolverr setup in README
openhands
Simo