Skip to content
TrueCharts Charts

Docs

News

Merch/Store

TrueCharts News

The End of Container Mirroring

Steven McElligott
Steven McElligott
Head Moderator

In the ever-evolving landscape of containerization and application deployment, TrueCharts has been at the forefront of providing users with streamlined and efficient Helm charts. As TrueCharts continues to prioritize user experience and development efficiency, a notable change is on the horizon – the decision to discontinue mirroring containers. We’ve highlighted below the main reasons for this change.

  • Focusing Dev Time on Innovation: TrueCharts has always been committed to delivering high-quality Helm charts that simplify the deployment of applications on Kubernetes. By discontinuing container mirroring, the development team can now redirect their efforts and time towards enhancing existing charts, introducing new features, and ensuring the overall improvement of the TrueCharts ecosystem. This shift in focus aims to bring users an even more polished and feature-rich experience.

  • Enhanced Clarity for Chart Users: The decision to cease container mirroring brings increased transparency for TrueCharts users. With a clear distinction between containers provided by TrueCharts and those hosted elsewhere, users can easily identify which containers are in use within their deployments. This added clarity fosters a better understanding of the components powering their applications and promotes a more informed and empowered user community.

  • Faster and More Efficient Processing: Our current automated testing, takes a lot of processing time. Part of this is separated testing and releasing of the the container mirror. By removing the container mirror, we can lower the amount of tests run separately by 20%, significantly increasing the speed at which we can follow upstream releases of new versions.

As well, we would like to highlight these two important aspects of this transition below

  • DockerHub Rate Limits: In a world where some container registries are subject to rate limits, this change does mean users might hit rate-limits when pulling certain containers. Especially those from dockerhub. If this is the case, please contact the container creator and request they use a different container registry.

  • Gradual Transition for Current Users: Change can be daunting, especially for existing users accustomed to a certain workflow. Therefore, the discontinuation of container mirroring will not impact current users for at least a year. During this transition period, users can continue to benefit from mirrored images while TrueCharts prepares them for the upcoming change through clear communication and support.

  • Seamless and Non-Breaking Change: TrueCharts is committed to making this transition as seamless as possible. Users can expect a non-disruptive experience, with no breaking changes to their current deployments. TrueCharts will provide comprehensive support to guide users through the transition, ensuring that the shift away from mirroring is a smooth and hassle-free process.

Conclusion

As TrueCharts takes this strategic step towards discontinuing container mirroring, the focus remains on user experience, transparency, and efficient development. By embracing this change, TrueCharts aims to provide users with an even more robust platform for deploying applications on Kubernetes. As the containerization landscape continues to evolve, TrueCharts remains dedicated to simplifying the deployment process and empowering users with the tools they need for success.

Stability Tiers and Helm Support

Kjeld Schouten
Kjeld Schouten
Maintainer & Founder of TrueCharts

We’re very glad to announce a new step in our project: Stability Tiers.

What are Stability Tiers?

Stability Tiers is a tier list of platforms supported by TrueCharts, ranked by how well we think our Charts function on each platform. Of course, all platforms get full access to community support, but we want to give realistic expectations on how many “snags” users can experience on the platform of their choice.

Improved First-Tier Helm Support

With the new tiers, we are also finally ready to announce that we’ve completed the required work to officially release our Normal Helm Charts as a first-tier supported platform. This also means that our industry-leading community support is now available for Helm users!

We want to make clear that, just as with SCALE, not every setting we offer is going to work well with every Chart. Sadly, we have not documented this very well, if at all. In the future, we want to document the release state (Experimental or GA) clearly for each Helm option in the documentation.

TrueNAS SCALE and Its Tier

While previously we’ve seen great effort and interest from the developers of TrueNAS SCALE, iXsystems, there’s been a shift in priorities towards limiting Kubernetes support and prioritising their own catalogs at the cost of third parties like TrueCharts. We’ve also noticed a shift away from their previous plans to support multi-node clusters, accompanied by a disappointing disregard for providing any decent backup utility for their platform.

At the same time, we’ve been working hard on hardening our pipelines by signing both our container builds and Helm Charts. Sadly, TrueNAS SCALE, due to explicit design choices by iXsystems, also does not offer any tooling to ensure Helm Charts have their signatures validated before installation. This leads us to conclude that TrueNAS SCALE Apps are inherently less secure and professional than Helm Charts.

All in all, and after long deliberation, this has led us to decide to move TrueNAS SCALE to a “Second Tier” platform, as we cannot fully guarantee the same stability and reliability that normal Helm offers. This, however, does not mean a decrease in development efforts. We’re still planning to fully support the platform where we can and expand both the catalog and our feature set on there in the future.

