TrueNAS Apps vs Docker on TrueNAS Scale

TrueNAS Finally Stopped Pretending Kubernetes Was Easy

TrueNAS Apps wins for anything in the catalog with standard networking, and raw Docker Compose wins the moment you need GPU passthrough, custom networking, or an app that isn’t in the catalog.

If you’ve been running TrueNAS Scale since the early days, you remember the pain. iXsystems spent years bolting K3s (Kubernetes) onto a storage appliance and calling it a feature. Your storage cluster became a Kubernetes cluster. Your ZFS pools became Kubernetes volumes. Everything was suffocating under YAML, custom resource definitions (CRDs), and the kind of networking complexity that makes you question your life choices at 2 AM.

Late 2024 changed that. TrueNAS Scale pivoted hard: rip out Kubernetes, go native Docker, lean into what makes TrueNAS actually special: ZFS snapshots, dataset granularity, storage-aware app lifecycle. The Apps catalog still exists, but now it’s backed by Docker Compose, not K8s operators. And you can finally install custom apps without learning Helm.

This shift matters because it changes the entire mental model. You’re not running a Kubernetes cluster that happens to have storage. You’re running a storage appliance that can containerize workloads and integrate them with your datasets. Two very different things.

Should You Use TrueNAS Apps Or Raw Docker Compose?

The K3s Era (and Why It Sucked)

For context: TrueNAS Scale shipped with K3s in 2021. The idea made sense on paper: lightweight Kubernetes, container orchestration, enterprise credibility. In practice, it was a forklift to move a couch.

K3s introduced:

• iX-charts: A custom Helm repo for “TrueNAS-optimized” apps. They weren’t. They were Helm charts with hardcoded assumptions and zero flexibility.
• Limited storage integration: ZFS datasets could be mounted as Kubernetes persistent volumes, but the mapping was opaque and divorced from your actual storage strategy.
• No custom apps: If you wanted to run something not in the catalog, such as your Compose stack, your weird database, or your one-off service, you had to SSH in and run Docker directly (which undermined the whole point).
• Upgrade chaos: K3s version bumps broke apps. Apps broke K3s. The entire system felt fragile.

By 2024, even iXsystems had to admit it: K3s wasn’t the answer for a storage appliance. People wanted simplicity, ZFS integration, and the ability to run whatever Docker image they threw at it.

The Docker Pivot (Electric Eel / Fangtooth)

Starting with Electric Eel (24.10, late 2024) and solidified in Fangtooth (25.04, April 2025), TrueNAS Scale ripped out K3s and went all-in on Docker. This is a major architectural shift, and honestly, it’s the right call. Fangtooth also merged the SCALE and CORE editions into one Community Edition (people still call it “TrueNAS Scale” out of habit), and the Docker-based Apps architecture carries forward into Goldeye (25.10), the current release as of September 2026.

Now the story is cleaner:

• TrueNAS Apps are curated Docker Compose stacks, packaged as catalogs.
• You can still SSH in and run raw Docker/Compose, no hand-wringing about “am I breaking the TrueNAS cluster?”
• Datasets can be mounted directly into container volumes with first-class ZFS snapshot integration.
• Custom apps are just Compose files. No Helm. No CRDs. No operators.

The apps UI still exists, still looks pretty, still gives you one-click installs. But underneath, it’s Docker. If you need to tweak something, you SSH in, edit the Compose file, and docker compose up. The boundary between “TrueNAS Apps” and “my Docker Compose” has become delightfully blurry.

TrueNAS Apps: What They Are Now

TrueNAS Apps today is a UI layer on top of Docker Compose. When you click “Install Nextcloud” in the web console, here’s what happens under the hood:

1. A Compose file is generated from the app definition (or fetched from a catalog).
2. Datasets are created to match the app’s storage needs.
3. docker compose up runs.
4. The UI watches the container and reports status.

Benefits of using the Apps UI:

• One-click installs: Pick an app, click “Install”, configure a few fields (admin user, storage path, port), done.
• ZFS snapshot integration: Apps tied to specific datasets. The UI can snapshot the dataset, restore it, migrate it.
• Catalog browsing: Curated, tested stacks (Nextcloud, Jellyfin, Immich, Qbittorrent, etc.). Someone else did the Compose work.
• App updates through the UI: Click “Update”, choose a new image tag, watch the container rebuild.
• Easy uninstall: Removes the app, optionally the dataset.

This is useful for home labs. You’re not hunting down scattered Docker images on GitHub or figuring out which flags -e ADMIN_USER= actually controls.

But it’s still just Docker underneath. You can SSH in, run docker ps, edit /var/lib/docker/volumes/*/docker-compose.yml, whatever. The Apps UI is a convenience layer, not a cage.

When to Bail: Raw Docker on TrueNAS

The Apps catalog is great for standard workloads. But reach for raw Docker/Compose when:

1. You need custom networking Catalog apps run in a default bridge network. The Apps UI’s Custom App screen exposes a Host Network option (Network Configuration section) if a container just needs to bind directly to the host, no Compose required. But macvlan (passing containers onto your home network as separate IPs) or cross-container networking with specific DNS still means writing your own Compose file.

2. You’re wiring up a multi-container stack Say you’re running Home Assistant with PostgreSQL, an MQTT broker, and a custom data processor. The Apps catalog has Home Assistant and Mosquitto individually, but composing them together with custom environment variables, depends_on, and shared networks, that’s a Compose file.

3. Advanced container labels or runtime options Seccomp profiles, resource limits (CPU shares, memory swaps), privileged mode, device passthrough beyond a single GPU. These are Docker run flags or Compose overrides. Apps UI doesn’t expose them all.

4. The app isn’t in the catalog Obvious, but: if you want to run Ollama, vLLM, an Ansible playbook runner, a reverse proxy with custom Lua scripting, SSH in and bring your own Compose.

5. You’re testing or iterating Writing a Compose file, tweaking it, breaking it, rebuilding it, you don’t want the Apps UI getting in your way. Raw Docker lets you docker compose down && docker compose up in seconds.

Datasets vs. Docker Volumes: The ZFS Angle

Here’s where TrueNAS Apps actually shine over stock Docker: ZFS-aware storage.

In raw Docker on Linux, volumes are usually just mount points. On TrueNAS with Apps, you can bind volumes to ZFS datasets, which means:

• Snapshots: Right-click a dataset, snapshot it. Now you can restore an app’s data to that point in time without messing with backups.
• Dataset-level policies: Compression, deduplication, quota enforcement, all inherited by the container.
• Visibility: zfs list shows datasets tied to apps. du -h /var/lib/docker/... doesn’t.

For a TrueNAS App (through the UI), it looks like:

# TrueNAS Apps generates this for you
services:
  nextcloud:
    image: nextcloud:34
    volumes:
      # Apps binds the container path to a dataset host path
      - /mnt/tank/apps/nextcloud/data:/var/www/html/data

When you do this via raw Compose on TrueNAS, you can be even more explicit:

# Raw Compose on TrueNAS Scale
services:
  nextcloud:
    image: nextcloud:34
    volumes:
      - /mnt/tank/apps/nextcloud/data:/var/www/html/data
      - /mnt/tank/apps/nextcloud/config:/var/www/html/config
    environment:
      MYSQL_HOST: mariadb
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: xxx
    networks:
      - nextcloud-net
    depends_on:
      - mariadb

  mariadb:
    image: mariadb:11
    volumes:
      - /mnt/tank/apps/nextcloud/db:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: xxx
      MYSQL_DATABASE: nextcloud
    networks:
      - nextcloud-net

networks:
  nextcloud-net:
    driver: bridge

The key difference: host paths instead of named volumes. This ties your app data directly to ZFS datasets. You can snapshot /mnt/tank/apps/nextcloud/data independently. You can set ZFS quotas. You can enable compression per-dataset. You’re leveraging TrueNAS’s storage superpower instead of treating it like a generic Docker host.

Best practice: create a dataset per app (or per app-component), use host paths in Compose, and let ZFS do the heavy lifting.

# Set up a dataset for Nextcloud data with compression
zfs create -p -o compression=lz4 tank/apps/nextcloud/data
zfs create -p -o compression=off tank/apps/nextcloud/db  # or lz4, depending on workload

Then in Compose:

volumes:
  - /mnt/tank/apps/nextcloud/data:/var/www/html/data
  - /mnt/tank/apps/nextcloud/db:/var/lib/mysql

And take snapshots through the TrueNAS UI or CLI:

zfs snapshot tank/apps/nextcloud/data@before-upgrade
# ... upgrade happens ...
zfs rollback tank/apps/nextcloud/data@before-upgrade  # if it breaks

Upgrades, GPU Passthrough, and Other Realities

App upgrades through the UI: New image tag, click “Update”, container gets recreated with the new image, old volume persists. Straightforward. Just ensure the new version is backwards-compatible with your data.

GPU passthrough: The Apps UI handles the common case natively now. Every app install, catalog or custom, has a GPU Configuration option under Resources Configuration: pick non-NVIDIA passthrough, or select a detected NVIDIA device, no Compose editing needed. The catch: plenty of users report the NVIDIA option showing up empty even with a card installed and drivers loaded (check nvidia-smi on the host first, then the TrueNAS community forums if it still won’t show). When the picker doesn’t cooperate, or you need finer control than a single dropdown gives you (multiple GPUs split across containers, custom NVIDIA_VISIBLE_DEVICES values), drop to raw Compose:

1. Install NVIDIA container runtime on TrueNAS (nvidia-container-toolkit).
2. Write your own Compose:

  services:
    ollama:
      image: ollama/ollama
      runtime: nvidia
      environment:
        NVIDIA_VISIBLE_DEVICES: all
      volumes:
        - /mnt/tank/apps/ollama/models:/root/.ollama

3. SSH in and docker compose up.

Upgrades with raw Compose: You own the versioning. Update the image: tag in your Compose file, docker compose down && docker compose up -d, done. No UI, no wizards. Downside: you’re responsible for testing compatibility. Upside: you know exactly what changed.

When the Catalog Wins

For most self-hosted apps, the TrueNAS Apps catalog is the right choice.

Use TrueNAS Apps when:

• The app is in the catalog (Nextcloud, Jellyfin, Immich, Plex, Home Assistant, Sonarr, Radarr, qBittorrent, Prowlarr, etc.).
• You don’t need exotic networking or GPU passthrough.
• You want the UI to manage the lifecycle: updates, snapshots, uninstall.
• Your stack is app-per-container (not a complex multi-container orchestra).
• You want ZFS snapshots of app data without manual docker inspect archaeology.

The catalog covers ~95% of self-hosting use cases. Nextcloud with MariaDB? There’s an app for that (or you install them separately and link them). Home Assistant with add-ons? App. Jellyfin? App. Immich? App.

For the remaining 5%, such as custom stacks, weird infrastructure, experimental services, or GPU workloads, SSH in and use raw Docker. You’re not abandoning TrueNAS. You’re just treating it as what it actually is: a storage appliance that can run containers, not a Kubernetes distro.

The Lesson

TrueNAS Scale’s pivot from Kubernetes to Docker is the industry’s latest reminder that over-engineering is seductive but wrong. K3s was impressive. It had operators, CRDs, auto-scaling. It also made simple things hard and hard things impossible.

Docker is simpler. Less powerful. But on a storage appliance, simple is the point. You want to install an app, bind it to your storage, snapshot it, move on. You don’t want to debug YAML templating at 2 AM because a CRD schema validation rule broke your deployment.

TrueNAS Apps handles 95% of use cases with a UI. Raw Docker handles the other 5% without friction. And ZFS datasets sit underneath it all, snapshotting and deduplicating regardless of what container layer you’re using.

If you’ve been avoiding TrueNAS Scale because of the Kubernetes days, now’s the time to revisit. It’s a storage appliance again.

Related Reading

• TrueNAS vs OpenMediaVault vs Unraid
• How to install NextCloud via Docker
• Appwrite Backend-as-a-service (BaaS)
• The *arr Stack Without 9000 Reddit Threads
• Automatic Backup of Docker MySQL or MariaDB Containers