QNAP Container Station is a first-class Docker and Docker Compose environment built directly into QTS. No separate server, no Linux expertise 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.
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. The full self-hosted catalogue. Container Station also supports Docker Compose stacks via a built-in YAML editor, and in recent versions of QTS (5.x) includes a stack management view for multi-container applications.
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. Minimum 8GB RAM for running several containers alongside QTS; 16GB is more comfortable once you add Nextcloud or Immich.
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, around $999) is the entry point for a functional container host; the TS-464 (quad-core Celeron, 8GB upgradeable to 16GB, around $1,049) is the best value all-round Docker NAS given the small price gap; the TS-473A (AMD Ryzen, PCIe 3.0, up to 64GB ECC RAM, from $1,269) is the choice for ML workloads or GPU passthrough via PCIe.
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. The TS-464 (8GB, Celeron N5095) is the recommended minimum for real Docker use. See the NAS sizing wizard to check whether your planned workload fits your hardware.
Step 1: Install Container Station
Container Station is available from the QTS App Center. It is not installed by default on most models.
- Open QTS in a browser and navigate to the App Center
- Search for Container Station
- Click Install.
- 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 main interface has three key sections:
- Overview. Running containers, resource utilisation, quick status
- Containers. List of all containers with start/stop/logs/terminal access per container
- Applications. Docker Compose stacks managed as single units
The Create button in the top right opens a wizard for deploying containers either from Docker Hub search or by entering an image name 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.
- In Container Station, click Create Container
- Search for portainer/portainer-ce and select the latest tag
- Set the following:
- Name: portainer
- Port mapping: Host 9000 → Container 9000 (HTTP), Host 9443 → Container 9443 (HTTPS)
- 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 http://[NAS-IP]:9000 and complete the initial setup. You can now manage all containers from Portainer's UI in addition to 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.
- Go to Applications → Create
- Give the application a name (e.g.
nextcloud) - Paste your Docker Compose YAML into the editor
- Click Validate YAML, then 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.
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 for the full options.
For more advanced setups, QNAP's Network & Virtual Switch (vSwitch) feature (in QTS App Center, separate from Container Station itself) gives finer control over container networking than the Docker default: bridged mode for direct LAN access, an isolated mode with its own DHCP for sandboxing, or external mode to dedicate a physical Ethernet port to a container for full bandwidth. Worth exploring if the default Docker network described above doesn't 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 thousands of smart home devices
- 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, runs happily on 256MB RAM
- 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?
Rough steady-state RAM consumption for common containers (actual usage varies with load):
A TS-464 with 8GB RAM. Whether these applications fit 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
Minimum hardware for Docker in Australia: The TS-464 (listed at $999 by Scorptec at the time of audit) is the most cost-effective QNAP for Docker homelab use. Available from PLE, Scorptec, Computer Alliance, Mwave, and Umart. For running Immich's ML pipeline or multiple memory-intensive containers, consider upgrading to 16GB RAM (compatible SO-DIMM DDR4 available from AU retailers for $50-$80) or stepping to the TS-473A for larger memory headroom.
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 cheap VPS (Vultr, Hetzner, DigitalOcean. From ~$5-$7 AUD/month), or check whether your ISP offers a static IP. See the remote access guide 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. A TS-464 running several active containers may draw 30-45W instead of its typical idle ~20W. At NSW electricity rates (~$0.30/kWh), this adds roughly $25-$55 to annual running costs. Manageable for a homelab, but worth factoring in. The NAS power cost calculator lets you estimate this precisely for your usage pattern and local rate.
Related reading: our NAS buyer's guide, our Synology vs QNAP comparison, and our NAS explainer.
See also: our complete QNAP NAS Australia guide.
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.
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.
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.
How do I update containers in Container Station?
Container Station does not automatically update container images. To update a container: pull the latest image (Containers → select container → pull latest), then recreate the container with the same settings. 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.
Does Container Station survive QTS updates?
Container Station and its containers persist across QTS software updates. The Docker Engine, running containers, and stored images are not affected by QTS version upgrades in normal circumstances. 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. QTS updates suspend ongoing tasks and may restart the NAS, including during updates within a major release; plan for container downtime and verify recovery afterward.
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.
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. On the TS-473A with up to 64GB ECC RAM, running both workloads simultaneously is comfortable.
Planning which QNAP model can handle your container workload? The NAS sizing wizard calculates recommended bay count, storage capacity, and RAM based on your use case. Including Docker and homelab workloads.