channels.yaml

# Distribution channel inventory (the "visibility matrix").
#
# One entry per place users can obtain LibreDB Studio. Human-maintained:
# scripts/distribution-check.mjs READS this file and reports drift against
# package.json - it never writes version numbers into it. Schema, tier and
# SLA definitions, and maintenance rules (including when to update
# last_bump_pr) live in docs/DISTRIBUTION.md ("Channel inventory and drift
# check").
#
# Field summary:
#   id/name/status/tier       identity; status: live | pending | deprecated
#   kind                      the technical shape of the artefact (what it
#                             literally is), independent of category (the audience-facing
#                             bucket several kinds can share): one of release-assets |
#                             container-image | package-registry | helm-chart |
#                             package-manager | os-package | one-click-template |
#                             paas-template | deploy-button | operator-catalog |
#                             partner-catalog | curated-catalog | marketplace
#   category                  business bucket for docs/CHANNELS.md:
#                             registries-releases | containers | kubernetes-operators |
#                             package-managers | os-desktop | paas-catalogs |
#                             deploy-recipes | cloud-marketplaces
#   platforms                 REQUIRED, non-empty list. Rendered and counted in
#                             this canonical order in docs/CHANNELS.md:
#                             linux | macos | windows | container | kubernetes | cloud
#   runtime                   REQUIRED. Who provides the Node.js the server runs
#                             on, which is what decides whether raising
#                             `engines.node` is a breaking change for this
#                             channel's users (issue #326):
#                             user_supplied    - the user's own `node` executes
#                               the payload, so the floor is theirs to meet.
#                             channel_supplied - the channel provides it:
#                               bundled in the artefact (image, snap, deb/rpm,
#                               Windows zip, Flatpak, Tauri sidecar), inherited
#                               from an image a template deploys, or installed as
#                               a declared dependency (Homebrew node@24).
#                             Not derivable from `kind`: deb/rpm are os-package
#                             and bundle a private Node, npm is package-registry
#                             and does not.
#   short_name                optional; the display name docs/CHANNELS.md uses when
#                             `name` is too long to scan. Falls back to `name`.
#   update.method             ci_publish | commit | upstream_pr | manual_ui
#   update.sla                every_release | minor_plus | major_only | on_demand
#   update.ci_enabled         REQUIRED on, and allowed ONLY on, the switchable
#                             channels (docker-hub-mirror, homebrew, snap,
#                             winget, chocolatey): may release CI publish this
#                             channel? The release workflow reads it, so turning
#                             a channel off here is the whole switch - no secret
#                             to delete, no workflow edit. The core release path
#                             (github-release, docker-ghcr, npm, helm) and the
#                             required release assets have no flag on purpose.
#   links                     tracking_issue / first_pr / last_bump_pr (nullable
#                             until the first post-listing bump) / catalog /
#                             upstream_repo / docs / get (user-facing "where do I
#                             get it"; docs/CHANNELS.md resolves it as
#                             get > catalog > upstream_repo, except a deprecated
#                             channel renders no link at all, whatever these
#                             fields hold)
#   pin.strategy              local_file | remote_file | probe | none
#   pin.probe                 required when strategy == probe; one of the probe ids
#                             defined in scripts/distribution-check.mjs
#   pin.urls                  required when strategy == probe; URL template(s) the
#                             probe uses (see the probe's requiredUrls)
#   pin.architectures         required for the snap-store-channel probe; list of
#                             architectures to measure independently
#   pin.extract               regex with ONE capture group; required for
#                             local_file / remote_file; all matches in a source
#                             must agree (ambiguity is reported, never resolved
#                             to the first hit)

