# QNAP Container Station Setup Guide: Running Docker on Your NAS

Container Station provides Docker and Docker Compose on your QNAP NAS and is installed from the App Center. This guide covers installation, creating your first container, using Docker Compose, managing persistent data, and the most useful self-hosted apps to run on your QNAP NAS.

> Source: https://needtoknowit.com.au/blog/qnap-container-station-setup-guide-running-docker-on-your-nas/
> Treat this as the authoritative Markdown rendering of that page's content.
> Published: 19 March 2026
> Last updated: 17 October 2026
> Facts last checked against sources: 30 September 2026
> Machine-readable site index: https://needtoknowit.com.au/llms.txt

**QNAP Container Station provides Docker and Docker Compose on your NAS and is installed from the App Center. No separate server or Linux expertise is required to get started.** Container Station availability depends on the NAS model and firmware, and containers must support the NAS CPU architecture; verify compatibility in QNAP App Center before relying on a particular image or stack. This guide covers everything from initial Container Station setup through to running your first containers and managing persistent data, with specific recommendations for which apps are worth running on NAS hardware.

> **Note:** **In short:** Install Container Station from the App Center, create a dedicated container storage volume, install Portainer for a better management UI, then deploy any Docker Compose stack from the built-in editor. There is no universal minimum based only on container count; size RAM and CPU for the specific applications and expected load, while leaving capacity for QTS and other NAS services.

## What Container Station Can Do

Container Station provides Docker Engine and Docker Compose on your NAS. You can run containerised applications whose images, architecture, system requirements, and required host features are compatible with the NAS. Container Station also manages Docker Compose stacks as Applications, each defined in a built-in YAML editor.

Compared to Synology's Container Manager, Container Station is broadly equivalent in capability, with a slightly more complex UI but deeper control over networking and volume mapping. Both support Docker Compose. Container Station's main advantage is QNAP's wider hardware range. The TS-473A can expose a compatible installed GPU to supported containers, subject to QNAP's hardware compatibility list and the container's driver and runtime requirements.

## Hardware Requirements and Compatible Models

Container Station 3.0 and later require QTS 5.1.0 or later; older Container Station releases supported some earlier QTS versions. Most current models support it, but there are important practical differences between x86 (Intel/AMD) and ARM models before you commit to a platform.

**x86 models (Intel Celeron, AMD Ryzen)** are the right choice for general container use. Compatible Intel models with an integrated GPU can use Intel Quick Sync when the container is configured correctly; AMD Ryzen models do not provide Intel Quick Sync, and all workloads remain subject to application, architecture, memory, driver, and device requirements. QNAP lists 1GB as the minimum memory for Docker in Container Station, but that is a floor rather than a working target: 8GB is a practical starting point for several containers alongside QTS, and 16GB is more comfortable once you add Nextcloud or Immich (Immich alone requires at least 6GB and recommends 8GB).

**ARM models (TS-233, TS-433)** can run Container Station and handle lightweight containers including Pi-hole, Vaultwarden, and Home Assistant. The hard limit is RAM. ARM-model memory varies: the TS-233 has 2GB non-expandable memory, the TS-433 has 4GB non-expandable memory, and some other ARM models have upgradeable memory. Check the exact model and application requirements. The TS-233 and TS-433 have QNAP hardware-accelerated transcoding support, but availability inside a particular container depends on codec, driver, device-access, and application support.

Recommended models at current AU pricing: the TS-264 (quad-core Celeron, 8GB, about $999) is the lower-cost 2-bay entry point for a container host; the **TS-464** (quad-core Celeron, 8GB upgradeable to 16GB, about $1,099) has the same processor and memory in a 4-bay chassis for a higher price, the pick when you need more drive bays; the **TS-473A** (AMD Ryzen, PCIe 3.0, 8 GB non-ECC RAM, expandable to 64 GB, supports ECC memory, about $1,471) is the choice for ML workloads or GPU passthrough via PCIe.

