Is https://railway.com/deploy/timescaledb-postgis still maintained?

a month ago

I want to get the latest timescaledb, postgis and postgres versions

Is there a more recent maintained template? Or should I just create my own docker image?

I'm thinking about contributing a script to automatically build a docker image with latest versions, but I noticed that https://github.com/railwayapp-templates/postgres-ssl is more active than https://github.com/railwayapp-templates/timescale-postgis-ssl and I also noticed that the Railway team is recently working on high availability databases, so I'm not sure if I should contribute to timescale-postgis-ssl repo or build my own script/fork

$10 Bounty

1 Replies

Railway

BOT

a month ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • about 1 month ago

coxdoj

HOBBY

a month ago

The Railway template is still published and its repository states that the deployed image is built from railwayapp-templates/timescale-postgis-ssl. However, it is behind the current upstream versions:

The newest Dockerfile on main is Dockerfile.pg17-ts2.17, based on timescale/timescaledb-ha:pg17-ts2.17.
PostgreSQL 18 and TimescaleDB 2.23 support was proposed in PR #7 in January 2026, but that PR is still open.
Upstream TimescaleDB has since released newer versions, so this repository is not currently tracking upstream closely.

The more active railwayapp-templates/postgres-ssl repository is not a direct replacement. It produces Railway’s SSL-enabled PostgreSQL image, but it does not add TimescaleDB and PostGIS.

For a new deployment requiring current versions, I would fork timescale-postgis-ssl or build a small derived image from a pinned upstream timescale/timescaledb-ha tag. Reuse Railway’s init-ssl.sh and wrapper.sh behavior if you need SSL plus Railway Database View compatibility.

A few precautions:

Pin an exact PostgreSQL/TimescaleDB image tag in production instead of relying on latest.
Confirm that the selected upstream image contains the required PostGIS version.
Test CREATE EXTENSION timescaledb; and CREATE EXTENSION postgis; in CI.
Test upgrades against a disposable copy of the database before changing the production image.
Keep the persistent volume and take a verified backup before any PostgreSQL major-version migration.

Contributing to the existing repository is preferable if Railway’s maintainers are willing to merge and publish the resulting image. Since PR #7 already targets PostgreSQL 18, I would first coordinate on or extend that PR rather than create a competing update. If you need the new versions immediately, use your own pinned fork while keeping the data-migration process separate from image automation.

Sources:

Welcome!