TrueCharts: the README has no install command, two Discord invites, and no release since 2025

The README contains no install command

This is the first thing to know, and it is unusual. There is no command anywhere in the file for adding a chart repository, and no chart repository address either.

The Getting started section is a single link to the project site. The support section links a FAQ, a manual and an issue tracker, all on the same site. The section about creating charts points at a different domain again. The first badge in the header points at the project site too.

So there are two domains in play, and the repository's own homepage metadata names the second one while the content of the README points at the first. Anyone who lands on the repository page and looks for the manual in the README finds a link to a domain that is not the one they arrived from.

The repository description carries the same confusion in a smaller way. It contains what looks like leftover front matter, a title line followed by a bolded phrase and then the same sentence again, which is what happens when a site's metadata block is pasted into a description field and not cleaned up.

None of this stops the charts from working. It does mean the repository is an index rather than a manual, and the first-time install experience lives somewhere the repository does not point to consistently.

Two Discord invites, a channel link and a malformed address

The contact section is where the small defects cluster.

The badge at the top of the README links one Discord invite. The contact section further down links a different one. Both are invite codes, so they cannot both be the same server, and a reader who tries the top badge and then wants to open a support ticket is being sent to two places.

The support ticket option is not an invite at all but a direct channel link built from two long numeric identifiers. That form only resolves for someone already inside the server, so for anyone arriving from the repository page it is a dead end.

The email link is written with a scheme prefix and a double slash, which is not the form mail clients expect, so it is likely to be treated as an unknown protocol rather than an address.

There are four contact channels listed in total, which is generous, and the support section also points at the FAQ, the manual and the issue tracker with the note that there is a significant chance your question has already been reported. That last framing is a reasonable expectation for a catalog with this many users, and it is also a signal about where the answers actually live: in the tracker and on the site, not in the repository.

No tagged release since September 2025, while commits continue

The release history is the clearest signal of the project's state, and it has two oddities.

The first is naming. The three newest tags are not called TrueCharts. They are named after a different tool: a 2.0.6 from 2025-09-07, a 2.0.0 from 2025-04-10, and a 2.0.0 beta published the same April day a few hours before the release itself. So the release pipeline in this repository produces artefacts under another product's name, which is exactly what a chart repository forked or renamed from another project looks like from the outside.

The second is timing. The newest tag is from September 2025, and the default branch was last pushed on 2026-09-22. So the tree has moved substantially since the last release, and nothing chart-shaped has been tagged in about a year.

For a chart catalog, that gap has a specific meaning. Users installing from the repository get whatever the repository points at, which in practice is a set of chart versions bumped by the release tool rather than by a project release. The project version numbers matter less than the per-chart versions, which means the tag history is the wrong thing to watch and the commit log is the right one.

That is a defensible arrangement for a catalog with independently maintained charts, and it is also why the development model matters more here than in most repositories.

No central roadmap means no cross-chart version policy

The development section states the model directly: the process is fully distributed and agile, every chart maintainer is free to set their own roadmap and development speed, and nobody has to comply with a central roadmap.

The justification given is that this ensures freedom and flexibility, and makes sure the end user always has the latest version of every chart installed.

For a catalog whose stated goal is that all charts work together, that model has a cost. A central roadmap is usually where coordinated bumps happen, where breaking changes are agreed across charts, and where a dependency between two charts is tracked. Without one, each chart moves when its maintainer has time, which is exactly the situation in which a chart starts requiring a newer base application version than the rest of the catalog assumes.

The README does offer the other half of the contract, which is that the charts are supposed to work together and are easy to set up with any Helm-compatible deployment tool, and that there are enough options to tune things to your liking. That is the user's side of the bargain: the catalog provides breadth and options, and the compatibility between them is something the individual chart's own documentation has to carry.

So a deployment that mixes charts from this catalog with charts from elsewhere is doing the version reconciliation itself.

Charts, scaffolding and release automation in one repository

The root of the repository explains how the catalog is maintained, and the file list is a better map than the README.

There is a charts directory holding the catalogue itself and a templates directory, which is the chart scaffolding new charts are generated from. There is a configuration file for a chart release tool, so publishing a new chart version is a machine step rather than a manual one. And there is a shell script whose name says what it does: a common test runner, presumably so that every chart can be linted and rendered the same way.

Around those sit the quality gates. A pre-commit configuration is committed and the README carries a matching badge, and a renovate badge implies dependency updating is automated across the charts. There is a markdown lint configuration, a file telling the documentation generator what to ignore when building chart documentation, an editor configuration, a development container definition, and a directory for editor settings.

There is also an all-contributors configuration file, which explains the second half of the README.

Nothing in that list is unusual for a chart repository, and taken together it describes a project whose real work is automation: scaffolding in, linting and common tests in the middle, releases out, with the human contribution arriving as chart maintenance.

Most of the README is a contributor table

The proportions are worth stating. The substance of the file occupies the first third: what the catalog is, one link to the getting-started page, the support pointers, the development model paragraph, and the contact list.

Everything after that is generated. There is a marked block for the contributors badge with an instruction not to remove or modify it, a generated list of people with links to their own sites and to their commits filtered by role, and a placeholder comment where a chat widget is meant to be inserted.

The role markers are the interesting part of that table. Each contributor is credited with categories such as code, documentation, infrastructure, review of pull requests, bug reports, and financial contribution, and each category links to a filtered commit list or an issue search. So the table is not decoration; it is a searchable record of who does what kind of work on this project.

The effect on a reader is still disproportionate. A file that is mostly contributor avatars tells you very little about what the charts do or how to install them, which is why the documentation has to live elsewhere. It also means the README has to be regenerated whenever someone is added, so the parts that would benefit from editing are the parts a contributor is least likely to touch.

Compatibility is promised rather than demonstrated

The catalog's central claim is compatibility, and the README states it as an intention rather than as a guarantee. All charts are supposed to work together and are supposed to be easy to set up with any Helm-compatible deployment tool, which leaves two words doing the work.

There is no compatibility matrix, no tested-against list, no table of minimum application versions per chart, and no statement about what happens when a chart's maintainer bumps a dependency that other charts in the catalog also depend on.

Licensing is the other thing a user has to work out per chart. The repository itself is AGPL version 3, which is a licence chosen for the tooling and templates. Charts wrap third-party applications, so what a user deploys carries the upstream project's licence, and the repository-level licence does not settle that. Anyone shipping a chart to customers needs to read the chart's own terms.

Both of those gaps point at the same place. The repository is a distribution mechanism with automation around it, and the judgement about whether a given chart works in your cluster is documented per chart and per application, in the manual that lives on the project site rather than here.

Editorial conclusion

TrueCharts fits someone who already knows how to add a chart repository and wants many community-maintained charts with per-chart tuning options rather than one vendor's bundle. It does not fit someone who wants to be walked through an install in the repository itself, because there is no command there. Verify four things before you depend on it. Find the actual documentation domain, because the README points at trueforge.org for the manual and the FAQ while the repository's homepage field says truecharts.org. Check the release history rather than the commit history, since the newest tags are named after a different tool, the last of them from 2025-09-07, while the default branch was pushed on 2026-09-22. Read the chart's own licence before deploying, because the repository is AGPL-3.0 and charts inside it carry their own terms. And plan for independent maintenance, since the project states that each maintainer sets their own roadmap and speed with no central plan, which is why a set of charts can work together without sharing a version policy. Support runs through a GitHub issue tracker, a Discord support channel and an email address, and the project itself expects most questions to have been asked already.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes