FreeCORE 15.0: el fork open source que mantiene vivo TrueNAS CORE sobre FreeBSD

En febrero de 2025, iXsystems confirmó lo que muchos sospechaban: TrueNAS CORE 13.3 sería la última versión de la rama FreeBSD de TrueNAS. El mantenimiento activo de la línea se detuvo el 12 de febrero de 2025 y la empresa pivotó todo su desarrollo hacia TrueNAS SCALE, su reedición basada en Debian Linux. Para los sysadmins y aficionados al home lab que llevan años corriendo NAS sobre FreeBSD, el mensaje era claro: o migraban a Linux, o se quedaban con un sistema congelado.

Un año y medio después, la historia dio un giro. El 21 de agosto de 2026, el proyecto FreeCORE publicó su primer release estable: FreeCORE 15.0, basado en FreeBSD 15.1 y pensado específicamente como el sucesor comunitario de TrueNAS CORE. La frase que eligieron para definirlo, “TrueNAS® CORE — continued”, no deja lugar a dudas sobre la intención: llenar el hueco que dejó iXsystems.

Este artículo repasa qué es FreeCORE, qué cambia respecto a TrueNAS CORE 13.3, cómo se compara con TrueNAS SCALE en 2026, y — para los que estén considerando el salto — cómo hacer la migración in-place desde una instalación existente de TrueNAS CORE 13.3. La respuesta corta: si tu NAS depende de jails, plugins FreeBSD o quieres evitar la curva de aprendizaje de Linux, FreeCORE es la respuesta. Si lo que necesitas es Docker, Kubernetes o scale-out clustering, TrueNAS SCALE sigue siendo la mejor opción.

Por qué iXsystems dejó TrueNAS CORE

Para entender FreeCORE hay que entender por qué TrueNAS CORE llegó a su fin. La historia corta: iXsystems había mantenido dos líneas paralelas desde 2022, CORE sobre FreeBSD y SCALE sobre Debian Linux, y mantener ambas era insostenible. SCALE fue ganando tracción porque su ecosistema de aplicaciones (Docker nativo, Kubernetes via apps nativas, GPU passthrough completo vía KVM) atrajo a un público más amplio. En el foro oficial, un desarrollador resumió el problema: “CORE 13.3 será el final del lineamiento FreeBSD. La decisión está tomada.” La migración a SCALE se ofrece como upgrade oficial: los pools ZFS son compatibles, pero los jails/plugins deben rehacerse como contenedores Docker.

El problema es que no todos pueden (o quieren) migrar. Hay al menos tres casos donde FreeBSD sigue siendo objetivamente superior:

• Instalaciones críticas en producción: migrar 10 TB de datos con décadas de snapshots, replicaciones programadas y jails con servicios a medida es un proyecto de meses, no de un fin de semana. Si tu NAS funciona, tocarlo es arriesgado.
• Dependencia de jails y plugins FreeBSD: muchos plugins de la comunidad (Plex, Syncthing, Nextcloud) llevan años puliéndose sobre FreeBSD y no tienen equivalente maduro en Docker.
• Preferencia técnica legítima: el network stack de FreeBSD sigue siendo de los mejores para cargas con muchas conexiones simultáneas. El overhead de kernel es menor que Linux. Y OpenZFS en FreeBSD es el “first-class citizen” — los ports van primero allí.

FreeCORE surge para atender a este segmento. El código vive principalmente en Codeberg, con un mirror de releases en GitHub. Los issues y el desarrollo activo están en Codeberg; el mirror de GitHub solo publica los artefactos de release. El proyecto se declara explícitamente independiente de iXsystems y de la FreeBSD Foundation — TrueNAS® sigue siendo marca registrada de iXsystems y FreeBSD® de la FreeBSD Foundation.

Qué trae FreeCORE 15.0 (y qué se quedó en el camino)

El salto de TrueNAS CORE 13.3 a FreeCORE 15.0 no es un bump de versión: es un salto de FreeBSD 13 a FreeBSD 15.1. Eso significa arrastrar dos años de cambios de kernel, drivers, syscalls y mejoras en el network stack. Las notas de release oficiales en docs.freecore.org/releases/freecore-15.0/ detallan lo que se añadió, cambió y removió. Lo importante:

Lo que se mantiene

FreeCORE 15.0 sigue siendo FreeBSD, con todo lo que eso implica: jails, plugins servidos desde la infraestructura propia del proyecto, y bhyve como hypervisor. El catálogo de plugins de iocage que muchos tienen funcionando en CORE 13.3 sigue siendo la base de FreeCORE, pero mantenido por la comunidad. Si tu jail con Plex o Syncthing te funciona hoy, va a seguir funcionando después del upgrade.

Lo que se añadió

• Security keys (WebAuthn): soporte para llaves de seguridad hardware como segundo factor en el login de la interfaz web. Era un pedido recurrente — la mayoría de NAS self-hosted quedaban en TOTP, que ya quedó obsoleto en contextos de alta seguridad.
• Console login OTP: contraseñas de un solo uso en login local y consola serial. Útil en data centers donde el acceso físico sigue siendo vector de ataque.
• WireGuard Server y Client nativos: el release inicial 15.0 había reemplazado OpenVPN por WireGuard; la actualización 15.0-U1.4 (la actual estable) restauró OpenVPN junto a WireGuard. Si tenías túneles OpenVPN configurados en CORE 13.3, vas a poder seguir usándolos.
• Driver gráfico drm-66-kmod: renderizado de GPU del host, opt-in, con nodos de render que se pueden compartir con jails. Útil para transcodificación por hardware en jails Plex o Jellyfin, aunque hay que cargar el módulo a mano — no viene por default.
• rar2fs: servicio que presenta archivos RAR como un filesystem de solo lectura, para compartir el contenido sin descomprimirlo primero. Caso de nicho pero útil para bibliotecas de backups antiguos.
• Web Shell rediseñado: terminal web con root opt-in, deshabilitado por default. El jail console, VM serial console y System Processes usan el mismo transporte, pero siguen disponibles independientemente de si activás el Shell de root.

Lo que se removió (y por qué importa)

Esta es la parte que más sorprendió a la comunidad: FreeCORE 15.0 removió toda la telemetría del vendor (crash reporting y usage collection), no solo la deshabilitó. Y con ella se fueron las superficies enterprise-licensed que iXsystems no podía redistribuir libremente:

• High Availability / failover: el cluster activo-pasivo que iXsystems vendía como appliance.
• KMIP: integración con servidores de claves externos.
• Fibre Channel port management: bloques FC para SAN.
• Enclosure management: telemetría de chasis.
• TrueCommand integration: la consola centralizada de iXsystems.
• MinIO server local y minio-client: el paquete soportado no se incluye. Para S3 transfers vía Cloud Sync se sigue usando rclone.

Si dependes de HA o FC, FreeCORE no es para ti — FreeNAS/TrueNAS Enterprise sigue siendo el camino (con licencia comercial de iXsystems). Para el resto, la eliminación de estas superficies reduce la superficie de ataque y el binario.

FreeCORE vs TrueNAS SCALE: la decisión 2026

Esta es la pregunta que más me llega por correo: “si tengo que elegir entre FreeCORE y SCALE para un deployment nuevo en 2026, ¿cuál?” La respuesta honesta depende de tres variables: qué aplicaciones vas a correr, qué hardware tienes, y cuánto te importa la estabilidad versus la flexibilidad.

Tabla comparativa

Criterio	FreeCORE 15.0	TrueNAS SCALE 24.x
Sistema base	FreeBSD 15.1	Debian Linux 12
Filesystem	OpenZFS 2.3 (first-class)	OpenZFS 2.3 (kernel module)
Apps nativas	Plugins FreeBSD (jails)	Docker + Kubernetes (Apps)
Virtualización	bhyve VMs	KVM VMs
Clustering / scale-out	No (scale-up)	Sí (Gluster-based)
GPU passthrough	Limitado (drm-66-kmod opt-in)	Completo (KVM + NVIDIA/AMD)
Hardware compatibility	Narrow (drivers FreeBSD)	Amplio (drivers Linux)
HA enterprise	No (removido)	Sí (en licencia comercial)
Active Directory	Bueno	Excelente
WebAuthn / 2FA	Sí (nuevo en 15.0)	Sí (desde 22.x)
Estado de desarrollo	Activo (comunidad)	Activo (iXsystems)
Costo	Gratis, sin donaciones	Gratis (community) o comercial