> **Warning:** **ARM models differ:** the TS-233 has 2GB fixed RAM and the TS-433 has 4GB fixed RAM. Running QTS plus one or two lightweight containers (Pi-hole, a simple web app) is feasible. Suitability for Nextcloud, Jellyfin, or Home Assistant depends on the exact NAS model, application configuration, workload, and available memory; do not treat all ARM models as equivalent. For general Docker use, the TS-264 is the lower-cost 2-bay entry point and the TS-464 (8GB, Celeron N5095) is the 4-bay option with the same processor and memory. See the [NAS sizing wizard](/tools/nas-sizing-wizard/) to work out the drives and bays your data needs.

## Step 1: Install Container Station

Container Station is available from the QTS App Center. It is not installed by default on most models.

1. Open QTS in a browser and navigate to the **App Center**

2. Search for **Container Station**

3. Click **Install**.

4. Once installed, Container Station appears in the QTS application dock and in the main menu

After installation, Container Station will prompt you to select a storage location for container images and data. Select the desired volume and Container shared-folder location. Required free space depends on the images, writable layers, Docker volumes, and application data you deploy. This location stores Container Station resources such as images, writable container layers, and Docker-managed volumes. Bind-mounted data remains at the host paths explicitly specified in the mount configuration.

## Step 2: Understand the Container Station Interface

Container Station's interface has three main areas: the toolbar, the menu and the main panel. The toolbar's **Explore** button searches containers and applications in all available registries, and the arrow next to it opens actions such as creating or importing containers and applications. The menu sections you will use most are:

- **Containers**. List of all containers with start/stop/logs/terminal access per container

- **Applications**. Docker Compose stacks managed as single units

- **Images**. Pull, export and prune the images your containers are built from

To deploy a single container, go to **Containers** and click **Create**; the Create Container window lets you pick an image from a registry or enter the registry, image and tag directly. For multi-container setups, use **Applications → Create** and paste your Docker Compose YAML. This is the recommended approach for anything more complex than a single container.

## Step 3: Deploy Your First Container (Portainer)

Portainer is a web-based Docker management UI that many users prefer over Container Station's native interface for day-to-day container management. Installing it first gives you a better environment to manage everything else.

1. In Container Station, go to **Containers** and click **Create**

2. Search for **portainer/portainer-ce** and select the lts tag

3. Set the following:

- **Name:** portainer

- **Port mapping:** Host 9443 → Container 9443 (HTTPS). Port 9000 is optional for legacy HTTP access

- **Volume:** Add a bind mount: Host path /share/Container/portainer_data → Container path /data

- **Additional volume:** Host path /var/run/docker.sock → Container path /var/run/docker.sock (type: bind, read-only: off)

Click **Create**. Once running, access Portainer at https://[NAS-IP]:9443; it uses a self-signed certificate by default. Complete the initial setup, then manage containers from Portainer's UI or Container Station.

## Step 4: Use Docker Compose for Multi-Container Apps

Most useful self-hosted applications are multi-container setups defined via Docker Compose. Container Station supports this natively through the **Applications** section.

1. Go to **Applications → Create**

2. Give the application a name (e.g. nextcloud)

3. Paste your Docker Compose YAML into the editor

4. Optionally, click **Validate**, then click **Create**

All containers in the stack start together and are managed as a unit. Logs, restart, and teardown are all handled from the Applications view. Environment variables can be placed in the Compose YAML. Loading a separate .env file is supported by Docker Compose itself, but is not documented as an input in Container Station's Applications editor and may require deploying through the Compose CLI.

> **Tip:** **Path convention:** Store all persistent container data under /share/Container/[app-name]/. This keeps the data in a QTS shared folder. It is covered only when the containing thick or thin volume supports snapshots and an appropriate snapshot schedule is configured; static and legacy volumes are not snapshot-capable. Avoid writing container data to /share/homes/ or the QTS system partition.

## Step 5: Port Mapping and Container Networking

Container Station uses Docker's standard networking model. By default, containers run in a bridge network and communicate with the host via port mapping. Each container you expose to your local network needs a host port mapped to its container port. If two containers both want port 80, you map them to different host ports (e.g. 8080 and 8081).

