TrueNAS Release History: FreeNAS, CORE, SCALE and Community Edition

TrueNAS began in 2005 as FreeNAS, a FreeBSD based storage system, became TrueNAS CORE in the 2020 unification, gained a Debian Linux sibling called SCALE in 2022, and is now a single Linux based product sold as TrueNAS Enterprise and given away as TrueNAS Community Edition. As of 25 October 2026, the TrueNAS Software Status page recommends 25.10.7 (Goldeye, 2 September 2026) for general use, lists TrueNAS 27.0.0 RC.1 (6 October 2026) for early adopters, and says CORE is no longer under active development.

Below: every major version with its date, base, kernel and OpenZFS version, how apps and updates changed, what "supported" means for TrueNAS, and an upgrade routine for a home or small office system. For ZFS basics, start with our home NAS guide.

Key takeaways

• One product line now. The SCALE and CORE names were dropped in 2025. The Linux based release is "TrueNAS", sold as Enterprise and free as Community Edition, from the same image.
• The current recommendation is 25.10.7 for General and Mission Critical users. TrueNAS 27 is at RC.1 for Early Adopters; 28 exists only as nightlies.
• Version numbers changed meaning. From 22.02 to 25.10 the numbers followed a year.month pattern. Starting with TrueNAS 27 (renamed from 26 during its beta), the project ships one major version a year, numbered for the year it is the stable release.
• There is no fixed end of life date. A TrueNAS version reaches end of life when it is no longer recommended for any user type on the Software Status page, and its documentation moves to the archive.
• Apps changed engine three times: FreeBSD jails, then Kubernetes (22.02 to 24.04), then Docker (24.10 onward), with LXC containers fully supported in 27.
• The CORE to Linux move is one way. You cannot roll a migrated system back to a FreeBSD boot environment, and moving from CORE straight to 24.10 or later needs a clean install with a configuration restore.
• Boot environments protect the OS, not your data. The updater snapshots the boot pool before each update, but pools, datasets and apps are not rolled back with it, and a ZFS pool feature upgrade cannot be undone.

Where TrueNAS came from: FreeNAS to CORE

FreeNAS, 2005 to 2009

TrueNAS's own FreeNAS history page says FreeNAS was created by Olivier Cochard-Labbé and based on FreeBSD, and that it "first made the leap onto the internet in 2005". It was an embedded storage server: a small FreeBSD image you booted from a USB stick or compact flash card, configured from a web page, and used to share disks over SMB, NFS, FTP and iSCSI.

The TrueNAS company history says that in December 2009 iXsystems took over development of FreeNAS, when the project "was about to switch development from FreeBSD to Linux", and reimplemented it on FreeBSD 8. That kept FreeNAS on FreeBSD, with its native ZFS, for another decade. Our FreeBSD release history covers that base.

FreeNAS 8 to 11: jails, plugins, bhyve and a new interface

The FreeNAS page and the company history list the milestones of the iXsystems era (the version notes for these releases are no longer in the current documentation):

• FreeNAS 8.2 brought the "modern jail and plugin architecture": third party applications installed into FreeBSD jails. 8.3 (2012) moved plugins to PC-BSD based packaging.
• FreeNAS 9.1 (2013) improved the volume manager; 9.10 added the bhyve hypervisor for virtual machines.
• FreeNAS 11 brought a new interface; 11.2 (December 2018) shipped the Angular web interface, the iocage jail manager and a real time version 2 API; 11.3 added an ACL editor and replication improvements.

Alongside FreeNAS, iXsystems sold TrueNAS, which the FreeNAS page describes as "the enterprise appliance edition of FreeNAS with high availability". The two were maintained separately although they shared most of their code.

2019 and 2020: unification and TrueNAS CORE