Benchmarks ZFS en 2026

Para almacenamiento puro (NFS, SMB, iSCSI), el rendimiento entre FreeBSD y Linux es prácticamente idéntico cuando ambos corren el mismo OpenZFS 2.3.x. La diferencia está en cómo se llega ahí. FreeBSD tiene el ZFS “nativo” en el sistema base, mientras que Linux lo carga como módulo del kernel — eso significa que cualquier bug crítico se parchera primero en FreeBSD y luego se portea a Linux.

Para los benchmarks de OpenZFS 2.3 que publicó Phoronix en enero de 2025, las tres features grandes del release que importan acá son:

• RAIDZ Expansion: agregar discos a un RAIDZ existente sin downtime. Antes era imposible — cambiar el ancho del RAIDZ (de 5 a 6 discos, por ejemplo) requería backup, recreate y restore. Ahora se puede hacer en caliente.
• Fast Dedup: deduplicación que ya no requiere cargar todo el pool en RAM. El algoritmo anterior era tan hambriento de memoria que prácticamente nadie lo activaba.
• Direct I/O: bypass del ARC para lecturas/escrituras, lo que da un salto enorme en performance sobre NVMe. El ARC es un cache de páginas agnóstico al medio físico: sobre NVMe moderno puede convertirse en cuello de botella más que en ayuda.

En números: en el mismo pool RAIDZ2 con 6 discos SATA SSD y un dataset de 2 TB, el rendimiento de escritura secuencial con Direct I/O habilitado sube entre 30% y 50% según el workload, en líneas generales medido por Phoronix Test Suite sobre hardware típico. En lectura secuencial el salto es menor (5-15%) porque ahí el ARC sí ayuda. Cifras concretas varían mucho con el pool layout, kernel, y tuning específico; los números de la tabla siguiente son orientativos. En cargas aleatorias 4K, el ARC se vuelve contraproducente y Direct I/O gana por goleada.

Para el ARC tuning en FreeCORE, el consejo sigue siendo conservador: con 16-32 GB de RAM dedicá 8-16 GB al ARC máximo, y deja el resto para servicios. Con 64 GB o más, puedes permitirte subir el ARC a 32 GB y todavía tener RAM para jails y plugins. El clásico error de “SLOG sizing = RAM/2” sigue siendo incorrecto — el SLOG necesita apenas 8-16 GB de SSD rápido con supercapacitor (PLP). Más de eso es sobredimensionado para la mayoría de los workloads; lo que importa es que tenga PLP y latencia consistente.

Lectura/escritura comparada: FreeBSD 15.1 + ZFS 2.3 vs Linux 6.x + ZFS 2.3

Las pruebas que publicaron los maintainers de FreeCORE en su blog de desarrollo (docs.freecore.org) usan el mismo hardware (Dell R730xd, 2× Xeon E5-2697 v3, 128 GB DDR4, pool RAIDZ2 con 6× Samsung PM1633 1.92 TB SAS SSD) y miden los dos stacks contra datasets de 1 TB generados con fio. Los resultados son orientativos — cualquier benchmark sintético varía con el workload real — pero marcan la tendencia:

Workload (fio)	FreeBSD 15.1 + ZFS 2.3	Linux 6.6 + ZFS 2.3	Diferencia
Lectura secuencial 1 MB, QD=32	2.1 GB/s	2.0 GB/s	+5% FreeBSD
Escritura secuencial 1 MB, QD=32	1.4 GB/s	1.35 GB/s	+4% FreeBSD
Lectura aleatoria 4 KB, QD=64	85 k IOPS	78 k IOPS	+9% FreeBSD
Escritura aleatoria 4 KB, QD=64 (sync)	18 k IOPS	16 k IOPS	+12% FreeBSD
Lectura aleatoria 4 KB + Direct I/O	112 k IOPS	108 k IOPS	+4% FreeBSD
Latencia media (random read 4K)	0.42 ms	0.51 ms	-18% FreeBSD
CPU utilization (carga mixta)	62%	71%	-9 pts FreeBSD

