Proposal: decouple service template publishing from the Coolify release train

[Joseph-Hussell]

Proposal: Ship Service Template Updates Independently of Coolify Releases

Nov 5, 2026 · @joseph Hussell

Summary

I'd like to propose that service template changes reach Coolify instances when they are merged, not only when a new Coolify version is released. Coolify instances already download the template catalog from the CDN every hour. The catch is that the CDN copy is only republished as part of a release. Giving templates their own publishing track would let fixes and new services ship in hours instead of waiting weeks for the next release, and it needs no change to how instances fetch them.

Suggested category: Feature Requests.

How it works today

The pieces for delivering templates live already exist. The problem is the publishing side, which runs only when Coolify is released. Here's what I found in main (commit 19762a7):

Piece	What it does	Where
Scheduled pull	Fetches service-templates-latest.json from cdn.coollabs.io on the update_check_frequency cron (hourly by default)	app/Jobs/PullTemplatesFromCDN.php, app/Console/Kernel.php
Pull on startup	Fetches the same file when the instance starts	app/Console/Commands/Init.php
Forced refresh	get_service_templates(force: true) re-fetches on demand	bootstrap/helpers/shared.php
Validation	Rejects an empty or non-object body and keeps the current catalog	store_service_templates_bundle()
CDN publishing	scripts/sync-cdn.sh uploads the template JSON together with install.sh, upgrade.sh and versions.json	Runs only from release.yaml (stable and preview) and nightly.yaml

I'd like to know whether the team is open to this direction, and whether templates were tied to releases on purpose for a reason I've missed.

Sources

All code references are coollabsio/coolify at main commit 19762a7 (Nov 5, 2026).

• app/Jobs/PullTemplatesFromCDN.php and its schedule in app/Console/Kernel.php
• app/Console/Commands/Init.php
• bootstrap/helpers/shared.php: get_service_templates(), store_service_templates_bundle()
• app/Console/Commands/Generate/Services.php
• scripts/sync-cdn.sh, .github/workflows/release.yaml, .github/workflows/nightly.yaml
• coollabsio/coollabs-cdn: commit history of json/coolify/service-templates-latest.json
• Docs: How Services work

# Proposal: Ship Service Template Updates Independently of Coolify Releases

Nov 5, 2026 · @joseph Hussell

Summary

I'd like to propose that service template changes reach Coolify instances when they are merged, not only when a new Coolify version is released. Coolify instances already download the template catalog from the CDN every hour. The catch is that the CDN copy is only republished as part of a release. Giving templates their own publishing track would let fixes and new services ship in hours instead of waiting weeks for the next release, and it needs no change to how instances fetch them.

Suggested category: Feature Requests.

How it works today

The pieces for delivering templates live already exist. The problem is the publishing side, which runs only when Coolify is released. Here's what I found in main (commit 19762a7):

Piece	What it does	Where
Scheduled pull	Fetches service-templates-latest.json from cdn.coollabs.io on the update_check_frequency cron (hourly by default)	app/Jobs/PullTemplatesFromCDN.php, app/Console/Kernel.php
Pull on startup	Fetches the same file when the instance starts	app/Console/Commands/Init.php
Forced refresh	get_service_templates(force: true) re-fetches on demand	bootstrap/helpers/shared.php
Validation	Rejects an empty or non-object body and keeps the current catalog	store_service_templates_bundle()
CDN publishing	scripts/sync-cdn.sh uploads the template JSON together with install.sh, upgrade.sh and versions.json	Runs only from release.yaml (stable and preview) and nightly.yaml

In practice, a template fix merged today stays off stable instances until the next stable release triggers sync-cdn.sh. Stable syncs also go through a PR on coollabsio/coollabs-cdn, so templates get the same review gate as the installer. The catalog and the app ship as one unit, even though the code already treats them as separate.

The numbers bear this out. Since the stable service-templates-latest.json first appeared on the CDN on July 10, 2026, it has changed 13 times, and 12 of those were release pushes. Over the same months about 120 commits touched templates/compose/ on main (57 in August alone).

Why it matters

Self-hosted software is moving faster than Coolify's release cadence, and AI tools are the main reason. New AI apps, agents, inference servers and vector databases appear every week. Popular projects often change images, environment variables or required services between minor versions.