In 2019 iXsystems decided to unify the two projects under the TrueNAS name. The FreeNAS page lists the announcement that the FreeNAS and TrueNAS code bases would be unified in TrueNAS 12.0, the reveal of "TrueNAS Open Storage" creating TrueNAS CORE and TrueNAS Enterprise, and then the release of TrueNAS 12.0 CORE as the standard upgrade path for FreeNAS 11.3. The company history describes TrueNAS CORE as "the continuation of FreeNAS". The last FreeNAS release, 11.3-U5, is dated 29 September 2020 on the Software Status page.

One inconsistency: the company history files "TrueNAS CORE 12.0 enters RELEASE status" under 2021, while the FreeNAS page and the 11.3-U5 date put 12.0 in late 2020. The last 12.0 build, 12.0-U8.1, is dated 14 April 2022.

CORE 13.0 and 13.3: the last FreeBSD releases

TrueNAS 13.0 was the last major CORE release for both community and Enterprise users. Its release notes date 13.0-RELEASE to 10 May 2022 and record the merge of OpenZFS 2.1. The final 13.0 build on the Software Status page is 13.0-U6.8, dated 14 July 2025.

In 2023, the company history says, CORE moved to maintenance only status and all new feature development shifted to SCALE. A TrueNAS blog post on CORE's plans then announced a 13.3 release based on FreeBSD 13.3, with a release candidate planned for May and a formal release in June 2024. The post said CORE was entering a "sustaining engineering phase" and was "not anywhere near its end-of-lifecycle phase", and it recommended SCALE for new installations.

The 13.3 release notes say 13.3 was "intended solely for community users" who wanted incremental fixes to FreeBSD 13.3, jails, bhyve, OpenZFS and Samba; it was not offered as an Enterprise upgrade. The component table lists FreeBSD 13.3-RELEASE-p2 and OpenZFS 2.2.4-1, while the summary at the top of the same page says OpenZFS 2.2.3, so check your own system with zfs version if the exact number matters. The last 13.3 build is 13.3-U1.2, dated 29 April 2025.

Two removals in this period matter for anyone still on CORE. The S3 service was deprecated in 13.0 and removed in 13.3 for "security vulnerabilities and maintainability issues", and the web interface shell was removed in 13.3. The 13.0 notes add that, following the upstream FreeBSD 13.2 end of life, the virtualization features in 13.0 (plugins, jails and virtual machines) are now obsolete.

Today the Software Status page carries a short line: "TrueNAS CORE is no longer under active development." Enterprise customers are told to contact support about migration.

Why SCALE moved to Debian, and how CORE and SCALE became one

The Linux decision

TrueNAS SCALE was announced in 2020 and entered alpha that year, entered beta in 2021, and reached general availability on 22 February 2022, a date the company history writes as "2.22.22". The CORE plans post explains the reasoning in plain terms: "the bulk of the open source innovation we rely on is created and supported on Linux first", and a Linux base broadened hardware support and opened the door to containers and scale out features.

SCALE was built on Debian, with a Linux kernel and OpenZFS integrated by the TrueNAS team. The 24.04 release notes list the base as "Debian 12 (Bookworm)". The release notes for other versions publish the kernel and OpenZFS versions but not the Debian release, so the table below only names Debian 12 where the notes do.

A TrueNAS system is not a general Debian server (see our Debian release history for the base itself). Every current version note warns that updating TrueNAS "using apt or any method other than the TrueNAS web interface can make the system inoperable".

Convergence: Fangtooth and the end of the SCALE name

The convergence happened in 25.04 "Fangtooth". The TrueNAS release announcement for 25.04.0 called it "the recommended and unified upgrade path for both SCALE 24.10 and CORE 13.x installations" and said that "as Fangtooth matures, CORE and SCALE will unify into a common Community Edition and Enterprise version".

The company history records the result for 2025: SCALE reached feature and performance parity with CORE and was "renamed simply TrueNAS", with TrueNAS Enterprise for commercial appliances and TrueNAS Community Edition as the free download, and "TrueNAS SCALE and TrueNAS CORE designations have been discontinued". In the same year iXsystems began doing business as TrueNAS. The FreeNAS page now says "the FreeNAS capabilities are now delivered as the TrueNAS Community Edition".

The Software Development Life Cycle page describes the current model as open core: "Community and Enterprise systems run the same software from the same installation image, with Enterprise features unlocked through licensing." That matters for security planning, because a Community Edition system and an Enterprise appliance on the same version carry the same base packages, kernel and OpenZFS build.

TrueNAS 27: a rename and an annual cadence

The newest change is to the version number itself. The TrueNAS 27 version notes say the page "tracks the latest notes for TrueNAS 27, which was renamed from TrueNAS 26", and the RC.1 changelog includes the line "Renames TrueNAS 26 to TrueNAS 27". The betas kept their old names: 26-BETA.1 (7 April 2026), 26-BETA.2 (17 June 2026) and 26-BETA.3 (20 August 2026), then 27-RC.1 (6 October 2026).

The Software Development Life Cycle page sets the new rule. "Starting with TrueNAS 27, TrueNAS follows an annual release cadence with one major version per year", and the major number reflects "the year in which that version is the stable release". Versions follow a YY.MINOR.PATCH format, with nightly builds named like 27.0.0-MASTER plus a timestamp, then BETA, RC, a .0 release, and maintenance releases numbered 27.0.x or 27.x.0.

Release timeline: every major version, base, kernel and OpenZFS

The table uses dates from the Software Status page and the release notes for each version. "First stable" is the .0 release. "Last build" is the final or latest maintenance release listed on the Software Status page as of 25 October 2026. Kernel and OpenZFS values are from each version's component table; where a version shipped more than one, the range is given.

The Linux line has tracked long term support kernels: 6.1, 6.6, 6.12 and now 6.18, which the 27 notes say receives "long-term maintenance and security updates from the upstream kernel project". Within 25.10 alone the kernel went from 6.12.33 to 6.12.105, a change the version string hides. Our Proxmox VE release history shows a similar Debian plus custom kernel pattern.

What a maintenance train looks like: 25.10 Goldeye

The 25.10 line shows the cadence you should expect after a .0 release. These dates are from the Software Status page.

That is ten post release builds in ten months. The later summaries are mostly about security: 25.10.4 updates the kernel "to address local privilege escalation and other security vulnerabilities", 25.10.5 updates the kernel and Samba, 25.10.6 the kernel and NVIDIA driver, and 25.10.7 moves to kernel 6.12.105 and OpenZFS 2.3.9.

How apps and virtualization changed over time

Apps are the part of a NAS most likely to run third party code and to break on upgrade, and TrueNAS has changed its app engine more often than its file system.

FreeNAS and CORE: plugins, jails and bhyve

On FreeNAS and CORE, applications ran in FreeBSD jails. A jail is an operating system level partition with its own file system root, process table, users and network stack, sharing the host kernel. Plugins were packaged jails with a curated application inside; from 11.2 the iocage manager handled them. Virtual machines ran under bhyve from FreeNAS 9.10.

Updates came in two layers: the TrueNAS release updated the host, and each jail's packages were updated separately. When a jail's FreeBSD release went out of support, so did its packages, which is why 13.0's notes call plugins, jails and VMs obsolete after FreeBSD 13.2 reached end of life.

SCALE 22.02 to 24.04: Kubernetes based apps

The first SCALE releases ran apps on Kubernetes, storing their data in an ix-applications dataset, as the 24.10 notes describe when explaining the migration out of it. Container isolation came with a large control plane for a home NAS.

The CORE plans post also mentioned "Sandboxes" in 24.04, jail like environments built on systemd-nspawn, aimed at CORE users who missed jails. They required manual workload migration.

24.10 Electric Eel: Docker