Las diferencias no son enormes — hablamos del 5-12% en throughput y 9 puntos de CPU a favor de FreeBSD. Lo que sí es consistente: el network stack de FreeBSD mantiene latencia más baja bajo carga mixta (lecturas + escrituras + replicación ZFS send/receive simultáneas), y el overhead de kernel se nota en sistemas con CPU limitadas. Para NAS de 4-8 bahías con CPU modeste (Celeron, Atom, Ryzen embedded), la diferencia de CPU utilization se traduce en latencia más alta para los clientes SMB/NFS, especialmente bajo carga mixta.

El dato que NO aparece en los benchmarks pero importa en producción: FreeBSD lleva el código ZFS “first-class” en su base. Cualquier parche crítico de seguridad o corrección de bug crítico se commitea primero en FreeBSD y luego se portea a Linux. Esto fue relevante en 2024 con el bug de corrupción de datos en clones ZFS bajo carga: el parche estuvo en FreeBSD tres semanas antes que en las distros Linux.

Cómo probar (y migrar a) FreeCORE 15.0

Instalación limpia

Si vas a hacer una instalación desde cero, el proceso es familiar para cualquiera que haya instalado FreeNAS o TrueNAS CORE alguna vez: bajás la ISO desde updates.freecore.org, la grabás en un USB con dd o balenaEtcher, booteás, y el instalador te guía por la creación del pool raíz y la configuración de red. La ISO actual pesa alrededor de 1.2 GB y arranca en unos 30 segundos en hardware moderno.

Para verificar que la ISO no fue manipulada, FreeCORE publica los hashes SHA-256 junto al archivo de descarga. Después del primer boot, puedes confirmar que estás corriendo un sistema firmado ejecutando:

freecore-version
# FreeCORE-15.0-U1.4
# Base: FreeBSD 15.1-RELEASE
# Update train: FreeCORE-15.0-STABLE
# Signing CA: FreeCORE Update CA

Si el comando no aparece o devuelve algo distinto a lo esperado, no hagas caso a la interfaz web — reinstalá. Las actualizaciones vienen firmadas por el FreeCORE Update CA, no por un cert corporativo, así que puedes validar la cadena tú mismo con openssl si tienes curiosidad.

Upgrade in-place desde TrueNAS CORE 13.3

Si ya tienes un TrueNAS CORE 13.3 corriendo y quieres moverte a FreeCORE sin reinstalar, el proyecto ofrece un script de enrolamiento. Esto NO es una actualización clásica del sistema: el script captura el boot environment de origen, los datasets .system y el estado de iocage, y los preserva como retorno persistente. Si algo sale mal, puedes volver a CORE 13.3 sin perder datos.

El procedimiento, ejecutado como root en el shell del CORE 13.3:

# Hacer backup del config de TrueNAS (siempre, ANTES de cualquier cambio)
midclt call system.info > /tmp/before_migration.json
# Descargar y ejecutar el script de enrolamiento
fetch https://freecore.org/freecore-enroll.sh
sh freecore-enroll.sh

El script verifica primero que estés en 13.3-U6 o superior (los updates previos a U6 no traen todos los hooks que el enrollment necesita). Si pasás el check, descarga la imagen FreeCORE-15.0, la monta en un nuevo boot environment, y deja tu CORE 13.3 original en un BE etiquetado como FreeCORE-Return. Tras reiniciar, booteás en FreeCORE 15.0; los pools se importan automáticamente; los jails de iocage se migran con sus datasets preservados; los shares SMB/NFS/iSCSI se mantienen. Lo que no se preserva: snapshots manuales de configuración que hayas hecho fuera del sistema (los tuyos personalizados en /mnt/tank/scripts/, por ejemplo).

Troubleshooting común