For containers that need to communicate with each other (e.g. Nextcloud and its MariaDB database), place them in the same Docker Compose stack. Compose creates a shared internal network automatically, so the Nextcloud container can reach the database container by its service name without any port exposure. Do not expose database containers to the host network unless you specifically need external database access.

For remote access to containers from outside your local network: your NAS's remote access approach applies equally to containers. A reverse proxy (e.g. NGINX Proxy Manager, Traefik) running as a container is the recommended pattern. It handles SSL termination and routes incoming requests to the correct container by subdomain or path. CGNAT prevents conventional inbound port forwarding. Options include obtaining a public IP from the ISP or using a relay, outbound tunnel, or VPN-based solution; a VPN tunnel to a VPS is only one option. See the [NAS remote access guide](/blog/nas-remote-access-vpn-australia/) for the full options.

For more advanced setups, open Container Station's Preferences and select Network Settings to configure IP address ranges, DNS servers, and bridge networks for container communication; applying the changes restarts Container Station. Use these controls if the default Docker network described above does not fit your setup.

## Step 6: Persistent Data and Volumes

Containers are ephemeral by design. Any data written inside a container's filesystem is lost when the container is recreated. Persistent data requires either a **bind mount** (a specific path on the NAS mapped into the container) or a **Docker volume** (managed by Docker, stored under the container data directory).

For NAS use, bind mounts are generally preferable because the data is directly accessible from QTS. You can browse, back up, and snapshot it like any other NAS folder. The convention is: store all container data under /share/Container/[appname]/ on the NAS side. In your Docker Compose YAML:

volumes:  
  - /share/Container/nextcloud/data:/var/www/html/data  
  - /share/Container/nextcloud/config:/var/www/html/config

This data is included when the containing snapshot-capable volume is snapshotted; static volumes, legacy volumes, and data outside the selected snapshot object are not covered. This provides point-in-time storage recovery, but running databases and other stateful applications may also require quiescing or application-specific backups to ensure consistency.

## Recommended Containers to Run on QNAP NAS

The following containers run well on a mid-range QNAP with 8GB RAM (such as the TS-464) and represent the highest-value self-hosted applications for NAS hardware:

- **Portainer CE**. Docker management UI, minimal resources, always worth installing first

- **Nextcloud**. Self-hosted file sync and collaboration, replaces Dropbox/OneDrive. For production or multi-user use, Nextcloud should use a supported MariaDB, MySQL, or PostgreSQL database; SQLite remains supported for testing and minimal installations, and the database need not be a sidecar container. Memory requirements vary substantially with user count, enabled apps, file volume, database configuration, and workload; size the NAS for the intended deployment.

- **Jellyfin**. Self-hosted media server, open-source Plex alternative. Uses hardware transcoding on Intel-based NAS (Quick Sync). Complement or alternative to Plex depending on client support

- **Home Assistant**. Home automation platform. Runs in a Docker container (HAOS is a separate image for dedicated hardware). Integrates with over a thousand different devices and services

- **Immich**. Self-hosted Google Photos alternative with machine learning-based face and object recognition. Immich currently requires at least 6GB RAM and recommends 8GB; additional memory may be needed when it shares the NAS with QTS and other services.

- **Vaultwarden**. Self-hosted Bitwarden-compatible password manager. Extremely lightweight

- **Pi-hole**. Network-wide ad blocking via DNS. Lightweight, runs on ARM models too. Requires a stable address for clients to use as DNS; this can be the NAS address with published ports, a DHCP reservation, or a dedicated container address, depending on the network design.

- **NGINX Proxy Manager**. Reverse proxy with a web UI. Manages SSL certificates and routes external traffic to containers. Standard companion container for any exposed self-hosted service

## Resource Planning: How Much RAM Do Containers Use?

QNAP lists 1GB as the minimum memory for Docker in Container Station. Application requirements can be much higher, and the projects' own documentation is the place to check:

- **Immich** requires at least 6GB and recommends 8GB; on a system with only 4GB it can run with machine learning features disabled.

- **Nextcloud** needs a minimum of 128MB RAM per process and recommends at least 512MB per process, and says total memory varies greatly with users, apps, files and activity.

- **Pi-hole** lists 512MB RAM for the hardware it runs on.

