SwarmCLI Charts

Community charts for SwarmCLI — a k9s-inspired TUI for Docker Swarm.

Available Charts

Chart	Version	App Version	Description
gitlab			GitLab CE — self-hosted Git hosting and CI/CD for Docker Swarm — omnibus all-in-one image, stateful, single-node pinned, Traefik-routed with git-over-SSH on a TCP entrypoint
keycloak			Keycloak identity & access management for Docker Swarm — DB-agnostic, secret-authenticated, Traefik-routed
mariadb			MariaDB relational database for Docker Swarm — persistent, secret-authenticated, single-node pinned
ollama			Ollama self-hosted LLM server for Docker Swarm — offline models, stateful, single-node pinned, optional GPU
openclaw			OpenClaw self-hosted personal AI assistant gateway for Docker Swarm — stateful, secret-authenticated, Traefik-routed
postgres			PostgreSQL relational database for Docker Swarm — persistent, secret-authenticated, single-node pinned
redis			Redis in-memory data store for Docker Swarm — persistent, secret-authenticated, single-node pinned
renovate			Self-hosted Renovate — opens dependency-update PRs, including for your swarmcli-release.yaml
superset			Apache Superset BI & visualization platform for Docker Swarm — external metadata DB + Redis, Celery workers, Traefik-routed
swarm-cronjob			Label-driven cron job scheduler for Docker Swarm
swarmcli-cd			SwarmCLI CD — GitOps continuous delivery for Docker Swarm, pulling from git instead of pushing from CI
traefik			Reverse proxy / ingress with Let's Encrypt TLS for Docker Swarm
vaultwarden			Vaultwarden password manager for Docker Swarm — SQLite by default or external PostgreSQL/MySQL, stateful, Traefik-routed
whoami			HTTP echo service for testing
zammad			Zammad helpdesk / ticketing for Docker Swarm — external or embedded PostgreSQL & Redis, embedded Elasticsearch, Traefik-routed via its own nginx

The Version/App Version badges read the live published index.yaml, so they track the latest release automatically — there is no number to bump by hand.

Adding the Repository

swarmcli charts repo add swarmcli-charts https://eldara-tech.github.io/swarmcli-charts
swarmcli charts repo update

You can add multiple repos and reference charts by repo prefix. install takes a release name and a <repo>/<chart> reference:

swarmcli charts install whoami swarmcli-charts/whoami

Usage

# Install a chart
swarmcli charts install whoami swarmcli-charts/whoami --set ingress.host=whoami.yourdomain.com

# Install with custom values
swarmcli charts install whoami swarmcli-charts/whoami -f my-values.yaml

# List available charts
swarmcli charts search

Keeping Charts Up to Date

Pin your releases in a file and let Renovate bump them:

# swarmcli-release.yaml
repositories:
  - name: swarmcli-charts
    url: https://eldara-tech.github.io/swarmcli-charts
releases:
  - name: edge
    chart: swarmcli-charts/traefik
    version: "0.1.1"
    values: [./traefik.yaml]
  - name: hello
    chart: swarmcli-charts/whoami
    version: "0.1.8"

swarmcli charts apply -f swarmcli-release.yaml --dry-run   # plan
swarmcli charts apply -f swarmcli-release.yaml             # converge
swarmcli charts outdated                                   # what has a newer chart?

Then extend this repository's Renovate preset — that is the whole configuration:

{ "extends": ["github>Eldara-Tech/swarmcli-charts"] }

Renovate opens a PR whenever a chart you pin gets a new version, with the chart's release notes attached. Merge it, and swarmcli charts apply in CI rolls it out.

docs/gitops.md is that CI job, worked end to end: reaching the swarm over an ssh:// context, installing the binary, a plan-on-PR / apply-on-merge workflow for GitHub Actions and GitLab CI, and the Renovate settings that are easy to get wrong.

The file's key names match Helmfile's on purpose, so Renovate's built-in helmfile manager reads it — there is no custom regex to maintain, and the chart registry is resolved from the repositories block, so the preset works for any chart repository you add, not just this one.

Running the bot yourself? To self-host Renovate on your own Swarm with the renovate chart — including pointing it at this repository — see docs/renovate-self-hosting.md.

Releasing a New Chart Version

The git tag is the source of truth for the version. The easiest way to cut one is the workflow dispatch, which derives the next version from the newest existing tag and creates the tag itself:

gh workflow run release.yml -f chart=whoami -f bump=patch   # or minor / major

Prefer it over a hand-pushed tag when releasing several charts at once: GitHub silently drops tag-push events beyond 3 tags per git push, so some charts would be tagged and never published.

Pushing a tag by hand also works:

git tag whoami/v0.2.0
git push origin whoami/v0.2.0

release.yml stamps that version into the chart's Chart.yaml at package time and publishes a GitHub Release with the .tgz; pages-index.yml then rebuilds the index.yaml on GitHub Pages. The version: field committed in Chart.yaml is only a placeholder — the tag wins.

The published chart version is plain SemVer (0.2.0); install it with --version 0.2.0 (the leading v belongs to the git tag, not the chart version).

Contributing

See CONTRIBUTING.md for the full guide. In short:

make new-chart NAME=mychart   # scaffold a passing skeleton
make test CHART=mychart       # render + validate (exactly what CI runs)
make e2e  CHART=mychart       # deploy to a local swarm + verify (see docs/e2e-testing.md)

• Each chart lives under charts/<name>/
• Required files: Chart.yaml, values.yaml, templates/stack.yaml.tmpl, README.md, and a ci/*-values.yaml fixture
• Templates use Go text/template syntax with .Values, .Chart, and .Release context
• CI renders every chart against its fixtures and validates the output — see CONTRIBUTING.md

One-Time Repo Setup (for maintainers)

The release workflow publishes index.yaml to GitHub Pages, so Pages needs to be enabled once:

1. Repo Settings → Pages → Source → set to "GitHub Actions" — the release workflow publishes the generated index via actions/upload-pages-artifact + actions/deploy-pages

That's it — contents: write is scoped only to the job that creates the GitHub Release (required by softprops/action-gh-release), and the index-publishing job only needs pages: write + id-token: write, which are job-level permissions the workflow requests itself and don't depend on the repo/org-wide "Workflow permissions" toggle. If that toggle is greyed out or locked by an org policy, this setup still works.

After the first successful release, the index will be live at:

https://<org>.github.io/swarmcli-charts/index.yaml

How the index is built

scripts/generate-index.sh rebuilds index.yaml from scratch on every chart release:

• Lists all GitHub Releases tagged <chart>/v<version>
• Reads each chart's Chart.yaml as it existed at that tag (via git show <tag>:path) for metadata
• Downloads each release's .sha256 file to embed the digest
• Outputs a Helm-style index.yaml with download URLs pointing at the release assets

The generated index.yaml is published straight to GitHub Pages (not committed back to main), so no repo-write permission is needed beyond what release creation already requires.

Run it locally to debug:

gh auth login
./scripts/generate-index.sh eldara-tech/swarmcli-charts > index.yaml