The 24.10 notes are direct: "24.10 moves the applications backend from Kubernetes to Docker." Custom apps can be installed from a Docker image through a wizard or from a Docker Compose YAML file. On upgrade from 24.04, supported catalog apps migrate automatically: TrueNAS reads the Kubernetes app data in ix-applications, ports it to Docker and stores it in a hidden dataset mounted at /mnt/.ix-apps. A failed migration can be restarted after upgrade with midclt call -job k8s_to_docker.migrate poolname.

Because Docker is now native, the notes warn that users who installed Docker by hand on 24.04 or earlier can see TrueNAS Apps fail in 24.10 or later.

The current docs say "Application maintenance, including version updates, features, and configuration options, is independent from TrueNAS version release cycles." In practice, an app's image and its catalog entry update on their own schedule, from the truenas/apps repository, not when you update TrueNAS.

25.04 Fangtooth: Incus instances, then a step back

25.04 added Linux system containers (LXC) and a new VM layer through Incus, shown on an "Instances" screen and marked experimental. The release announcement said LXC "provides a lightweight functionality similar to Jails on CORE". In 25.04.2, TrueNAS "reintroduced classic virtualization" with a separate Virtual Machines screen; the Instances screen was renamed Containers, and VMs created on it in 25.04.0 or 25.04.1 kept running there.

That detour has a long tail. 25.10 stops those legacy VMs from starting at boot, and the TrueNAS 27 notes say they "are removed in TrueNAS 26" (the renamed 27) without migration. Their disks stay on the pool, but you must re-create each VM by hand.

25.10 and 27: VMs grow up, containers become supported

25.10 added Secure Boot for VMs, disk import and export (QCOW2, RAW, VDI, VHDX, VMDK) and VM failover on Enterprise high availability systems. It also added external container registry mirrors for apps and shipped the NVIDIA open GPU kernel modules, which the notes say work with Turing and later GPUs only.

In 27, "LXC containers, introduced as an experimental feature in earlier TrueNAS releases, are fully supported", with GPU passthrough to containers and failover on Enterprise HA.

What each model means for isolation and updates

How updates are delivered, and what "supported" means

Update profiles replaced trains

Older releases offered named update trains. The current Updating TrueNAS page describes update profiles instead, matching the Software Status user types. Community Edition systems default to the highest profile available for the installed version and can choose Developer, Early Adopter or General; Enterprise systems ship on Mission Critical and can choose only General or Mission Critical. The dropdown only offers profiles at or below the level of the running version, and the docs warn that Developer is a non production train.

Release types

The Software Status page labels every build as Early (ALPHA, BETA and RC), Stable (the .0 release) or Maintenance (.1 and later, with .x.y hotpatches). It also states the rule that drives every upgrade: "Update to the latest maintenance release of the current major version before upgrading to the next major version." The status page publishes an upgrade path chart. In it, the supported chain runs 22.02.4 to 22.12.4.2 to 23.10.2 to 24.04.2.5 to 24.10.2.4 to 25.04.2.6 to 25.10.7, with TrueNAS 27.0 marked "anticipated" after 25.10.7. CORE 13.0 can update in place to 24.04.2.5, and needs an ISO install with a configuration restore to reach 25.10.7.

The two permitted methods are "update" (the Update screen or a manual update file) and "ISO install" (save the configuration, install fresh, upload the configuration), which can skip majors if you read the notes for every skipped version.

Boot environments

Each update installs into a new boot environment on the boot pool. The boot environment docs say the update process "automatically creates a snapshot of the current boot environment and adds it to the boot menu before applying the update", keeps the last two boot environments by default, and recommends keeping three to four on production systems. If an update goes wrong you can activate the previous environment and restart.

The same page lists the limits. Boot environments "do not preserve or restore the state of any attached storage pools or apps, only the system boot-pool", and configuration changes made in one environment do not carry into another, so switching back and forth causes configuration drift and missing audit records. For a migrated CORE system, the migration docs are blunt: the move to Linux "is a one-way operation" and activating a FreeBSD boot environment afterward "can break the system".

Verification of update files

