QNAP Container Station Setup Guide: Running Docker on Your NAS

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. It runs on every Intel Celeron and Ryzen QNAP NAS from the TS-264 upward, and supports the full Docker ecosystem including Docker Compose, Portainer, and custom stacks. 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.

What Container Station Can Do

Container Station provides Docker Engine and Docker Compose on your NAS. This means you can run any containerised application from Docker Hub or any container registry: Nextcloud, Jellyfin, Home Assistant, Vaultwarden, Portainer, Pi-hole, Immich, Gitea, Grafana. 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. PCIe-equipped models like the TS-473A allow GPU passthrough for AI inference containers.

Hardware Requirements and Compatible Models

Container Station requires a QNAP NAS running QTS 5.0 or later. All current QTS models support it, including ARM-based units. However, the practical minimum for running meaningful container workloads alongside NAS duties is an Intel Celeron model with at least 8GB RAM.

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. The package is approximately 300MB and installs in 1-2 minutes
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. Choose your primary storage pool (not the system volume) and allocate at least 20-50GB depending on how many containers you plan to run. This location stores Docker images, container filesystems, and any bind-mounted data that you do not explicitly redirect.

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.

1. In Container Station, click Create Container
2. Search for portainer/portainer-ce and select the latest tag
3. 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.

1. Go to Applications → Create
2. Give the application a name (e.g. nextcloud)
3. Paste your Docker Compose YAML into the editor
4. 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 defined in the YAML or loaded from a .env file. Container Station supports both.

Step 5: Networking. Port Mapping and Container Networks

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. On CGNAT connections, a VPN tunnel to a VPS is required to expose services externally. See the NAS remote access guide for the full options.

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 pattern means your container data is included in any QTS snapshot of the storage pool. Giving you point-in-time recovery for your container applications alongside your NAS data.

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. Requires MariaDB or PostgreSQL sidecar container. Memory-intensive; 8GB RAM minimum recommended
• 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. Requires 8GB RAM minimum; a QNAP with 16GB is more comfortable with the ML pipeline running
• 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 static IP on the container
• 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):

• Portainer CE: ~50-100MB
• Pi-hole: ~50-150MB
• Vaultwarden: ~30-80MB
• NGINX Proxy Manager: ~100-200MB
• Home Assistant: ~300-600MB depending on integrations
• Jellyfin (idle): ~200-400MB; more during active transcoding
• Nextcloud (with MariaDB): ~500MB-1GB total for the stack
• Immich (with ML pipeline): ~1.5-3GB during active use

A TS-464 with 8GB RAM. Leaving ~7GB after QTS overhead. Can comfortably run Portainer, Pi-hole, Vaultwarden, Home Assistant, and Jellyfin simultaneously. Add Nextcloud and you are near the ceiling. Add Immich and 8GB is insufficient; upgrade to 16GB or use the TS-473A (up to 64GB ECC) for ML workloads.

🇦🇺 Australian Buyers: What You Need to Know

Minimum hardware for Docker in Australia: The TS-464 ($989 at Scorptec) 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. Most NBN providers place residential connections behind CGNAT, blocking inbound connections. 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.

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. Any Docker image from Docker Hub or any registry works with Container Station. Docker Compose YAMLs written for any other environment work in Container Station without modification. 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 limitation is RAM: with 4GB fixed RAM and QTS consuming 600-800MB, you have roughly 3.2GB free for containers. One or two lightweight containers (Pi-hole, Vaultwarden, a simple web app) run fine. Memory-intensive applications (Nextcloud, Jellyfin, Home Assistant, Immich) will cause memory pressure and instability. 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. QNAP recommends stopping containers before major QTS upgrades (e.g. QTS 5.x to a future 6.x) as a precaution, then restarting them after the upgrade completes. For minor updates within a major version (5.1 → 5.2), containers can remain running during the update.