feat: Add pg18beta3 container

[thomasboussekey]

based on trixie as debian-bulleye is getting old

[ImreSamu]

( @thomasboussekey )

Thank you for the PR!

1.)
The file 18-master/Dockerfile is missing,
but the GitHub CI build matrix is still referencing it.
Could you please either add the missing 18-master/Dockerfile
or remove it from the build matrix (and we can add it later)?

2.)
Currently, the images are generated with the tag postgis/postgis:18-3.5-alpine.
However, in this project the preferred approach is to use a tag like postgis/postgis:18beta3-3.5-alpine.
The reason is that the tag name should make it clear that this is still a beta version, not the final release.
This helps avoid surprises for users when PostgreSQL 18.0 is officially released and they later need to upgrade.
It also makes user support easier: if someone reports an issue, the image name itself shows whether they are using the beta or the final version.
This approach is also consistent with the upstream PostgreSQL Docker images - for example, at https://hub.docker.com/_/postgres there is no 18-trixie tag yet, only 18beta3-trixie.
So the only change needed here is to move the directory from 18-3.5 to 18beta3-3.5 with
git mv 18-3.5 18beta3-3.5 and then update the build matrix accordingly.
( For reference, here is a sample PR for 17beta3: https://github.com/postgis/docker-postgis/pull/388/files )

3.)
Additionally, if possible, please update the README.md:

• The update.sh script generates a markdown table (for debian, alpine, test) in the logs. You can copy-paste that to refresh the relevant sections of the README.md.
• Also, please update the date in the header line # Versions (2025-07-11) to match the modification date.

[thomasboussekey]

( @thomasboussekey )

Thank you for the PR!

1.) The file 18-master/Dockerfile is missing, but the GitHub CI build matrix is still referencing it. Could you please either add the missing 18-master/Dockerfile or remove it from the build matrix (and we can add it later)?

2.) Currently, the images are generated with the tag postgis/postgis:18-3.5-alpine. However, in this project the preferred approach is to use a tag like postgis/postgis:18beta3-3.5-alpine. The reason is that the tag name should make it clear that this is still a beta version, not the final release. This helps avoid surprises for users when PostgreSQL 18.0 is officially released and they later need to upgrade. It also makes user support easier: if someone reports an issue, the image name itself shows whether they are using the beta or the final version. This approach is also consistent with the upstream PostgreSQL Docker images - for example, at https://hub.docker.com/_/postgres there is no 18-trixie tag yet, only 18beta3-trixie. So the only change needed here is to move the directory from 18-3.5 to 18beta3-3.5 with git mv 18-3.5 18beta3-3.5 and then update the build matrix accordingly. ( For reference, here is a sample PR for 17beta3: https://github.com/postgis/docker-postgis/pull/388/files )

3.) Additionally, if possible, please update the README.md:

• The update.sh script generates a markdown table (for debian, alpine, test) in the logs. You can copy-paste that to refresh the relevant sections of the README.md.
• Also, please update the date in the header line # Versions (2025-07-11) to match the modification date.

Thanks @ImreSamu , fix in progress!

For 1️⃣ , it should be named 18beta3-master, no?

For 2️⃣ , folder has been renamed

For 3️⃣ , for tomorrow 😪

[ImreSamu]

For 1️⃣ , it should be named 18beta3-master, no?

Yes, correct.
But since Dockerfile.master.template has not been tested with Trixie,
there could be potential issues.
If you cannot resolve this now, I think it’s fine to leave it for later.

For 2️⃣ , folder has been renamed

Great!
In that case, please also update .github/workflows/main.yml accordingly.

[ImreSamu]

In the meantime, PostGIS 3.6.0rc1 has also been released (2025/08/18):

• https://git.osgeo.org/gitea/postgis/postgis/raw/tag/3.6.0rc1/NEWS

If possible, could you also update:
17-3.6.0beta1 → 17-3.6.0rc1
And maybe even add a 18beta3-3.6.0rc1 version, which could be useful.

Of course, no problem if you prefer to skip these changes in this PR - I can add them later myself.

Thanks in advance!

[thomasboussekey]

@ImreSamu should the script use this location, in order to download postgis 3.6rc1?
I'm not an expert of DEBIAN packages 🤣

[ImreSamu]

should the script use this location,
in order to download postgis 3.6rc1?
I'm not an expert of DEBIAN packages 🤣

I’m not an expert either 🙂

Traditionally we use apt.postgresql.org because it aligns with upstream docker postgresql and makes it easy to extend with other packages (e.g. pgrouting ).
The downside is that PostGIS Debian packages are usually updated more slowly.
Right now, the latest Debian packages I see are still at postgis 3.5.3:
https://www.postgresql.org/search/?m=1&q=postgresql-18-postgis-3&l=76&d=365&s=d

postgresql-18-postgis-3 | 3.5.3+dfsg-1~exp1.pgdg130+1 | trixie-pgdg | amd64, arm64, ppc64el
postgresql-18-postgis-3 | 3.5.3+dfsg-1~exp1.pgdg120+1 | bookworm-pgdg | amd64, arm64, ppc64el

If you’re interested in following the apt.postgresql.org - debian postgis packaging process more closely,
the mailing list is a good resource: https://www.postgresql.org/list/pgsql-pkg-debian/

The Debian experimental package
is interesting, but I think using it would mean losing the easy compatibility and extension ecosystem (pgrouting, mobilitydb, …).

So my preference would be to keep the current conservative approach,
and for Debian-based images only use PostGIS versions available from apt.postgresql.org .

in order to download postgis 3.6rc1?

So we should wait until it appears on apt.postgresql.org (most likely 1–2 weeks after the official 3.6.0 release).

---

And thanks a lot for updating the images!

When your changes are ready for another review, please let us know.

[thomasboussekey]

should the script use this location,
in order to download postgis 3.6rc1?
I'm not an expert of DEBIAN packages 🤣

I’m not an expert either 🙂

Traditionally we use apt.postgresql.org because it aligns with upstream docker postgresql and makes it easy to extend with other packages (e.g. pgrouting ). The downside is that PostGIS Debian packages are usually updated more slowly. Right now, the latest Debian packages I see are still at postgis 3.5.3: https://www.postgresql.org/search/?m=1&q=postgresql-18-postgis-3&l=76&d=365&s=d

postgresql-18-postgis-3 | 3.5.3+dfsg-1~exp1.pgdg130+1 | trixie-pgdg | amd64, arm64, ppc64el
postgresql-18-postgis-3 | 3.5.3+dfsg-1~exp1.pgdg120+1 | bookworm-pgdg | amd64, arm64, ppc64el

If you’re interested in following the apt.postgresql.org - debian postgis packaging process more closely, the mailing list is a good resource: https://www.postgresql.org/list/pgsql-pkg-debian/

The Debian experimental package is interesting, but I think using it would mean losing the easy compatibility and extension ecosystem (pgrouting, mobilitydb, …).

So my preference would be to keep the current conservative approach, and for Debian-based images only use PostGIS versions available from apt.postgresql.org .

in order to download postgis 3.6rc1?

So we should wait until it appears on apt.postgresql.org (most likely 1–2 weeks after the official 3.6.0 release).

And thanks a lot for updating the images!

When your changes are ready for another review, please let us know.

@ImreSamu , it looks good now! I managed to fix Pg18beta3 Dockerfile generation 😅

[ImreSamu]

@thomasboussekey :

Thank you for this excellent work! The changes are looking really good overall.

I've spotted two minor issues that would be worth addressing:

1. Directory cleanup needed
   The 17-3.6.0beta1 directory is still present in the repository.
   Ideally, we would have used git mv 17-3.6.0beta1 17-3.6.0rc1 to rename it during the transition, but at this point I think a simple git rm 17-3.6.0beta1 would do the job perfectly.
   Once that's removed, you'll also need to update the README.md since ./update.sh won't include it in the test matrix anymore.

2. Duplicate entry in workflow
   The .github/workflows/main.yml matrix appears to contain 18beta3-3.5 twice now.
   I believe we can safely remove the duplicate entries from the include: section.

What's working brilliantly:

• The ./update.sh script is functioning exactly as expected
• Your pg18 -> trixie solution is really clever; I'm quite impressed with that approach! 💯

These are just small housekeeping items, and the core functionality looks spot on.
Thanks again for your thorough work on this!

[ImreSamu]

Duplicate entries - the original matrix already includes these combinations.
I think these can be removed.

• 18beta3-3.5-default - 'ubuntu-24.04'
• 18beta3-3.5-default - 'ubuntu-24.04-arm'

[thomasboussekey]

All the other editions are written that way, see here
According to the matrix, defined here, I agree with you!

So, I deduplicate all the lines and remove runner-platform in ALL entries?

[thomasboussekey]

Same question about the variant key 🤔

... trying something 🤞

[thomasboussekey]

Pushed commit 53506a4

[thomasboussekey]

❌

[Docker PostGIS CI](https://github.com/postgis/docker-postgis/actions/runs/17172851282/workflow)
Error when evaluating 'runs-on' for job 'make-docker-images'. .github/workflows/main.yml (Line: 33, Col: 14): Unexpected value ''

[thomasboussekey]

Reverting, not clever enough to understand strategy.matrix.include logic

[ImreSamu]

postgis/postgis:17-3.6.0beta1-alpine

This row was included because of the 17-3.6.0beta1 directory, but we're no longer building beta1, only rc1.
Once the 17-3.6.0beta1 directory is removed, ./update.sh will no longer generate this line in the log test markdown section.