The documentation pages used here say updates come from the TrueNAS update server or a manual update file, but do not describe how update files are signed or verified, so this post makes no claim either way. If that matters to you, read the update code in the public truenas/middleware repository and download manual files only from official TrueNAS pages.

Support windows

TrueNAS does not publish end of life dates. The Software Development Life Cycle page says: "TrueNAS does not define a fixed End of Life (EoL) date for its releases. In practice, a version reaches end of life when the TrueNAS team no longer recommends it for any user type." Its documentation then moves to the read only archive.

In practice, the Software Status page is the support calendar. On 25 October 2026 it recommends 25.10.7 to General and Mission Critical users, 27.0.0 RC.1 to Early Adopters and 28 nightlies to Developers. Nothing recommends 25.04, so by TrueNAS's own definition 25.04 and every earlier Linux release are past end of life, and so is CORE. The status page adds that "bug tickets are typically accepted for the latest release of the current stable version", and that legacy versions are provided "as-is" and "typically do not receive further maintenance releases".

Enterprise customers are covered by their contract; the CORE plans post says they "will always be fully supported for the duration of your support contract regardless of the software version". Community Edition users should stay on a recommended version.

Which security features arrived when

The release notes and current docs let you date most of the security relevant features. Where a feature is Enterprise only, the docs say so and so does this table.

Two of these can lock you out. The 27 upgrade clears any 2FA secret with a non standard interval, which could have been set "through the global 2FA setting in TrueNAS releases before 24.04", so re-enroll first. And API keys created through the API with method allow lists in 24.10 or earlier "are revoked upon upgrade" to 25.04. Check every script that calls the TrueNAS API before 25.04 and again before 27.

TrueNAS's security recommendations page adds operational rules: stay on the latest updates, upgrade majors "promptly consistent with the deployment use case", send logs to external syslog, keep "Show Text Console without Password Prompt" disabled, keep passwords out of custom scripts (they appear in cleartext in debug files), and "restrict the TrueNAS web UI, IPMI, and any other management interfaces to private subnets". It lists the web interface and API on ports 80 and 443 as open by default, with SSH, NFS, SMB, iSCSI and other services closed until enabled.

CORE versus SCALE versus Community Edition

Step by step: check, back up, upgrade, verify, roll back

This routine fits a single Community Edition system moving between maintenance releases or to the next major. Read the release notes for every version you will cross first; they are where TrueNAS lists removed features and upgrade blockers.

Step 1: find out exactly what you are running

In the web interface, System > Update shows the installed version and the selected update profile, and the dashboard shows the version too. From an SSH session or the shell, the TrueNAS API client midclt reads the same data. system.version, system.info, update.config, update.status and boot.environment.query are all documented methods in the 25.10 API reference.

# Installed TrueNAS version string
midclt call system.version

# Hardware, uptime and version details (JSON)
midclt call system.info

# Current update profile and update settings
midclt call update.config

# Whether an update is available for the selected profile
midclt call update.status

# Boot environments, which one is active, and which are kept
midclt call boot.environment.query

# OpenZFS userland and kernel module versions
zfs version

Compare the version with the Software Status page.

Step 2: read the release notes for every version you will cross