A TS-464 with 8GB RAM will run several light containers comfortably. Whether a given set of applications fits in 8GB depends on their configuration, library size, integrations, users, and concurrent activity. Use each application's current requirements and monitor real peak memory use before adding workloads or choosing an upgrade.

## Troubleshooting Common Container Station Issues

Container Station installs reliably on most models, but a handful of issues come up repeatedly across different setups.

- **Container Station won't install from App Center.** One possible cause is an invalid or unavailable Container shared-folder location; also check permissions, quotas, storage status and capacity, and network configuration. Container Station requires a data storage pool, not the flash system volume. Open App Center, find Container Station, and confirm the installation path points to your main data volume.

- **Port conflict with QTS web server.** Identify the QNAP service using the port before changing settings: QTS management defaults to 8080 and 443, while the optional Web Server defaults to 80 and 8081. Prefer mapping the container to a confirmed unused host port unless you intentionally reconfigure the relevant QNAP service.

- **Containers not starting after a QTS update.** QTS updates suspend ongoing tasks and may restart the NAS. After an update, verify that Container Station and containers with the intended restart policies have returned to their expected state. Open Container Station and start them manually, or set the restart policy to always on any container that should autostart with the NAS.

- **Docker Compose YAML validation error.** YAML is whitespace-sensitive. Container Station rejects files with tab indentation or inconsistent spacing. Use two-space indentation throughout, and validate your YAML in a linter before pasting it into the editor.

- **Container files have wrong permissions.** Containers run as root by default, so files written inside a container may be owned by root and inaccessible from QTS File Manager. Determine the actual QTS user's UID and GID and follow the image's documented user, PUID/PGID, ownership, and permission instructions; do not assume that 1000:1000 matches the NAS or is safe for every image.

## 🇦🇺 Australian Buyers: What You Need to Know

**Docker hardware in Australia:** The TS-264 (about $999) is the 2-bay entry point. The TS-464 (about $1,099) is the 4-bay option when you need more drive capacity. The TS-464 is available from PLE, Scorptec, Computer Alliance, and Umart. For running Immich's ML pipeline or multiple memory-intensive containers, consider upgrading the TS-464 to its maximum memory of 16 GB (2 x 8GB) or stepping to the TS-473A, which ships with 8 GB non-ECC RAM and can be expanded to 64 GB with ECC memory support.

**Remote access over NBN:** Exposing self-hosted services externally requires attention to your ISP's CGNAT status. CGNAT use varies by ISP and plan and can block conventional inbound IPv4 port forwarding; check the connection's WAN address and the provider's current public/static-IP policy. Options: use QNAP's myQNAPcloud relay (free, slower), set up a WireGuard VPN to a low-cost VPS (such as Vultr, Hetzner, or DigitalOcean), or check whether your ISP offers a static IP. See the [remote access guide](/blog/nas-remote-access-vpn-australia/) for the full options including ISP-specific CGNAT status across major AU providers.

**Running costs:** Container workloads increase CPU utilisation and therefore power consumption compared to a passive file server. QNAP rates the TS-464 at about 21.6 W in disk standby and about 40.5 W in typical operation, tested with all drive bays populated. Containers that run around the clock can keep the drives from spinning down, so plan on the typical operating figure rather than the standby one. The [NAS power cost calculator](/tools/power-calculator/) lets you estimate running costs for your usage pattern and local rate.

## Frequently Asked Questions