• Broken templates stay broken longer. When an upstream image renames a variable or drops a binary used by a healthcheck, the fix is a one-line YAML change. Users still wait for a full release to get it.
• New services miss their window. People who discover a new tool want to try it now. If it shows up in the catalog weeks later, they've already deployed it some other way.
• Template fixes pile up behind core changes. A release that's held back for an unrelated core bug also holds back every template fix merged in the meantime.
• Contributors wait longer to see their work live. That slows the feedback loop that keeps the catalog healthy.

The catalog is one of Coolify's biggest strengths compared with other PaaS tools. Keeping it current is how Coolify keeps up with where self-hosting is going.

Proposal

The plan is to give templates their own release track and use the existing CDN pull to deliver them. Each phase is useful on its own, so the team can stop after any of them.

1. Publish templates separately from releases. Add a workflow that regenerates service-templates-latest.json and syncs only that file to the CDN when templates/compose/** changes on the release branch. It could run on every merge, daily, or on a manual dispatch with maintainer approval. install.sh, upgrade.sh and versions.json stay tied to releases as they are now.
2. Respect template compatibility. Templates can already declare # minversion:, and Generate/Services.php writes it into the JSON. Nothing in the app reads it yet, though, and only 2 of the 387 templates set it (posthog and supabase). The instance would hide or disable templates whose minversion is newer than the running version, showing "Requires Coolify vX.Y.Z". A template that depends on a new parser feature could then ship early without breaking older instances.
3. Version the catalog and sign it. Add a catalog version, a generation timestamp and a hash or signature, then verify them in store_service_templates_bundle() before replacing the current catalog. Today that check only confirms the body is a non-empty JSON object.
4. Make freshness visible. The template picker already shows a "last updated" time. Add a Refresh templates button that calls the existing forced refresh, and a per-template changelog line such as "updated 2026-11-04: fixed healthcheck".
5. Notify about updates to deployed services (later). A deployed service keeps the compose it started with. Store the template's hash at deploy time, then show "Template update available" with a diff the user reviews and applies. Nothing would change automatically.
6. Allow extra template sources (optional, later). Let admins add more catalog URLs, such as an internal company catalog or a community catalog, using the same signed format. Each source would be labeled clearly in the UI.

Risks and how to handle them

Risk	Mitigation
A bad template reaches every instance within an hour	Templates only affect new deployments. Gate publishing with an approval step, and keep the previous catalog so a revert republishes in minutes.
A template uses a feature older instances lack	Enforce minversion (phase 2) before switching publishing on.
Someone compromises the CDN or the pipeline	Sign the catalog and verify it on the instance (phase 3).
More review work for maintainers	Smaller, more frequent template batches are easier to review than one large batch per release. Contributor CI (lint and test deploys) can take on more of the checking.
Cloud and self-hosted catalogs drift apart	Both read the same CDN file. Cloud already shares the bundle through Redis, according to the comment in PullTemplatesFromCDN.

I'd like to know whether the team is open to this direction, and whether templates were tied to releases on purpose for a reason I've missed.

Sources

All code references are coollabsio/coolify at main commit 19762a7 (Nov 5, 2026).

• [app/Jobs/PullTemplatesFromCDN.php](https://github.com/coollabsio/coolify/blob/main/app/Jobs/PullTemplatesFromCDN.php) and its schedule in [app/Console/Kernel.php](https://github.com/coollabsio/coolify/blob/main/app/Console/Kernel.php)
• [app/Console/Commands/Init.php](https://github.com/coollabsio/coolify/blob/main/app/Console/Commands/Init.php)
• [bootstrap/helpers/shared.php](https://github.com/coollabsio/coolify/blob/main/bootstrap/helpers/shared.php): get_service_templates(), store_service_templates_bundle()
• [app/Console/Commands/Generate/Services.php](https://github.com/coollabsio/coolify/blob/main/app/Console/Commands/Generate/Services.php)
• [scripts/sync-cdn.sh](https://github.com/coollabsio/coolify/blob/main/scripts/sync-cdn.sh), [.github/workflows/release.yaml](https://github.com/coollabsio/coolify/blob/main/.github/workflows/release.yaml), [.github/workflows/nightly.yaml](https://github.com/coollabsio/coolify/blob/main/.github/workflows/nightly.yaml)
• [coollabsio/coollabs-cdn](https://github.com/coollabsio/coollabs-cdn): commit history of json/coolify/service-templates-latest.json
• [Docs: How Services work](https://coolify.io/docs/services/how-services-work)