channels:
  # ---- Tier 0: core registries, published directly by release CI ----------

  - id: github-release
    name: GitHub Releases (standalone tarballs, deb/rpm, snap assets)
    short_name: GitHub Releases
    status: live
    category: registries-releases
    platforms: [linux, macos, windows]
    runtime: user_supplied
    tier: 0
    kind: release-assets
    update:
      method: ci_publish
      sla: every_release
    links:
      catalog: https://github.com/libredb/libredb-studio/releases
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: remote_file
      url: https://api.github.com/repos/libredb/libredb-studio/releases/latest
      extract: '"tag_name":\s*"(\d+\.\d+\.\d+)"'
      note: Probes the latest-release API; confirms the draft-first publish actually landed.

  - id: docker-ghcr
    name: Docker image (GHCR, canonical)
    short_name: Docker image (GHCR)
    status: live
    category: containers
    platforms: [container]
    runtime: channel_supplied
    tier: 0
    kind: container-image
    update:
      method: ci_publish
      sla: every_release
    links:
      catalog: https://github.com/libredb/libredb-studio/pkgs/container/libredb-studio
    pin:
      strategy: probe
      probe: ghcr-tag-digest
      urls:
        token: https://ghcr.io/token?service=ghcr.io&scope=repository:libredb/libredb-studio:pull
        manifest: https://ghcr.io/v2/libredb/libredb-studio/manifests/{ref}
      note: Compares the image :latest resolves to against the released version tag. Anonymous pull token,
        no secret, so the probe also works from a fork.

  - id: docker-hub-mirror
    name: Docker Hub mirror (discoverability only)
    short_name: Docker Hub mirror
    status: live
    category: containers
    platforms: [container]
    runtime: channel_supplied
    tier: 0
    kind: container-image
    update:
      method: ci_publish
      sla: every_release
      ci_enabled: true
    links:
      catalog: https://hub.docker.com/r/libredb/libredb-studio
    pin:
      strategy: probe
      probe: dockerhub-tag-digest
      urls:
        tag: https://hub.docker.com/v2/repositories/libredb/libredb-studio/tags/{ref}
      note: Mirror of GHCR; immutable-tag rules must stay semver-only. The push is secret-gated and skips
        silently, so an absent version tag here is how an expired DOCKER_HUB_TOKEN becomes visible.

  - id: npm
    name: npm package @libredb/studio (library + npx launcher)
    short_name: npm @libredb/studio
    status: live
    category: registries-releases
    platforms: [linux, macos, windows]
    runtime: user_supplied
    tier: 0
    kind: package-registry
    update:
      method: ci_publish
      sla: every_release
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/110
      first_pr: https://github.com/libredb/libredb-studio/pull/122
      catalog: https://www.npmjs.com/package/@libredb/studio
    pin:
      strategy: remote_file
      url: https://registry.npmjs.org/-/package/@libredb/studio/dist-tags
      extract: '"latest":\s*"(\d+\.\d+\.\d+)"'
      note: Probes the npm dist-tags endpoint; confirms npm-publish.yml actually landed.

  # ---- Tier 1: packaged formats owned by this repo, CI-published ----------

  - id: helm
    name: Helm chart (libredb.org repo + GHCR OCI + ArtifactHub)
    short_name: Helm chart
    status: live
    category: kubernetes-operators
    platforms: [kubernetes]
    runtime: channel_supplied
    tier: 1
    kind: helm-chart
    update:
      method: ci_publish
      sla: every_release
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/138
      first_pr: https://github.com/libredb/libredb-studio/pull/44
      catalog: https://artifacthub.io/packages/helm/libredb-studio/libredb-studio
      docs: docs/HELM_CHART.md
    pin:
      strategy: local_file
      files:
        - charts/libredb-studio/Chart.yaml
      extract: 'appVersion: "(\d+\.\d+\.\d+)"'
      note: Enforcement lives in the required chart:check CI gate (#138); this row is visibility.

  - id: homebrew
    name: Homebrew tap (libredb/tap/libredb-studio)
    short_name: Homebrew tap
    status: live
    category: package-managers
    platforms: [macos, linux]
    runtime: channel_supplied
    tier: 1
    kind: package-manager
    update:
      method: ci_publish
      sla: every_release
      ci_enabled: true
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/111
      first_pr: https://github.com/libredb/libredb-studio/pull/122
      upstream_repo: https://github.com/libredb/homebrew-tap
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/libredb/homebrew-tap/main/Formula/libredb-studio.rb
      extract: 'version "(\d+\.\d+\.\d+)"'
      note: Confirms the release-CI tap push actually landed.

  - id: snap
    name: Snap Store (stable channel, amd64+arm64)
    short_name: Snap Store
    status: live
    category: package-managers
    platforms: [linux]
    runtime: channel_supplied
    tier: 1
    kind: package-manager
    update:
      method: ci_publish
      sla: every_release
      ci_enabled: true
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/113
      first_pr: https://github.com/libredb/libredb-studio/pull/177
      catalog: https://snapcraft.io/libredb-studio
    pin:
      strategy: probe
      probe: snap-store-channel
      architectures:
        - amd64
        - arm64
      urls:
        info: https://api.snapcraft.io/v2/snaps/info/libredb-studio
      note: Reads the stable channel of each architecture separately, so one lagging build is drift rather
        than a pass. Edge may legitimately differ from stable and is ignored.

  - id: linux-deb-rpm
    name: Linux .deb / .rpm packages (release assets)
    short_name: Linux .deb / .rpm
    status: live
    category: os-desktop
    platforms: [linux]
    runtime: channel_supplied
    tier: 1
    kind: os-package
    update:
      method: ci_publish
      sla: every_release
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/112
      first_pr: https://github.com/libredb/libredb-studio/pull/122
      get: https://github.com/libredb/libredb-studio/releases/latest
    pin:
      strategy: none
      note: Built by nfpm from the tag in release-artifacts.yml; nothing to drift.

  - id: appimage
    # Quoted: an unquoted scalar containing ": " is a YAML mapping, not a string.
    name: "Desktop app (release assets: AppImage and GUI .deb, x64 + arm64)"
    short_name: Desktop app (AppImage, .deb)
    status: live
    category: os-desktop
    platforms: [linux]
    runtime: channel_supplied
    tier: 1
    kind: release-assets
    update:
      method: ci_publish
      sla: every_release
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/232
      first_pr: https://github.com/libredb/libredb-studio/pull/235
      get: https://github.com/libredb/libredb-studio/releases/latest
      docs: desktop/README.md
    pin:
      strategy: none
      note: Both artifacts come per arch out of the one desktop-appimage job and are required by
        publish-release, so they cannot drift from the tag - hence no pin. The AppImage has shipped
        since 0.9.60 and the GUI .deb since 0.9.62. The AppImage is also what the in-repo Flatpak
        manifest repacks in flatpak-smoke.yml (packaging/flatpak, dormant - see the flathub
        channel); the GUI .deb (libredb-studio-desktop_<version>_<arch>.deb, distinct from the
        headless server package) is what FlatPark pins as extra-data.

  # ---- Tier 2: LibreDB-owned copies and listings, bumped by hand ----------

  - id: railway-template
    name: Railway one-click template
    status: live
    category: paas-catalogs
    platforms: [cloud]
    runtime: channel_supplied
    tier: 2
    kind: paas-template
    update:
      method: manual_ui
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/174
      first_pr: https://github.com/libredb/libredb-studio/pull/67
      catalog: https://railway.com/deploy/libredb-studio
      docs: deploy/railway/PUBLISH.md
    pin:
      strategy: local_file
      files:
        - deploy/railway/template.json
        - deploy/railway/README.md
        - deploy/railway/PUBLISH.md
      extract: 'libredb-studio:(\d+\.\d+\.\d+)'
      note: The published template is edited in the Railway dashboard; these three files must move together.

  - id: koyeb-deploy-button
    name: Koyeb deploy button (repo README)
    short_name: Koyeb deploy button
    status: live
    category: deploy-recipes
    platforms: [cloud]
    runtime: channel_supplied
    tier: 2
    kind: deploy-button
    update:
      method: commit
      sla: on_demand
    links:
      get: https://github.com/libredb/libredb-studio/tree/main/deploy/koyeb
      docs: deploy/koyeb/README.md
    pin:
      strategy: none
      note: The button deploys ghcr.io latest by design; there is no version pin.

  - id: fly-io
    name: Fly.io launch config (repo fly.toml)
    short_name: Fly.io launch config
    status: live
    category: deploy-recipes
    platforms: [cloud]
    runtime: channel_supplied
    tier: 2
    kind: paas-template
    update:
      method: commit
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/218
      first_pr: https://github.com/libredb/libredb-studio/pull/219
      get: https://github.com/libredb/libredb-studio/blob/main/fly.toml
      docs: docs/FLY.md
    pin:
      strategy: local_file
      files:
        - fly.toml
      extract: 'libredb-studio:(\d+\.\d+\.\d+)'
      note: Users deploy straight from the repo file; bump the tag here on release when convenient.

  - id: render
    name: Render Blueprint (repo render.yaml)
    short_name: Render Blueprint
    status: live
    category: deploy-recipes
    platforms: [cloud]
    runtime: channel_supplied
    tier: 2
    kind: paas-template
    update:
      method: commit
      sla: on_demand
    links:
      get: https://github.com/libredb/libredb-studio/blob/main/render.yaml
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: none
      note: Render builds from the repo Dockerfile (render.yaml dockerfilePath) on push, so there is no image tag to pin - the deployed version tracks whatever main builds. Like fly.toml, render.yaml is auto-detected at the repo root, so users deploy straight from the repo Blueprint.

  - id: unraid-ca
    name: Unraid Community Applications (libredb/unraid-templates)
    short_name: Unraid Community Apps
    status: live
    category: paas-catalogs
    platforms: [container]
    runtime: channel_supplied
    tier: 2
    kind: one-click-template
    update:
      method: commit
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/283
      catalog: https://ca.unraid.net/apps/libredb-studio-0a5x41a1cy1kay
      upstream_repo: https://github.com/libredb/unraid-templates
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/libredb/unraid-templates/main/templates/libredb-studio.xml
      extract: 'libredb-studio:(\d+\.\d+\.\d+)'
      note: The container template is LibreDB-owned (libredb/unraid-templates), so a version bump is a commit
        in THAT repo - not a PR here and not an upstream PR - which is why this is tier 2 with a remote_file
        pin rather than local_file. Community Applications only serves what its own periodic catalog build
        picked up, so a bump reaches users one CA build after the commit. Submitted via ca.unraid.net/submit
        on 2026-08-04 and auto-approved (a non-duplicate Docker app with no plugin needs no human review).
        The `container` platform is deliberate and not a stand-in for cloud - the user installs a Docker
        container on their own Unraid server.

  # ---- Tier 3: upstream community catalogs, bumped via PR -----------------

  - id: caprover-official
    name: CapRover official one-click apps
    short_name: CapRover official
    status: live
    category: paas-catalogs
    platforms: [cloud]
    runtime: channel_supplied
    tier: 3
    kind: one-click-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/56
      first_pr: https://github.com/caprover/one-click-apps/pull/1303
      upstream_repo: https://github.com/caprover/one-click-apps
      docs: deploy/caprover/README.md
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/caprover/one-click-apps/master/public/v4/apps/libredb-studio.yml
      extract: "defaultValue: '(\\d+\\.\\d+\\.\\d+)'"
      note: The single CapRover row. A LibreDB-owned 3rd-party repo
        (libredb/caprover-one-click-apps) served the app while this submission was in review and was
        retired once it merged; it had its own inventory entry until that duplicated CapRover in the
        coverage matrix as one live and one dead route to the same platform, with the dead one's URL
        no longer published. Its record lives in deploy/caprover/README.md, which is where a
        maintainer bumping the template already looks. Users install from the official catalog only -
        no third-party repo to add.

  - id: dokploy
    name: Dokploy template catalog
    status: live
    category: paas-catalogs
    platforms: [cloud]
    runtime: channel_supplied
    tier: 3
    kind: paas-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/171
      first_pr: https://github.com/Dokploy/templates/pull/931
      catalog: https://templates.dokploy.com
      upstream_repo: https://github.com/Dokploy/templates
      docs: deploy/dokploy/README.md
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/Dokploy/templates/main/blueprints/libredb-studio/docker-compose.yml
      extract: 'libredb-studio:(\d+\.\d+\.\d+)'
      note: Bump from 0.9.27 to the current release is tracked in issue 175.

  - id: cosmos
    name: Cosmos servapp marketplace
    status: live
    category: paas-catalogs
    platforms: [cloud]
    runtime: channel_supplied
    tier: 3
    kind: one-click-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/172
      first_pr: https://github.com/azukaar/cosmos-servapps-official/pull/218
      upstream_repo: https://github.com/azukaar/cosmos-servapps-official
      docs: deploy/cosmos/README.md
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/azukaar/cosmos-servapps-official/master/servapps/LibreDB-Studio/cosmos-compose.json
      extract: 'libredb-studio:(\d+\.\d+\.\d+)'

  - id: kubero
    name: Kubero template catalog
    status: live
    category: paas-catalogs
    platforms: [cloud]
    runtime: channel_supplied
    tier: 3
    kind: paas-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/173
      first_pr: https://github.com/kubero-dev/kubero/pull/754
      catalog: https://www.kubero.dev/templates
      upstream_repo: https://github.com/kubero-dev/kubero
      docs: deploy/kubero/README.md
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/kubero-dev/kubero/main/services/libredb-studio/app.yaml
      extract: 'ghcr\.io/libredb/libredb-studio\s+tag:\s*(\d+\.\d+\.\d+)'

  - id: sealos
    name: Sealos App Store template
    status: live
    category: paas-catalogs
    platforms: [cloud]
    runtime: channel_supplied
    tier: 3
    kind: one-click-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/276
      first_pr: https://github.com/labring-actions/templates/pull/739
      catalog: https://sealos.io/products/app-store/libredb-studio
      upstream_repo: https://github.com/labring-actions/templates
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/labring-actions/templates/kb-0.9/template/libredb-studio/index.yaml
      extract: 'libredb-studio:(\d+\.\d+\.\d+)'
      note: Sealos app-store templates live in labring-actions/templates (labring is the company behind
        Sealos) and go in as a direct template PR - no upstream issue first. That repo's default branch is
        `kb-0.9`, NOT main or master, so both the pin URL above and any bump PR must target it; a
        raw.githubusercontent URL on `main` 404s, and `master` carries a copy that can lag. The template
        pins the image in TWO places - the StatefulSet's `originImageName` annotation and the container
        `image` - so the shared all-matches-must-agree rule is what catches a half-finished bump here.
        Deploys SQLite on a 1 GiB PVC by default, with KubeBlocks-managed PostgreSQL as an opt-in
        storage backend, and ships AUTH_BOOTSTRAP=off so the deployment starts in strict mode.

  - id: truenas-scale
    name: TrueNAS SCALE community apps catalog
    short_name: TrueNAS SCALE apps
    status: live
    category: paas-catalogs
    platforms: [container]
    runtime: channel_supplied
    tier: 3
    kind: one-click-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/278
      first_pr: https://github.com/truenas/apps/pull/5501
      catalog: https://apps.truenas.com/catalog/libredb-studio_community/
      upstream_repo: https://github.com/truenas/apps
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: remote_file
      url: https://raw.githubusercontent.com/truenas/apps/master/ix-dev/community/libredb-studio/ix_values.yaml
      extract: 'ghcr\.io/libredb/libredb-studio\s+tag:\s*(\d+\.\d+\.\d+)'
      note: Merged in truenas/apps#5501 (14 Aug 2026); live in the TrueNAS SCALE community catalog. The pin
        reads the ghcr repo and tag in ix-dev/community/libredb-studio/ix_values.yaml (the maintainer-edited
        source a bump PR touches) - the container_utils_image tag is a different repository and must not be
        matched. The built catalog also renders under trains/community/libredb-studio/<version>/. The user
        installs on their own TrueNAS box, so the platform is container, not cloud.

  - id: casaos
    name: CasaOS App Store
    status: pending
    category: paas-catalogs
    platforms: [container]
    runtime: channel_supplied
    tier: 3
    kind: one-click-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/277
      first_pr: https://github.com/IceWhaleTech/CasaOS-AppStore/pull/992
      upstream_repo: https://github.com/IceWhaleTech/CasaOS-AppStore
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: none
      note: PR IceWhaleTech/CasaOS-AppStore#992 is open, so nothing is listed yet. On merge, flip to live
        and add a remote_file pin on
        https://raw.githubusercontent.com/IceWhaleTech/CasaOS-AppStore/main/Apps/LibreDBStudio/docker-compose.yml
        with extract 'libredb-studio:(\d+\.\d+\.\d+)'. Installs a Docker container on the user's own device,
        so the platform is container.

  - id: umbrel
    name: Umbrel App Store
    status: pending
    category: paas-catalogs
    platforms: [container]
    runtime: channel_supplied
    tier: 3
    kind: one-click-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/214
      first_pr: https://github.com/getumbrel/umbrel-apps/pull/5847
      upstream_repo: https://github.com/getumbrel/umbrel-apps
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: none
      note: PR getumbrel/umbrel-apps#5847 is open, so nothing is listed yet. On merge, flip to live and add
        a remote_file pin on
        https://raw.githubusercontent.com/getumbrel/umbrel-apps/master/libredb-studio/docker-compose.yml
        with extract 'libredb-studio:(\d+\.\d+\.\d+)' - the image is digest-pinned (tag@sha256) and the
        regex captures the semver and stops before the @. umbrelOS installs on the user's own device, so
        the platform is container.

  - id: easypanel
    name: Easypanel template catalog
    status: pending
    category: paas-catalogs
    platforms: [cloud]
    runtime: channel_supplied
    tier: 3
    kind: paas-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/212
      first_pr: https://github.com/easypanel-io/templates/pull/1446
      catalog: https://easypanel.io/templates
      upstream_repo: https://github.com/easypanel-io/templates
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: none
      note: PR easypanel-io/templates#1446 is open, so nothing is listed yet. On merge, flip to live and add
        a remote_file pin on
        https://raw.githubusercontent.com/easypanel-io/templates/main/templates/libredb-studio/meta.yaml
        with extract 'libredb-studio:(\d+\.\d+\.\d+)' - the version lives in meta.yaml's
        appServiceImage.default, not index.ts (which parameterises the image). Same PaaS-template shape as
        dokploy, so the platform is cloud.

  - id: portainer
    name: Portainer app templates
    status: pending
    category: paas-catalogs
    platforms: [container]
    runtime: channel_supplied
    tier: 3
    kind: one-click-template
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/213
      first_pr: https://github.com/portainer/templates/pull/262
      upstream_repo: https://github.com/portainer/templates
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: none
      note: PR portainer/templates#262 is open against the v3 branch (Portainer's current template format,
        NOT master), so nothing is listed yet. On merge, flip to live and add a remote_file pin on
        https://raw.githubusercontent.com/portainer/templates/v3/templates.json with extract
        'libredb-studio:(\d+\.\d+\.\d+)'; both the pin URL and any bump PR must target v3. Deploys a
        container to the user's Docker host, so the platform is container.

  - id: operatorhub-community
    name: OperatorHub / OpenShift community operator catalogs
    short_name: OperatorHub / OpenShift
    status: pending
    category: kubernetes-operators
    platforms: [kubernetes]
    runtime: channel_supplied
    tier: 3
    kind: operator-catalog
    update:
      method: upstream_pr
      sla: every_release
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/152
      first_pr: https://github.com/redhat-openshift-ecosystem/community-operators-prod/pull/10497
      upstream_repo: https://github.com/redhat-openshift-ecosystem/community-operators-prod
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: local_file
      files:
        - operator/bundle/manifests/libredb-studio-operator.clusterserviceversion.yaml
      extract: 'libredb-studio-operator:(\d+\.\d+\.\d+)'
      note: The OpenShift console catalog is live at 0.9.59 (community-operators-prod#10497 merged 2026-07-27, FBC catalogs in community-operators-prod#10581); the OperatorHub.io listing (k8s-operatorhub/community-operators#8794) is still in review, so this channel stays pending until both are listed. Catalog submissions (k8s-operatorhub + community-operators-prod) start after the operator PR lands; the committed bundle is the source for both, with community-operators-prod contributed in FBC mode (fbc.enabled plus per-OCP-version catalog_mapping in ci.yaml). FBC releases in two upstream PRs - bundle first, then the rendered catalogs - and that second PR is only bot-created when the bundle directory ships a release-config.yaml, so every release must include one.

  # ---- Tier 4: partner and curated catalogs (not self-serve) --------------

  - id: rancher-partner
    name: Rancher Partner Charts
    status: live
    category: kubernetes-operators
    platforms: [kubernetes]
    runtime: channel_supplied
    tier: 4
    kind: partner-catalog
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/166
      first_pr: https://github.com/rancher/partner-charts/pull/1158
      catalog: https://www.suse.com/pcsc/viewVersionPage?versionID=26969
      upstream_repo: https://github.com/rancher/partner-charts
    pin:
      strategy: none
      note: Merged in rancher/partner-charts#1158 (17 Aug 2026); live in Rancher Partner Charts (the repo
        index.yaml carries libredb-studio at appVersion 0.12.0) and listed in the SUSE Solutions Catalog.
        Partner catalog, not self-serve - the chart is regenerated on Rancher's cadence and index.yaml
        accumulates every chart version, so an image-tag extract there would be ambiguous; strategy stays
        none like the other tier-4 partner/curated catalogs.

  - id: koyeb-catalog
    name: Koyeb One-Click Apps catalog (curated by Koyeb)
    short_name: Koyeb One-Click Apps catalog
    status: pending
    category: cloud-marketplaces
    platforms: [cloud]
    runtime: channel_supplied
    tier: 4
    kind: curated-catalog
    update:
      method: manual_ui
      sla: on_demand
    links:
      catalog: https://www.koyeb.com/deploy
      docs: deploy/koyeb/CATALOG_SUBMISSION.md
    pin:
      strategy: none

  - id: digitalocean
    name: DigitalOcean Marketplace
    status: live
    category: cloud-marketplaces
    platforms: [cloud]
    runtime: channel_supplied
    tier: 4
    kind: marketplace
    update:
      method: manual_ui
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/72
      first_pr: https://github.com/libredb/libredb-studio/pull/210
      catalog: https://marketplace.digitalocean.com/apps/libredb-studio
      docs: deploy/digitalocean/README.md
    pin:
      strategy: none

  - id: winget
    name: winget community repository (LibreDB.Studio)
    short_name: winget
    status: live
    category: package-managers
    platforms: [windows]
    runtime: channel_supplied
    tier: 4
    kind: package-manager
    update:
      method: ci_publish
      sla: every_release
      # The first listing merged 2026-07-31, so wingetcreate update now has a
      # manifest to carry forward and every release submits an update PR.
      ci_enabled: true
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/114
      first_pr: https://github.com/microsoft/winget-pkgs/pull/402985
      catalog: https://github.com/microsoft/winget-pkgs/tree/master/manifests/l/LibreDB/Studio
      upstream_repo: https://github.com/microsoft/winget-pkgs
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: probe
      probe: winget-max-version
      urls:
        versions: https://api.github.com/repos/microsoft/winget-pkgs/contents/manifests/l/LibreDB/Studio
      note: Listed since 0.9.59 (winget install LibreDB.Studio). winget publishes no floating "latest"
        document - the contents listing enumerates every published version - so the highest version it
        enumerates is the served state. A regex pin cannot express that (all matches in a source must
        agree), which is why this is a probe. The release job's own pre-check (package listed / version
        already merged / update PR already open) remains the publish-time guard.

  - id: chocolatey
    name: Chocolatey community repository (libredb-studio)
    short_name: Chocolatey
    status: pending
    category: package-managers
    platforms: [windows]
    runtime: channel_supplied
    tier: 4
    kind: package-manager
    update:
      method: ci_publish
      sla: every_release
      # push.chocolatey.org answers 403 for EVERY version while an account's
      # first submission is unapproved, which failed the 0.9.60 and 0.9.61
      # release runs after the releases themselves had published fine.
      ci_enabled: false
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/114
      catalog: https://community.chocolatey.org/packages/libredb-studio
      docs: docs/DISTRIBUTION.md
    pin:
      strategy: none
      note: win32 zip ships in every release since 0.9.59. CI packs and pushes via the choco
        container (CHOCO_API_KEY gate) once ci_enabled is flipped; the first push (0.9.59) is in
        human moderation. When approved, set ci_enabled true, flip to live, add a community-API pin.

  - id: flathub
    name: Flathub community catalog (org.libredb.Studio)
    short_name: Flathub
    status: deprecated
    category: package-managers
    platforms: [linux]
    runtime: channel_supplied
    tier: 4
    kind: package-manager
    update:
      method: upstream_pr
      sla: on_demand
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/232
      upstream_repo: https://github.com/flathub/flathub
      first_pr: https://github.com/flathub/flathub/pull/9538
      docs: packaging/flatpak/README.md
    pin:
      strategy: none
      note: Not shipped, and not being pursued. The submission (flathub/flathub#9538) was declined
        on 2026-07-30 under Flathub's generative AI policy - the reviewer's position was that
        developing with an AI assistant disqualifies the app, and the PR carries their AI Slop
        label. We closed it ourselves rather than argue the point; the closing comment, which
        leaves the verifiable maintenance record on the thread, is at
        https://github.com/flathub/flathub/pull/9538#issuecomment-5136879185. Linux desktop users
        get the same app id from the flatpark channel, which is live - route every Flatpak
        instruction there. packaging/flatpak stays in the tree because the manifest still renders
        and flatpak-smoke.yml still builds it, but a resubmission would additionally have to be
        built from source (the AppImage repack is a second, independent blocker), so treat this as
        dormant rather than as work in progress.

  - id: flatpark
    name: FlatPark signed Flatpak remote (org.libredb.Studio)
    short_name: FlatPark (Flatpak)
    status: live
    category: package-managers
    platforms: [linux]
    runtime: channel_supplied
    tier: 4
    kind: package-manager
    update:
      method: upstream_pr
      sla: every_release
    links:
      tracking_issue: https://github.com/libredb/libredb-studio/issues/241
      upstream_repo: https://github.com/flatpark/flatpark
      first_pr: https://github.com/flatpark/flatpark/pull/158
      catalog: https://flatpark.org/
      docs: packaging/flatpark/README.md
    pin:
      strategy: none
      note: Repackages the GUI .deb as Flatpak extra-data - the artifact is fetched on the user's
        machine at install time, not built by FlatPark, and AppImages are not accepted there. The
        descriptor set is staged in packaging/flatpark and copied into a flatpark/flatpark fork as
        registry/org.libredb.Studio. Live since 0.9.62 (flatpark/flatpark#158 merged 2026-07-30),
        carrying the developer-approved flag - LibreDB packages its own app. FlatPark's bot now
        re-pins every release from resolve-update.sh, so the staged copy drifts by design and must
        stay out of release gates; a released version reaching the catalog is their CI's job, not
        ours, which is why there is no pin here. Sequencing question settled 2026-07-30 - FlatPark
        asks that an app not already be on Flathub, and the Flathub submission was declined, so
        this is now the only Flatpak channel and there is nothing to revisit.