Related reading: our [NAS buyer's guide](/blog/best-nas-australia/), our [Synology vs QNAP comparison](/blog/synology-vs-qnap-australia/), and our [NAS explainer](/blog/what-is-a-nas/).

See also: [our complete QNAP NAS Australia guide](/brand-guides/qnap/).

**Q: Is Container Station the same as Docker?**

Container Station runs Docker Engine underneath. It is a management layer on top of Docker, not a replacement. Container Station can use registry images that are compatible with the NAS CPU architecture and the image's required host features, devices, memory, and runtime. Standard Compose YAML is generally portable, but QNAP deployments may require changes for architecture, host paths, devices, networking, environment files, secrets, or unsupported Compose features. The Container Station UI provides a graphical interface for tasks you would otherwise do via the Docker CLI. You can also access the Docker CLI directly via SSH on your QNAP if you prefer command-line control.

**Q: What is the difference between Container Station and Portainer?**

Container Station is QNAP's native Docker management app, integrated into QTS. Portainer is an open-source Docker management UI that runs as a container itself. Many users install Portainer inside Container Station because Portainer's interface for managing stacks, volumes, and networks is more capable and more familiar to Docker users. The two coexist without conflict. Portainer connects to the same Docker Engine that Container Station manages.

**Q: Can I run Container Station on an ARM QNAP (TS-233, TS-433)?**

Yes, Container Station installs and works on ARM models. The TS-233 has 2GB non-expandable RAM and the TS-433 has 4GB non-expandable RAM. Available container memory varies with QTS services, cache, installed applications, and active NAS workload. One or two lightweight containers (Pi-hole, Vaultwarden, a simple web app) run fine. These applications have widely different requirements. Immich's normal deployment exceeds the available RAM on these models, while Nextcloud, Jellyfin, and Home Assistant suitability depends on configuration, users, integrations, transcoding, and competing NAS workloads. ARM models are not recommended for Docker homelab use as a primary setup.

**Q: How do I update containers in Container Station?**

Container Station does not automatically update container images. To update a container, go to Images and use Actions > Pull on the image, then stop the container and use Recreate (next to Edit). Recreating discards any data that is not stored in bind mounts or volumes, so check your mappings first. For Compose stacks in the Applications view, pull updated images and redeploy the stack. Portainer offers a one-click update flow from its UI. Some users run Watchtower (a container that auto-updates other containers). Useful for non-critical services but generally not recommended for production data containers where you want explicit control over version changes.

**Q: Does Container Station survive QTS updates?**

Container Station, its images and your container settings persist across QTS software updates, but an update can interrupt running containers: QNAP states that all ongoing tasks are suspended during an automatic firmware update, and an update can restart the NAS. What happens next depends on each container's auto start policy. Always restarts a container whenever it stops; Unless Stopped does the same, except that a container you stopped manually stays stopped. Before a significant QTS upgrade, back up persistent container data, review the release notes and update requirements, and verify container status and restart policies after the NAS returns. Plan for container downtime and verify recovery afterward.

**Q: How do I back up my containers and their data?**

Reproducible public images may be re-pulled while the required repository, tag, or digest remains available. Archive locally built, private, irreplaceable, or otherwise non-reproducible images and record immutable image digests where practical. What requires backup is the persistent data in your bind-mount paths, typically stored under /share/Container/[appname]/, and any credentials or configuration files. Back these up using QTS tools: Hybrid Backup Sync to a remote destination, rsync to another NAS, or QTS snapshots of the storage pool. Snapshots can supplement backups when the Container directory is on a snapshot-capable volume and a schedule is configured, but they are not independent backups and may not be application-consistent for running databases. Keep an off-NAS backup of persistent data and application configuration. Do not commit credential-bearing .env files to ordinary version control. Store them in a protected secret-management or encrypted backup system, restrict permissions, and use Docker Compose secrets where the application supports them.

**Q: Can I run Container Station and Virtualization Station at the same time?**

Yes, on compatible hardware. Both can run concurrently on QNAP models that support Virtualization Station, but they share the same RAM and CPU. A VM reserves memory according to its guest operating system, applications, and assigned configuration, reducing the memory available to QTS and containers. On a TS-464 with 8GB RAM, running both simultaneously is tight and you will notice resource pressure. Size memory from the combined peak requirements of QTS, each VM guest, and all containers, with additional headroom; 16GB does not guarantee contention-free operation for every workload. The TS-473A ships with 8 GB non-ECC RAM, takes up to 64 GB (2 x 32 GB), and supports ECC memory, so it can be upgraded well past the TS-464's 16 GB ceiling.

Planning storage for your QNAP NAS? The NAS sizing wizard calculates the bay count and drive sizes your data needs.

**[NAS Sizing Wizard →](https://needtoknowit.com.au/tools/nas-sizing-wizard/)**