Skip to main content

· 2 min read
Kjeld Schouten-Lebbing

As some of you might've noticed, Traefik has been a bit outdated the last few weeks. The reason behind this, was a multitude of potentially breaking todo's where left and we don't want to bother users with continues manual intervention on breaking changes. By now we've fixed the remaining issues and will soon release a breaking-change release for traefik and a patch for all the charts.

In short we've ensured that we only use our signature "tc-system" namespace for storing configuration and middlewares for traefik. This ensures consistent behavior for users using ingressClasses and allowed us to, cleanly, fix the known bug where a port got appended to the TrueNAS SCALE "portal" button.

This also means that charts that do not get patches because they are not ported to new common, most notably: Nextcloud Will inherently not work anymore. Though, users would've been ill-adviced using it at all currently... due to the big ongoing nextcloud rework.

Unrelated new issue

We also got the request from iX-systems staff a while ago to limit our use of non-ix-prefixed namespaces on kubernetes. While the other work to do so, requires a lot of work building our own operator helm-charts, these Traefik changes are the initial step to comply to those wishes. The "low hanging fruit".

As we're working hard on building seperate operator helm-charts, instead of handling it in the background.This work leads to a unrelated temporary issue, which has been created on purpose: CNPG will currently only be installed on new systems, if one of our "enterprise" charts is being installed. More news about this will be released later.

· 4 min read
Kjeld Schouten-Lebbing

Previously we've warned users against using the stop-botton on TrueNAS SCALE. At the same time we also understand, that users expect platform uniformity between Helm and SCALE. That's why we're happy to announce our own solution stop our Charts: TrueCharts Stop-All!

About that stop button

First off, we would like to go into a bit more depth about the design issues of the TrueNAS SCALE "Stop" Button. We've hinted at it previously, but it's always good to explain why we need to step in ourselves.

The idea with Kubernetes, is that one tool should be managing deployment of objects at a time. Often indicated by a managed-by annotation on said objects. With TrueNAS SCALE, the middleware, triggers a management tool called "Helm" to deploy objects. So far so good, a GUI isn't magically able to trigger other software, after all.

However, with the stop button, iX decided to also start editing some of those objects themselves. Specifically "Deployments" and "StatefullSets", setting them to 0 "replica's" meaning "run nothing". That sounds completely fine, however: In these cases "Helm" is the actuall management tool for those objects, so everything a helm action is triggered, those modifications are instandly removed.

That's where the problems start to become bigger and bigger, because helm actions are triggered more often than people realise. For example: A reboot also triggers helm, requiring the same "hacks" to put things "back to sleep" again.

iX also decided to not even include all default objects that are technically "running", like: Daemonsets, Jobs and Cronjobs. Which leads to issues with breaking jobs or daemonsets/jobs locking access to PVC's. There it becomes more complicated, as kubernetes does not only exists of those "default" objects. There are also "Custom Resources", objects that are defined by other charts and there is also the ability of other management tools, like Operators, to add objects.

When making such changes through Helm, it would be relatively easy for Chart/App developers to mitigate this. However, iX decided not to and does not even expose the "stop" button state to the Chart/App developers, leaving us completely without tools to mitigate these design flaws.

In the end, that leave out how the stop button can get into a near endless state of limbo, if not all running objects are stopped correctly... Putting the cherry on top.

Looking for a better way forward

With that all concluded, we decided to look into "what needs to be done", to get all our Charts to have "stop" button functionality back again. It's clear that the stop button, even with little fixes, isn't going to be a future proof design. It completely needs to be redesigned, including all it's backend logic. Sadly enough, refactors of said scale (pun not even intended), are currently not the priority of iXsystems, so not something we can rely on for our users.

We concluded that the only way to do so reliably, is through Helm itself. We know which objects we have, how they need to be stopped and can do so reliably through Helm. Which means: Do it ourselves!

The solution: TrueCharts Stop-All

With the most recent updates, we've introduced a new option: TrueCharts Stop-All This option will cause all your running objects to slowly shut themselves down or, in the case of our postgresql backend (CNPG), "hibernate".

It's designed to feature support for all default kubernetes objects deployed using our common chart: Daemonsets, Deployments, StatefullSets, Jobs and Cronjobs. On top we can easily expand that to cover any operator based objects, like cnpg, that needs to be shut down as-well in the future!

How To Use Stop-All


On SCALE this is a little checkbox on editing the App. Check it and its done

NOTE: Do not forget to uncheck the "Stop-All" checkbox to start the App again.

Using Helm

On native Helm, the same functionality is also availably: Simply set the following in your values.yaml file:

stopAll: true

· 3 min read
Kjeld Schouten-Lebbing

We're glad to finally announce the end of our code-freeze. Since a few days we've re-enabled our automatic updates and within a few weeks everything should balance out again automatically!

At the same time, we've not completely finished porting all stable-train charts to the new common, 65 are still missing. But we've clearly label those updates as breaking in the changelog when they come in. Most of those are charts that have more complications than anticipated, so need a little quality time with our maintainers which takes a while.

Known Issues

Now that we're mostly done, we also need to report a few known issues with the new backend:


The Stop button should not be used on any TrueNAS SCALE Apps that uses postgresql. It due to severe design mistakes by iXsystems, it will get into an endless loop and never finish. We're reported the issue to iXsystems and they are not interested in fixing this.

  1. Postgresql breaking on reboot

We're seen some edgecases where the new database backend breaks after a reboot. Often after the STOP button was used, though we cannot trace the issue down back to the use of the stop button itself. These issues are reported to the folks over at CNPG and we've also thrown them an email to discuss weither we can fund them to fix these issues

  1. hostNetworking changes

After much R&D, our staff have discovered quite a few nasty kubernetes-level bugs with hostNetworking. As a result, we've decided to never enable it by default anymore on any of our charts/apps, as we cannot guarantee its stability. For some charts that, often, require this setting (like tailscale), users would have to manually and explicitly enable it from now on.

The setting has also moved in the GUI.

  1. Deprecated certificate system and you

With most Charts ported, we want to highlight the fact that the "TrueNAS SCALE (Deprecated)" certificate option, should not be used anymore. We cannot guarantee it's stability nor can do anything at-all to help out. It will also be removed as an option in the future, though that will be months rather than weeks.

The future

With the charts slowly all being ported, we can start working on our long-term plans again. One of those plans is a renewed focus on native Helm Charts.

For May and June, we're planning to go all-in on improving documentation for use of our charts as normal Helm charts. At the same time we're going to work on ensuring all our SCALE specific tricks (of which only a few are left, luckily), will have automatic alternatives for normal kubernetes clusters.

To highlight this, we've asked Artifact hub, to highlight our Common-Library chart, as an "official" TrueCharts Helm chart. All users of helm should be able to use the power of this advanced common-library, to build the Helm Charts they please... Without even relying on TrueCharts to host their charts for them!

Check it out here: And also check out the docs as always:

· One min read
Kjeld Schouten-Lebbing

While most of our migration to new common worked out reasonably well, we've recieved many issues with regards to another change. Our change for the "Arr" Apps, like Radarr and Prowlarr, to their new Postgresql backend ended up terribly.

We did not correctly anticipate how hard that migration was going to be for our users and also encountered a number of bugs and design mistakes for those Apps. After long consideration and attempted bugfixing, we've decided to revert the move to Postgreqsql for the "Arr" Apps, back to sqllite.

This also means that after next change (which will be flagged as breaking due to moving back the database change) you will also be able to neatly import your "Arr" App backups from old common again.

We've very sorry for this revert and we completely understand that we should've done considerably more research before implementing this move to a different database version. The revert should be made available shortly, within 24 hours.

· 4 min read
Kjeld Schouten-Lebbing

We're close to releasing releasing the breaking port of another 50+ of our "Stable" train charts to the new common train. With this, we want to look back on a few things we've noticed with the initial release:

Breaking Changes

Generally speaking, any change in the first semver digit of our versions, means a potentially breaking changes. How much this affects you, usually is effected by both the updates and your personal setup. In this specific case, we want to make extra clear that 99.9% of our SCALE Apps will require manual reinstall.

For SCALE: This also means anything in databases is going to be completely wiped unless you've HeavyScript/TrueTool backups and/or have followed one or more of our community migration guides. We should've been more clear that this behavior includes any and all databases and is not limited to MariaDB. Sadly enough this "wipe on App deletion" is a design in TrueNAS SCALE and not something we have influence over.

Our Helm users would, in most cases, with adapting their current values(.yaml) file in accordance with the new structure. though databases will still get wiped when doing the update.

GPU Support

GPU support took two snags:

  • One was an obscure SCALE bug where dicts with one item didn't get rendered in the GUI (and it's output) accordingly. We've created a temporary patch for this to compensate
  • The other was a minor permission issue, namely an additional group that should've been passed that got lost in development-translation from old to new common

Both are by now resolved and (being) rolled out. In the future we plan to prevent at least the first issue more thoroughly by manually checking if the interface behaves correctly when doing big GUI changes.


We're still having some issues getting the Addons, primarily the VPN addon, behaving correctly. Mostly this is due to significantly increased hardening of our default kubernetes deployment. We expect this to be fixed within a week or two, in the mean time users depending on our charts being used with VPN might want to wait a little.


There is some annoyance over the fact we use Discord for support. We're aware of this and are actually contemplating moving to another platform (as well). Sadly enough we do not have unlimited time available to work on the new common, release a new branding style and expand support to another platform. Users can expect a Discord alternative either end of 2023 or somewhere in 2024.