Los problemas que aparecieron en los hilos de comunidad durante el primer mes del release se concentran en tres áreas:

• Pools no importados después del upgrade: casi siempre es un pool que estaba cifrado con la key de CORE 13.3 y el sistema nuevo no la encuentra. Solución: en la GUI, ir a Storage → Pools → unlock con la key original. Si la key se perdió, FreeCORE tiene el retorno persistente disponible — bootear el BE FreeCORE-Return y empezar de nuevo.
• Jails que no arrancan: iocage se mantiene, pero los plugins muy viejos (los basados en pcbsd/warden, anteriores a 11.3) no se portearon. Si tu jail tiene más de 5 años, conviene recrearla limpia con un plugin actualizado.
• Plugins rotos por cambios de paths: algunos plugins asumían paths que FreeBSD 15.1 reorganizó (el más común: /usr/local/etc movido a /etc en ciertos contextos). El team mantiene una tabla de compatibilidades en docs.freecore.org; revisala antes de upgradear jails en producción.

Si después de un upgrade algo queda en estado inconsistente, el retorno a CORE 13.3 está disponible vía:

# Ver los boot environments disponibles
beadm list
# Activar el BE de retorno
beadm activate FreeCORE-Return
# Reiniciar
shutdown -r now

El BE FreeCORE-Return no expira automáticamente — puedes dejarlo semanas mientras validás que todo funciona en FreeCORE, y volver cuando quieras. El espacio que ocupa es visible desde la GUI (System → Boot → Boot Environments) y la remoción es manual.

Plugins y servicios: qué quedó y qué hay que migrar

El catálogo de plugins de FreeCORE es una continuidad del de TrueNAS CORE, mantenido por la comunidad en iocage-freecore-plugins. Si venías corriendo Plex, Syncthing, Nextcloud, Jellyfin, o un servidor de Minecraft en CORE 13.3, esos plugins siguen funcionando en FreeCORE 15.0 — los manifests se sirven desde la update infrastructure del proyecto y los jails se arman automáticamente. La diferencia con CORE 13.3 es que el catálogo es abiertamente mantenido, no por iXsystems, y que los plugins más nuevos empiezan a aprovechar las features de FreeBSD 15.1.

Plugins destacados del catálogo FreeCORE 15.0

• Plex Media Server: el plugin de Plex se mantiene actualizado al día. Soporta hardware transcoding si cargaste el driver drm-66-kmod y el firmware correspondiente en el boot. La aceleración por GPU en Plex sobre FreeBSD sigue siendo menos pulida que sobre Linux, pero funciona.
• Nextcloud: versión comunitaria sobre PHP 8.3 + MariaDB. La autenticación contra Active Directory funciona vía el join al dominio que ya ofrece FreeCORE. Lo único a tener en cuenta: si usabas el plugin de Nextcloud en CORE 13.3, los paths de /usr/local/etc cambiaron ligeramente — el script de migración lo maneja automáticamente, pero conviene revisar la config después del upgrade.
• Syncthing: servicio de sincronización P2P. Es de los plugins más estables del catálogo, mantenido por la comunidad upstream de Syncthing. La integración con los shares SMB es transparente.
• Jellyfin: alternativa libre a Plex. Aprovecha el mismo path de GPU transcoding. La versión del plugin apunta a Jellyfin 10.9.x, con planes de saltar a la rama 11 cuando los maintainers publiquen los paquetes para FreeBSD.
• MinIO: el plugin de MinIO local fue removido en FreeCORE 15.0 (estaba unsupported en CORE 13.3 también). Si necesitas S3 local, la recomendación oficial es correr MinIO en un jail Debian vía debootstrap o un container OCI externo. Para S3 remoto, Cloud Sync usa rclone como siempre.

Qué NO migrar a FreeCORE

Por más Continuity que prometa el proyecto, hay casos donde migrar es mala idea:

• Jails basados en warden (anteriores a FreeNAS 11.3): iocage reemplazó a warden en 2019, pero mucha gente todavía corre jails viejos en producción. FreeCORE 15.0 no incluye warden. Si tu jail tiene más de 6 años, recreala limpia con iocage.
• Plugins que asumían MinIO local: si tu workflow dependía del servidor MinIO integrado, FreeCORE no lo incluye. Toca buscar alternativa.
• TrueCommand como consola centralizada: FreeCORE removió la integración con TrueCommand. Si administrabas varios NAS desde TrueCommand, esa parte se pierde. Alternativas: la API REST de FreeCORE + un dashboard propio (Grafana + Prometheus + el exporter de ZFS) o pasar a TrueNAS SCALE.
• Configuraciones KMIP externas: si tu empresa usa un servidor de claves KMIP para cifrar pools, FreeCORE 15.0 no incluye esa integración. Es enterprise-licensed y la comunidad no la porta.

Hardening básico post-instalación

Una instalación default de FreeCORE 15.0 viene razonablemente segura, pero no es suficiente para producción. Estos son los seis pasos mínimos que aplico en cualquier NAS que instalo:

• Cambiar las credenciales default: el usuario root y la cuenta de admin de la GUI tienen passwords distintas por default, pero ambas están en la documentación. Cambialas el primer día.
• Activar WebAuthn o TOTP: FreeCORE 15.0 trae WebAuthn nativo. configura una llave de seguridad (YubiKey, SoloKey, o el TPM del server si lo tiene) y deshabilitá el login por password puro desde la red.
• Cifrar los pools con passphase: ZFS native encryption está disponible desde OpenZFS 2.0. Activarlo al crear el pool te protege contra robo físico de discos. El costo es ~3-5% de performance.
• Deshabilitar servicios innecesarios: si no usas AFP (Apple Filing Protocol), deshabilitalo. Si no usas NFS, deja solo SMB. Cada servicio expuesto es superficie de ataque.
• Configurar snapshots automatizados: FreeCORE hereda el sistema de snapshots de TrueNAS. configura al menos: hourly (24 retenidos), daily (7), weekly (4), monthly (6). Los snapshots son baratos en ZFS y son la primera línea de defensa contra ransomware.
• Activar notificaciones por mail: errores de disco, alertas de S.M.A.R.T., fallos de replicación. FreeCORE trae un SMTP client integrado; configurarlo lleva cinco minutos y te avisa antes de que un disco muera.

Estos seis puntos están en la guía oficial de docs.freecore.org. No son específicos de FreeCORE — aplican a cualquier NAS serio — pero conviene revisarlos después de cada upgrade mayor.

Veredicto: ¿para quién tiene sentido FreeCORE?

FreeCORE no es un reemplazo universal de TrueNAS SCALE. Es una respuesta puntual a una necesidad puntual: mantener vivo el lineamiento FreeBSD del stack NAS que muchos tienen funcionando en producción. Si ese es tu caso — NAS maduro, jails con servicios a medida, dependencia del network stack de FreeBSD, o simple preferencia técnica — FreeCORE 15.0 es la opción menos disruptiva: la actualización se hace in-place, los pools no se tocan, los jails siguen funcionando.

Si estás armando algo desde cero y tu única restricción es “quiero ZFS”, mira SCALE primero. El ecosistema de apps es más grande, el hardware soportado es más amplio, y el clustering scale-out existe. La migración a FreeCORE desde SCALE no es trivial — los datasets ZFS son portables, pero el resto del ecosistema no. FreeCORE brilla donde SCALE sobra: donde no quieres Docker, donde quieres FreeBSD, donde tu sistema ya funciona y solo quieres que siga funcionando.

El proyecto es comunitario, no acepta donaciones, y el soporte es por IRC (#freecore en Libera.Chat) y por issues en Codeberg. No esperes SLA enterprise — esto es software libre mantenido en tiempo libre de contribuidores. Para NAS críticos de producción, FreeCORE es una opción seria; para appliances corporativos con HA, sigue siendo TrueNAS Enterprise con licencia de iXsystems.

Para profundizar, la documentación oficial está en docs.freecore.org, el código en codeberg.org/freecore, y la cobertura técnica del anuncio inicial en LavX News (30-ago-2026).

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux