feat: update to latest versions of all service runtimes

[hrodmn]

• titiler-pgstac v3.0.0
• stac-fastapi-pgstac v6.3.1
• tipg v1.4.0
• stac-browser v5.0.0-rc.1 (upgrading to v5.0 while we are in here since there is a useful config change with the SB_CONFIG env var)

resolves #229

[willjnz]

Works well for me thanks!

[lhoupert]

Can we drop this pin? v0.9.11 seems to publish a linux/arm64 manifest and runs natively on Apple Silicon (verified: aarch64, schema 0.9.11, PostGIS 3.5), so this now forces emulation on such devices

[hrodmn]

do you mean just drop the platform: linux/amd64?

[lhoupert]

yes sorry! I realised I was not clear 😅

[lhoupert]

Hey I ran this branch end to end before reviewing, all four backend services plus a full build and run of the rewritten browser image and it all works!

Two things (found by Claude) that may hit people who already ran the stack before, so not PR bugs, but maybe worth a short note in the README (right under docker compose up, ~L55)?

🤖 Claude speaking:

• The browser image won't rebuild by itself. The mapping goes 8085:8085 → 8085:8080 and the new Dockerfile makes nginx listen on 8080, but docker compose up doesn't rebuild a build: service when its Dockerfile changes. So with a cached eoapi-stac-browser you get host 8085 → container 8080 and localhost:8085 just refuses the connection. docker compose up --build fixes it.
• Bumping the pgstac tag doesn't migrate an existing .pgdata. The schema only installs on an empty data dir, so get_version() stays at 0.9.6 — silently: both services return 200 against the old schema and /_mgmt/health just reports "pgstac_version": "0.9.6". Nothing breaks, you just don't get the 0.9.7–0.9.11 fixes. Fix is rm -rf .pgdata or pypgstac migrate from outside the container (pypgstac isn't installed in the pgstac image).

[hrodmn]

Bumping the pgstac tag doesn't migrate an existing .pgdata. The schema only installs on an empty data dir, so get_version() stays at 0.9.6 — silently: both services return 200 against the old schema and /_mgmt/health just reports "pgstac_version": "0.9.6". Nothing breaks, you just don't get the 0.9.7–0.9.11 fixes. Fix is rm -rf .pgdata or pypgstac migrate from outside the container (pypgstac isn't installed in the pgstac image).

@lhoupert thanks for flagging the .pgdata version issue! I think we could add a new service to docker-compose.yml that would run pypgstac migrate and include a note in the README for users who find themselves needing to migrate the databse to a newer version. We can also add a healthcheck script to the network that requires the installed pgstac version to match the image version.

[dfoley1218]

Tested this branch on Windows (Docker Desktop) against a clean .pgdata volume (PGSTAC_VERSION default 0.9.11).

The pinned STAC_BROWSER_VERSION fix works — confirms the fix for the unpinned git clone issue (#229): building stac-browser from current main fails because upstream has since moved to Vite, where index.html lives at repo root instead of public/index.html, breaking the sed step in Dockerfile.browser. Pinning to v5.0.0 avoids that entirely.

database, stac-fastapi, titiler-pgstac, and tipg all came up healthy and responded on their ports.

stac-browser itself still crashes, though, with a follow-on issue in the same Dockerfile.browser:

40-stac-browser-entrypoint.sh: line 86: can't open /etc/nginx/conf.d/default.conf.template: no such file nginx: [emerg] unknown directive "${STAC_PREFIX_REDIRECT}" in /etc/nginx/conf.d/default.conf:7

The entrypoint script copied in from the v5.0.0 build (/app/docker/docker-entrypoint.sh) expects to envsubst an nginx config template to resolve ${STAC_PREFIX_REDIRECT}, but Dockerfile.browser doesn't copy that template into the image, so nginx gets the literal placeholder and refuses to start.

Separately, unrelated to this PR but hit while testing on Windows: check-pgstac-version.sh fails with no such file or directory if checked out with CRLF line endings (the Windows git default) — the \r breaks the #!/bin/sh shebang inside the container. A .gitattributes entry (*.sh text eol=lf) would prevent that for other Windows contributors.

Happy to open a follow-up PR for the default.conf.template fix if that's useful.