For 24.10 to 25.10, read 25.04 and 25.10. Look for removed features (the REST API and Instances VMs in 27), authentication changes (API keys in 25.04, 2FA intervals in 27) and hardware changes (25.10's NVIDIA open kernel modules drop Pascal, Maxwell and Volta GPUs).

Step 3: back up the configuration with the secret seed

Before any update, download the configuration file. When the updater asks "Save configuration settings from this machine before updating?", select Export Password Secret Seed and save. The docs explain why: the secret seed decrypts encrypted fields in the configuration database, such as certificates and stored service passwords, and "when a config file is restored without the secret seed, encrypted fields are set to empty values", which breaks local SMB accounts and apps. Store the file somewhere other than the NAS, and treat it like a password store, because with the seed it can decrypt those fields.

Step 4: check pool health and take recursive snapshots

# Prints "all pools are healthy" or details of the unhealthy pool
zpool status -x

# List pools that do not have every supported feature enabled.
# With no arguments this only lists; it changes nothing.
zpool upgrade

Do not run zpool upgrade -a or zpool upgrade <pool> as part of an OS update. Enabling new pool features is one way: once a feature is active, older TrueNAS versions may no longer import the pool, and a boot environment rollback will not undo it. Upgrade pools only after you are sure you will not need to roll the OS back.

Take a recursive snapshot of each dataset tree you care about and confirm a recent backup exists; our homelab backups guide covers restore tests.

Step 5: check apps and API clients

Note each app's version on the Apps screen. List anything that talks to the TrueNAS API, such as monitoring or backup scripts (our homelab monitoring guide covers safe exporters), and check how each authenticates. Remove auxiliary parameters from SMB, NFS and SSH settings; the docs say they "can result in unexpected behavior such as SMB share failures after an upgrade".

Step 6: update to the latest maintenance release, then to the next major

Apply updates from System > Update while the system is idle. First update to the latest maintenance release of your current major version (for example 25.04.2.6), reboot, confirm the system is healthy, and only then move to the next major. Never use apt on TrueNAS. After the reboot, clear the browser cache before logging in; the docs suggest Ctrl+F5.

Step 7: verify after the reboot

# Confirm the new version
midclt call system.version

# Confirm pools imported and are healthy
zpool status -x

# Confirm the new boot environment is active and the old one is kept
midclt call boot.environment.query

Then check Alerts, open each share from a client, confirm snapshot and replication tasks run, start each app and VM, and review System > Audit for failed logins from broken API clients.

Step 8: roll back if needed

If the new version has a problem you cannot fix, go to System > Boot, activate the previous boot environment and restart. Pool state and apps are not rolled back, configuration changes made in the new environment do not carry back, and a migrated CORE system must never boot a FreeBSD environment again.

Common mistakes

• Exposing the web UI or IPMI to the internet. Port forwarding 443 to a NAS puts the API and every login flow in front of the whole internet. Use a VPN.
• Staying on a version nothing recommends. A 24.10 or 25.04 system still works, but it is past end of life by TrueNAS's definition and misses the kernel, Samba and OpenZFS fixes in 25.10 maintenance releases.
• Staying on CORE because it still boots. CORE is no longer under active development, its jails and plugins depend on FreeBSD releases that are out of support, and its S3 service was removed for security reasons.
• Running community apps as root or in privileged mode. Many container images default to root. Run apps as an unprivileged user where the app allows it, avoid privileged LXC ID mapping unless you need it, and mount only the datasets an app needs, read only where possible.
• Upgrading pools before confirming the OS upgrade. A boot environment rollback restores the OS, not the pool. Enabling new pool features first can strand you on the new version.
• Restoring a configuration without the secret seed. Encrypted fields come back empty and SMB local accounts and apps break.
• Installing packages with apt or adding Docker by hand. The docs say it can make the system inoperable, and manual Docker installs on 24.04 or earlier break native apps after 24.10.
• Ignoring API client changes. API keys changed in 25.04 and the REST API is removed in 27. A monitoring script that silently fails after an upgrade hides the next disk failure.
• Skipping release notes when jumping versions. An ISO install can skip majors, but every removed feature in between still applies.

FAQ

What is the latest version of TrueNAS?

As of 25 October 2026, the latest stable release is TrueNAS 25.10.7 (Goldeye), released 2 September 2026 and recommended for General users. TrueNAS 27.0.0 RC.1 (6 October 2026) is available for Early Adopters, and TrueNAS 28 exists only as nightly builds.

Is TrueNAS CORE end of life?

TrueNAS does not use fixed end of life dates, but the Software Status page says "TrueNAS CORE is no longer under active development", and no CORE version is recommended for any user type. The last builds are 13.0-U6.8 (14 July 2025) and 13.3-U1.2 (29 April 2025). Treat CORE as end of life and plan a migration.

What is TrueNAS Community Edition?

It is the free edition of the current Linux based TrueNAS. In 2025 the SCALE and CORE names were dropped; the software is now called TrueNAS, sold as TrueNAS Enterprise on TrueNAS hardware and offered free as Community Edition. Both run the same installation image, with Enterprise features unlocked by license.

Is TrueNAS SCALE based on Debian?

Yes. SCALE and its successor run on Debian with a TrueNAS integrated kernel and OpenZFS; the 24.04 notes name Debian 12 (Bookworm). It is an appliance, so never update it with apt.

Why was TrueNAS 26 renamed to 27?

TrueNAS moved to an annual release cadence in which the major number reflects the year the version is the stable release. The betas shipped in 2026 as 26-BETA.1 to 26-BETA.3, and the release candidate was renamed TrueNAS 27 because it will be the stable release for 2027. Later releases follow a YY.MINOR.PATCH format.

Can I upgrade directly from TrueNAS CORE to Community Edition 25.10?

Not with an in place update. The migration docs say CORE 13.0 or 13.3 can update through the UI to 24.04 and earlier, but moving to 24.10 or later requires a clean install of the target version followed by a configuration restore. Update CORE to its last build first, leave Active Directory before migrating, and remember the move cannot be rolled back.

How long is a TrueNAS release supported?

There is no published window. A version is supported while the Software Status page recommends it for at least one user type, and it reaches end of life when it is recommended for none. In the 25.10 line, maintenance releases arrived about once a month for ten months after the .0 release.

What happened to Kubernetes apps in TrueNAS?

TrueNAS 24.10 (Electric Eel) moved the apps backend from Kubernetes to Docker. Supported catalog apps migrated automatically when upgrading from 24.04, with app data moved into a hidden dataset at /mnt/.ix-apps. Custom apps can now be deployed from a Docker image or a Compose YAML file.

The software around your NAS

TrueNAS itself is an appliance image, so its kernel, Samba and OpenZFS fixes have to come from TrueNAS releases, not from you. The apps, Compose files, backup scripts and small services you run on or around a NAS are different: they pull open source dependencies and container images that you choose and can fix yourself.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard does not scan NAS firmware, manage TrueNAS systems or patch the TrueNAS base image. It fits the software you build and run next to your storage: Compose apps, scripts and services in your own repositories, and their container images.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. If you keep Compose files, app configurations or helper services for a home or office NAS in a repository on a workstation, this is how you scan that repository and its images where they live.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix a lodash CVE, the assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a small dashboard, exporter or automation script you wrote against the TrueNAS API, where the vulnerable dependency is in your own repository and the fix is a change you review and test.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your projects are in Safeguard, you can ask which of them contain a given component and version, for example every service that still bundles an outdated library you also run inside a NAS app container.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• TrueNAS Software Status
• TrueNAS Software Development Life Cycle
• TrueNAS 28 development notes
• TrueNAS 27 version notes
• TrueNAS 25.10 version notes
• TrueNAS 25.04 release notes
• TrueNAS 24.10 release notes
• TrueNAS SCALE 24.04 release notes
• TrueNAS SCALE 23.10 release notes
• TrueNAS SCALE 22.12 release notes
• TrueNAS CORE 13.0 release notes
• TrueNAS CORE 13.3 release notes
• TrueNAS history
• FreeNAS is now TrueNAS
• TrueNAS blog: TrueNAS CORE 13.3 plans
• TrueNAS blog: TrueNAS Fangtooth 25.04 release
• TrueNAS Community Edition
• Updating TrueNAS
• Managing boot environments
• CORE community migrations
• Migration preparation
• Managing global 2FA
• Using audit logs
• TrueNAS security recommendations
• TrueNAS API v25.10 documentation
• TrueNAS middleware repository

Last reviewed: 25 October 2026. TrueNAS publishes maintenance releases every few weeks; check the Software Status page before planning an upgrade.