Guide: running stable open-source releases
For teams that run open-source software for their organization (a CRM, defect tracking, document signing, a wiki, monitoring, databases) and want it to keep working, safely, release after release.
Who ReadyStack is for
A good fit
- You run open-source applications for your business; you do not develop them.
- You want security fixes and new versions without a team that builds and patches images.
- Your data and settings stay with you, and you change the applications through their settings, plugins and integrations, rarely their code.
- You pin exact releases, move forward on purpose, and want to show what you run: who built it, what is inside, what changed.
- People or AI agents operate your systems and need documentation that matches the exact release.
Not a fit
- You need a vendor's paid or enterprise edition: we package open-source editions only.
- You want a
latesttag that changes under you: every ReadyStack tag names one release and never moves. - You maintain large changes to an application's code. The build kit is then a good starting point (see below), but you are maintaining your own version.
Best practice for stable releases
How release tags work- Pin the exact release, and its digest.For example
readystack/postgresql:18.6-CE-ubuntu24.04-r5. A tag names one release and never moves, and we publish nolatest. Never pull a tag that starts withinternal-. - Keep everything that is yours outside the image.Data in volumes at the paths the release's handbook names; settings in environment variables or mounted configuration files kept in version control; secrets in a file only you can read.
- Check what you run.Before you start a release, verify its signature with
cosign verify --key https://readystack.dev/keys/cosign.pub readystack/<app>@sha256:<digest>. Each release page shows the evidence that comes with it (software bill of materials, provenance) and its grade with the date it was measured. - Let new releases come to you.Our Renovate preset opens a pull request for each new revision of the version you run and for each new upstream version, and nothing else.
- Read the release notes before you move.They say what changed, which release this one replaces, its known issues, and anything you set that has to change. The admin handbook's "Moving from the upstream image" section lists the measured differences from the project's own image, such as its user, ports and data paths.
- Try the move on a copy first.Back up, restore into a test instance, start the new release on it and run the checks in its handbook, then switch production. Keep the previous tag for a rollback, and keep the backup: a new upstream version can change your data in ways an older one cannot read.
Making a change without breaking the next release
The rule of thumb: change an application through its front doors (settings, plugins, volumes, ports), not by rearranging its insides.
| When you want to | Do it this way | Why the next release still works |
|---|---|---|
| Change a setting (email, single sign-on, language, limits) | Use the environment variables and configuration files the handbook documents, mounted from outside the container. | The next release reads the same settings from the same place. |
| Add plugins, themes or extensions | Use the application's own plugin mechanism, stored in its data volume. Or build a small image of your own, FROM readystack/<app>:<release tag>, that adds only your files. | Nothing of ours is edited: your layer is rebuilt on top of each new release. |
| Connect it to your proxy, backups, monitoring or identity provider | Work around the container: its published ports, networks and volumes. | Each handbook lists the ports, data paths and user of its release: compare them before you move. |
| Trust your company's certificate authority, or add fonts or languages | Mount them, or add them in your own small image built from our release. | The same as plugins: your addition sits on top. |
| Change the application's code | Contribute the change to the project first. If you need it now, start from the build kit of the exact release, keep your patch small, and sign the result with your own key. | Our recipe changes only with a release. Your patch is a small change you apply again to each new release's kit. |
Avoid
- Editing files inside a running container: the next release replaces them.
- Depending on paths, users or files the handbook does not name.
- Copying an image and maintaining it by hand: you take on every future fix yourself.
- Pinning a release and never moving on: you stop receiving security fixes.
How ReadyStack compares
Checked 2026-11-07 on each provider's own pages; sources belowFive ways to get the same open-source software running. Each suits someone; what differs is who does the work, what you can pin, and what comes with the software.
| Pin an exact version, free | Security fixes | Promised fix time | Docs, test data, offline rebuild | Base OS and CPUs | |
|---|---|---|---|---|---|
| Build from the project's GitHub source | Yes, any version | You watch for fixes, rebuild and redeploy yourself | Yours to set | The project's own docs; test data and a repeatable offline build are yours to make | Your choice |
| Images from unknown publishers on Docker Hub | Whatever the publisher tags | Up to the publisher; Docker states no guarantee outside its badge programs | None | Up to the publisher | Varies |
| Chainguard | No: the free images carry only latest and latest-dev; version tags need a paid plan (Catalog Starter: any five images) | Rebuilt nightly | Paid plans: 7 days for critical, 14 days for the rest; none on the free images or Catalog Starter | Signed SBOM and SLSA provenance on every image; we found no test data or offline rebuild kit offered | Chainguard OS; x86-64 and Arm |
| Bitnami | No: since 28 August 2025 the free Docker Hub images carry only latest, for development use; earlier version tags moved to bitnamilegacy, which gets no updates | On latest; supported versions through Bitnami Secure Images (sales) | None stated for the free images | Dockerfiles are public, but a rebuild downloads prebuilt binaries, so it needs the network | Photon OS; x86-64 and Arm |
| ReadyStack | Yes: every release tag, and a tag never moves | Each release ships with every available critical and high fix; re-scanned daily and rebuilt when it falls below grade A | None published yet: we measure and publish the time to each fixed release | Handbooks checked against the exact image, seed data and tests; a free build kit (with an account) rebuilds each release offline, bit-for-bit | Ubuntu 24.04 for most products; x86-64 only |
Sources: Chainguard container categories, Catalog Starter, pricing, overview; Bitnami catalog change notice and the bitnami and bitnamilegacy repositories on Docker Hub; Docker trusted content; NIST SP 800-190 on rebuilding images to apply fixes. Read on 2026-11-07; providers change their offers, so check their pages before you decide. Product names belong to their owners.
How ReadyStack is governed
AboutReadyStack is governed by the ReadyStack Software Organization. Its goal is to use AI as fully as possible to make software as safe and as free as possible.