What it does mean is that some features might be slightly less reliable due to poorly designed “middleware” that is part of TrueNAS SCALE, which we, sadly enough, cannot do much against.

Future Platforms

However, there is more! We’re also glad to announce we’re working on supporting two more ways of deploying our Helm charts:

  • FluxCD
  • Rancher

For FluxCD, we hope to create a catalog of pre-made helm-release+kustomize files that can be readily copy-pasted into your GitOps repository! Even better, we’re working hard to automate the deployment of GitOps with Flux, Sops-Encryption, and even a dedicated operating system: Talos-OS!

For Rancher, while you can already load our helm charts into Rancher and edit the YAML like any other Helm Chart, we are planning to add custom Rancher GUI elements to each and every published Helm chart. Just like with SCALE, but this time fully Kubernetes aware without complicated middleware!

The Tier List

This leads us to the following Stability Tier List, which will be documented on the website insert link here and adapted where needed:

  1. Helm
  2. TrueNAS SCALE

We hope this gives users more clarity on which platform to pick and what experience to expect. We’re super stoked to expand this list in the future to support more awesome platforms!

Cluster-Wide Certificates

Stanislav Dimov
Stanislav Dimov
Contributor

We are happy to announce that support for cluster-wide certificates is now available for Truecharts! You can now create a single certificate and use it throughout your cluster. We call these certificates “cluster certificates”.

Before you use the new feature, you should sync the Truecharts catalog and update all of your already installed apps to their latest version.

In addition to the cert-manager and clusterissuer apps you need for normal certificates, to use cluster certificates you also need to install our new kubernetes-reflector app from the enterprise train. For most setups installing the app with default settings is sufficient.

Once installed, edit your clusterissuer app and add a new cluster certificate. Note down the name you called it. Edit the app you wish to use the cluster certificate for and go to the Ingress section. If you have previously used a clusterissuer certificate, remove the issuer name. Click on Show Advanced Settings and add a TLS entry. Enter the name of your cluster certificate, and the certificate host(s) which it will be used for.

For a more detailed guide, see our docs.

Cert-Manager Operator

Anthony Scaffidi
Anthony Scaffidi
Support Team

After building our own MetalLB, CNPG and Prometheus operator charts, we’ve also now finished the work on building our own Cert-Manager operator chart. As of today this chart will be a requirement for new users if they want to use Cert-Manager and required for all users starting August 1, 2023.

If you have already installed clusterissuer follow the below guidance for installation of the Cert-Manager operator chart.

If you have not already done so add the operator train to TrueCharts [as outlined here](/

  1. Run this in the system shell as root:
    k3s kubectl delete --grace-period 30 --v=4 -k https://github.com/truecharts/manifests/delete4
  2. Install cert-manager from the operators train. (Deprecated 2025)
  3. Update clusterissuer to the latest version of (2.0.1+).
  • If you are already on the latest version perform an empty edit of clusterissuer (Edit app and save without making any changes).

If you run into additional issues, please file a ticket with our dedicated support staff via the #support channel of our discord as normal.

Deprecating Old Operators

Anthony Scaffidi
Anthony Scaffidi
Support Team

As part of limiting our promise not to introduce breaking changes to the charts within our Enterprise train, we’ve ensured both the new and old way of dealing with “operators” were both supported.

Starting August 1, 2023, we will completely drop support for the old (pre-July installs only, internal not user controlled) way of handling operators.

After August 1, 2023, additional checks for operators will be enabled, preventing users from making the mistake of installing charts without the right operator from the operator train present. This means that charts will prevent themselves from being updated when you’re still using the old operators at that time.

If you have already installed the metallb, prometheus-operator, and cloudnative-pg operators then no further action is required.

Prerequisites

Add the operator train to TrueCharts [as outlined here](/

MetalLB

The MetalLB operator is only required for users of MetalLB, anyone who does not use or plan to use MetalLB can skip this section.

  1. Uninstall current metallb from Enterprise train.
  2. Run this in the system shell as root: k3s kubectl delete --grace-period 30 --v=4 -k https://github.com/truecharts/manifests/delete
  3. Complete MetalLB installation as outlined here

Prometheus

The Prometheus operator is required for the use of app metrics. Its installation is recommended.

  1. Run this in the system shell as root: k3s kubectl delete --grace-period 30 --v=4 -k https://github.com/truecharts/manifests/delete3
  2. Install prometheus-operator from the operators train. (Deprecated 2025)

CNPG

The cloudnative-pg operator is required for any applications that utilize postgres. Its installation is recommended.

  1. Follow the [CNPG Operator Migration Guide](/ to migrate to the new CNPG operator. Ensure you follow the guide carefully as data loss can occur with this migration if proper steps are not followed.

If you run into additional issues, please file a ticket with our dedicated support staff via the #support channel of our discord as normal.