ata loss: docker-compose.yml mounts the postgres volume at /var/lib/postgresql/data, but the image's PGDATA is /home/postgres/pgdata/data

[ArthurDZF]

Description

The published docker-compose.yml mounts the named volume postgres_data at
/var/lib/postgresql/data, but the gotempsh/timescaledb-walg:pg18 image (timescaledb-ha
based) initialises its cluster in PGDATA=/home/postgres/pgdata/data. The mounted volume
therefore stays empty and the real cluster lives in the container's writable layer:
every bit of data is lost the moment the container is recreated (image update,
compose down && up, host reboot with --rm-style recreation, etc.).

We lost a complete Temps instance this way — projects, API keys and ingested spans — after
a routine recreation.

Steps to reproduce

Starting from the repository's own docker-compose.yml:

docker compose up -d
docker compose exec temps-postgres printenv PGDATA
#   /home/postgres/pgdata/data          <- the real cluster
docker compose exec temps-postgres ls -A /var/lib/postgresql/data
#   (empty)                             <- what the volume is mounted on

Then create a project through the console, and:

docker compose down && docker compose up -d
# the project, its API keys and all ingested data are gone; a fresh cluster is initialised

Expected behavior

The volume should persist the cluster across container recreation.

Actual behavior

docker-compose.yml mounts the postgres volume at /var/lib/postgresql/data, but the image's PGDATA is /home/postgres/pgdata/data

Operating System

Linux

Temps version

v0.1.0

Docker version

No response

Relevant logs

Additional context

Fix

Mount the parent of PGDATA:

volumes:
  - postgres_data:/home/postgres/pgdata

Verified on our instance: after this change, two full down/up cycles preserve
everything (select id, name from projects still returns the project; the cluster files
are visible under the mounted volume).

Two remarks that may help:

• The mismatch is silent — Postgres starts happily, healthchecks pass, and nothing warns
  that the mounted volume is unused. A startup check comparing PGDATA with the mount
  points would turn a data-loss bug into a boot-time error.
• Users who have already run the current compose file cannot simply change the path:
  their existing data only exists in the container layer and is lost as soon as it is
  recreated. A note in the release notes or an upgrade guide would spare them the
  discovery we made.

[dviejokfs]

Hi @ArthurDZF, thanks for reporting this issue.

The docker-compose.yml is not meant for deployment currently, the recommended deployment is to use deploy.sh script:

curl -fsSL https://temps.sh/deploy.sh | bash

if you are running in a VPS with a publicly accessible IP, then use option 2 (quickstart) from deploy.sh

Nevertheless, I will apply the fix and there's an ongoing PR #841 that fixes docker compose deployment so that temps can run within docker without needing to expose ports manually