Verbal Abuse

A much less okey subject is the fact multiple of our staff members have suffered verbal abuse of varying degrees. Some have even led to cases where platform (reddit, discord etc.) needed to step in to take action. While sometimes a staff response might seem a tad blunt or not to your liking, some of the things we've seen are completely and utterly unacceptable. We've a head moderator, JagrBombs if you've any issue with a staff member.

We've taken steps to prevent needlessly exposing our staff to this. One of which is limiting our presence within certain communitie on an as-needed basis.


In the end we've gotten a lot of feedback on the new release. Understandably many users are/where upset a reinstall was required. We want to highlight that we understand the frustration, but with the scope of these changes, a complete rewrite of our Common backend, we didn't have much choice on SCALE. It's important to note, that users on SCALE cannot update via the update button in almost all cases, so users do not have to worry about magically losing data by using the update button for this release.

Another topic we've seen mentioned was "but they say they are production ready", we want to be completely clear about this: TrueCharts is not production ready at this time. In the future, after a seperate announcement, only our "Enterprise" train will be considered "production ready". We want to highlight that this does not mean "stable" users can expect these breaking changes more often, as we don't plan to put another 700+ hours into the common chart any time soon. But it does mean, users should NEVER depend on our stable train for production, unless they do so on their own risk.

We wish all our users the best in going through these migrations and our support staff is available on Discord if you need any help.

· 2 min read
Kjeld Schouten-Lebbing

Hope everyone had an amazing easter, we know we had a busy one to say the least!

We are excited to announce that we have completed porting the first 222 charts in our "stable" train to our new "common" library chart. This chart serves as the basis for all of our apps and charts, and we believe that it will provide a more stable and reliable foundation for all of our future work.

While there are still over 160 charts left to be ported in our stable train, we expect to complete this work before the end of the month. To ensure that we have sufficient time to complete this work, we are extending our code freeze for the stable train until May 1, 2023. After this date, we guarantee that we will resume our normal update schedule.

In addition, we want to make it clear that we have lifted the code freeze for our "Enterprise" and "Dependency" charts, and will continue to provide updates for these charts on a regular basis.

It is important to note that this update is considered "most likely breaking," and will likely wipe all databases used in charts. We also anticipate that there may be some regressions, which is why we encourage users to file bug reports or contact our support staff if they experience any issues.

We would like to take this opportunity to thank our community for their patience and understanding as we work to improve our platform. We believe that these updates will provide significant benefits in terms of stability, reliability, and functionality, and we look forward to sharing them with our users in the coming weeks and months.

As always, we welcome any feedback or suggestions from our users, and we remain committed to providing the best possible experience for everyone who uses our platform. Thank you again for your support, and we look forward to continuing to work with you in the future.

· One min read
Kjeld Schouten-Lebbing

After a lot of work by @xstar and review by our staff, we've finally officially released our new fancy charts list. It's now easier than ever to search and provides all the basics at a single glance! Check it out here:

At the same time, we've decided to remove/hide the list with default ports and paths. We feel that, in due time, this info should be added to our documentation on a per-application basis, on top of that it often lead to confusion as things like ports are not always as simple as they look in a spreadsheet.

As a sidenote, we want to highlight the fact TrueTool is not developed anymore and the repository removed. We want to advice everyone to support @heavyBullets and use HeavyScript instead:

HeavyScript is now also featuring special fixes, to ensure TrueCharts SCALE Apps can be stopped if they cannot be stopped in the GUI. This comes in very handy when you want to mount your PVC volumes for maintenance, check it out!

We hope that these changes makes it easier to use TrueCharts for everyone, even those that have not yet picket-out the Chart they want to use!

· One min read
Kjeld Schouten-Lebbing

We are excited to announce that the TrueCharts project has undergone a makeover with a fresh new look! Our team has been working hard behind the scenes to bring you a new logo, logo animations, and headers is clean, modern, and easily recognizable, making it a perfect representation of what TrueCharts is all about.

We've also created logo animations that bring our new logo to life. These new logo animations will help us stand out and make a lasting impression on our audience.

In addition to the new look, we're thrilled to announce that we've launched our official merch store on Etsy!

By purchasing from our merch store, you're not only getting a cool piece of TrueCharts swag, but you're also supporting our project. Every purchase helps us continue to develop and improve our platform, making it the best Helm and App repository out there!

We're very excited about the new look and the launch of our merch store, and we hope you are too. Stay tuned for more exciting news and updates from the TrueCharts project, as we continue to grow and evolve!

· 2 min read
Kjeld Schouten-Lebbing

Two and a half years ago, we started as nothing but a fork of the k8s-at-home project with added support for TrueNAS SCALE. But since then, we've grown quickly and surpassed k8s-at-home in many ways with our fresh custom-made common-chart.

Our focus on providing easy-to-use and reliable Helm charts for various applications has been steadily gaining popularity. As our SCALE support solidifies, we've been getting more and more questions about supporting other Kubernetes-based platforms. And we want you to know that we've been listening!

Recently, we made the first steps towards giving other platforms the attention they deserve by fixing the release workflow for building a normal Helm repository. Starting Q2 2023, we plan to slowly but steadily begin work on supporting Rancher as well, including full GUI support!

You may slowly see changes in things like our documentation structure, Discord channels, and YouTube video names, including the inevitable broken links. But we believe it will be worth it, lets say "for the greater good"...

In addition to expanding our platform support, we've also been secretly working on a complete redesign of our project to match our new multi-platform goals. We're keeping the redesigns a semi-secret for now, but we're certain that everyone will be amazed by the incredible artwork our designers have come up with!

But we're not done yet! With the growth of the project and much feedback (Special shoutout to @HeavyBullets from, it slowly became clear that we couldn't both build amazing Charts/Apps and offer specialized tools for the platforms we build for. We want to focus on what we're good at: building those amazing charts.

Taking everything into account and with some pain in our hearts, but also knowing there is a very good alternative out there called "HeavyScript," we've decided to drop development of TrueTool. We would advise everyone to migrate to HeavyScript, which offers a very similar featureset and workflow as the good 'ol TrueTool!

Overall, we're excited for what the future holds for the TrueCharts project. We're committed to providing easy-to-use and reliable Helm charts for our users, and we're always looking for ways to improve. We believe that focusing on what we do best will allow us to do even more for our users and the community.

· 4 min read
Kjeld Schouten-Lebbing

As part of our March breaking change update of all our apps, we're glad to announce the first round of updates:

  • Dependency train has been updated, except "Collabora" and "Postgresql" which will be moved to the "stable" train later
  • Enterprise train has been updated
  • Vaultwarden has been added to the enterprise train
  • Authelia has been added to the enterprise train
  • Blocky gained backend support for more query logging options, which will later be added the the TrueNAS SCALE GUI.

We've done considerable testing to validate if, and how, we could add automated migration. But the changes are so significant, that the chance of things breaking is many times too high. So while we're sorry for the inconvenience, users will likely have to reinstall many of their Apps this month.

Luckily enough, the enterprise train did not contain anything using Postgresql databases, so you don't have to worry about updates nuking databases.

But on the topic of nuking databases: We're working internally on a script to export all your postgresql databases, which will be released before the stable train will get it's round of updates. That way you don't have to manually export all those sql files.


We want to repeat that this will be a breaking change. While some Apps/Charts might update without issue, many will not.

In those cases, the only solution is to reinstall. Due to the fact that the complete backend is rewrithen from scratch, it's simply too much for us to write.

Highlighted changes

We want to highlight some of the biggest changes, as there are some real showstealers in this update to make it worth it!

Cert-Manager Certificates

We're heard many of you complain about flaky and limited certificate behavior on TrueNAS SCALE. It's understandable people are upset and so are we.

To ensure users have an actually solid experience, we've decided to implement the current industry leading certificates solution: Cert-Manager. It supports more forms of certificates, is faster to setup and is build by people that are actually specialised in certificate management. Which, lets be realistic, NAS developers are not.

Later this month, we'll release some guides for setting it up, but here's some screenshots:

Cert-Manager App

Configurable Cloud Native Postgresql

This is our biggest change this release. We moved to a completely different postgresql backend. Backed by CloudNative Postgresql, a kubernetes operator for postgresql.

You might ask "what the heck is an operator", in short it's a solution to have a specialised project maintain deployments of things within kubernetes. They write code to ensure things like: updates, upscaling, downscaling and deployment go smoothly. Basically the same thing as Cert-Manager does for certificates, CloudNative Postgresql does for Postgresql Databases.

The upside to this is that we can be certain your database deployments are designed by people that are specialised in the database you want to have deployed. It limits your risk of dataloss and our work of maintaining it. Simply put, your database deployments should be managed by a specialist in databases, not by NAS or Helm-Charts developers.

Postgresql Settings

Enterprise Train and breaking changes

We also want to announce and put-in-place a new breaking-changes policy for the Enterprise train. Which will take effect 01-04-2023:

  • All Charts in the Enterprise train, will get one-by-one attention to write migration scripts where possible
  • If there are breaking changes, we will write migration guides for each of them, customised where needed
  • Breaking changes will be announced at least 3 months in advance and older versions (pre-breaking-change) will continue to be supported for at least 3 months afterwards (so at least 6 months after the announcement of a breaking change)
  • In the future help with migrations will, obviously, be included in the priority enterprise support packages that come with our future SLA offerings for the Enterprise Apps

These measure should ensure users that require our Apps for production use, are not surprised again with unwanted breaking changes in the future. While, at the same time, everything stays available for everyone to work with, for free.