Running multiple self-hosted apps on a single NAS is practical on mid-range hardware, provided you understand the resource constraints and plan your container stack before you buy. The most common combination today is Immich (photo management), Jellyfin (media server), and Vaultwarden (password manager) alongside a basic file-sharing setup. Each app has a different resource profile, and understanding those profiles is what separates a NAS that runs smoothly from one that falls over at 9pm when everyone in the house is streaming.
In short: A 4-bay NAS with a quad-core processor and 8GB RAM can comfortably run 3-4 self-hosted apps simultaneously. Add Jellyfin software transcoding and you need more CPU or a NAS with hardware transcoding support. Immich is the most RAM-hungry app in a typical home stack. Plan your container stack before you buy, not after.
Why Self-Hosting Multiple Apps on One NAS Works (and Where It Breaks)
A NAS is not a dedicated server, but modern mid-range models are capable enough to run several Docker containers alongside standard file-sharing and backup tasks. The key distinction is between idle resource consumption and peak load. An app like Vaultwarden uses almost no resources when nobody is unlocking their password vault. Jellyfin's impact depends entirely on whether it is transcoding. Immich's machine-learning features spike CPU and RAM when processing new photos.
The failure mode is not that the NAS crashes. It is that apps become slow or unresponsive when multiple peak loads overlap. Understanding each app's resource profile lets you set realistic expectations and configure your stack to avoid overlapping workloads.
Resource Profiles: What Each App Actually Needs
Before stacking containers, it helps to understand what each app demands. The figures below are practical estimates for a home deployment, not vendor marketing numbers.
Self-Hosted App Resource Requirements (Home Deployment)
| Immich | Jellyfin | Vaultwarden | Nextcloud | Home Assistant | |
|---|---|---|---|---|---|
| Idle RAM | 500MB-1GB | 300-500MB | 20-50MB | 300-500MB | 300-600MB |
| Peak RAM | 2-4GB (ML processing) | 1-2GB (transcoding) | 100MB | 1-2GB | 500MB-1GB |
| CPU (idle) | Low | Very low | Negligible | Low | Low |
| CPU (peak) | High (face/object detection) | Very high (SW transcode) | Negligible | Medium | Low-medium |
| Storage impact | High (photo library + ML models) | High (media library) | Minimal | Medium-high | Low |
| Hardware transcoding benefit | No | Yes, significant | No | No | No |
The table shows why Jellyfin and Immich are the two apps to plan around. Vaultwarden, Home Assistant, and lightweight services like a personal wiki or RSS reader add almost nothing to the overall load and can generally be added without concern once the main workloads are accounted for.
Jellyfin: The Transcoding Problem
Jellyfin's resource demand is almost entirely determined by whether it needs to transcode. Direct play (the client can play the file format natively) uses almost no CPU. Software transcoding (converting a video to a format the client can handle in real time) can consume all available CPU on a low-to-mid-range NAS processor.
The practical approach is to build a library that favours direct play. MP4/H.264 content at reasonable bitrates will direct-play on most modern clients including Roku, Apple TV, Chromecast, smart TVs, and browser players. H.265/HEVC and AV1 content is more likely to require transcoding unless the client has hardware decode support for those codecs.
Hardware transcoding bypasses the CPU entirely by offloading video conversion to the NAS's integrated GPU or dedicated NPU. Not all NAS processors support this and the implementation varies by platform. Key things to check before buying for Jellyfin:
- Does the NAS processor include Intel Quick Sync or a supported ARM codec engine?
- Does the NAS vendor's operating system expose the hardware transcoding capability to Docker containers?
- What video codecs does the hardware transcoder support? Most consumer NAS hardware transcoding handles H.264 and H.265 but not AV1.
On Synology, hardware transcoding in Docker containers requires a Plus series model with a compatible processor. On QNAP, hardware transcoding availability in containers depends on the specific model and QTS version. Check each vendor's compatibility documentation before assuming this feature is available.
Immich: The RAM and ML Processing Consideration
Immich is the most resource-intensive app in a typical home self-hosting stack. Its machine-learning features, specifically face recognition and object/scene detection, require a dedicated immich-machine-learning container that holds ML models in memory.
On first import of a large photo library, Immich will run processing jobs that consume sustained CPU and RAM over hours or days. This is a one-time cost, but it matters for sizing. After initial processing, ongoing resource use is low unless new photos are imported frequently.
The ML model container typically uses 1-2GB of RAM by itself when loaded. Combined with the main Immich server, Redis, and PostgreSQL containers, the full Immich stack in a home deployment sits at approximately 2-3GB RAM at idle and can spike to 4GB during active ML processing.
If RAM is constrained, consider disabling the ML features and running Immich as a pure photo backup and browsing tool. It remains useful without face recognition. Re-enable ML features if you upgrade RAM later.
Vaultwarden: The Easy One
Vaultwarden is a lightweight, unofficial Bitwarden-compatible server written in Rust. Its resource footprint is minimal. A typical Vaultwarden instance uses 20-50MB of RAM at idle and negligible CPU, even with multiple users syncing their vaults. It can run comfortably on any NAS capable of running Docker, including entry-level 2-bay models.
The primary consideration with Vaultwarden is security, not resources. A password vault should never be exposed directly to the internet without a properly configured reverse proxy (Nginx Proxy Manager or Traefik are common choices in the homelab community) and strong authentication. HTTPS is a hard requirement. If you are not comfortable configuring this, consider keeping Vaultwarden on your local network only and using a VPN (Tailscale or WireGuard) to access it remotely.
This is especially relevant for Australian users on NBN connections where CGNAT (Carrier-Grade NAT) may prevent direct port forwarding from the internet to your NAS. CGNAT is common on mobile broadband and some NBN plans, particularly those using the Hybrid Fibre Coaxial (HFC) connection type with certain ISPs. If your ISP assigns you a private IP address, standard port forwarding will not work and Tailscale (which uses relay servers to bypass CGNAT) is a reliable alternative.
CGNAT and remote access: Many Australian NBN users are behind CGNAT, which blocks inbound connections from the internet to your home network. If port forwarding does not work, check with your ISP. Tailscale is a free, practical solution that works through CGNAT and does not require a static IP. See our guide on NAS remote access options in Australia for more detail.
Choosing the Right NAS for a Multi-App Stack
The most common mistake when building a self-hosted NAS stack is buying a NAS sized for storage and then trying to run services on it. Storage capacity and compute capacity are separate concerns. A NAS with 4 bays and a low-power ARM processor may hold 40TB of data and still struggle to run Immich and Jellyfin simultaneously.
For a multi-app stack in 2026, the practical minimum hardware spec is:
- Processor: Quad-core x86 (Intel Celeron J4125 or newer) or ARM Cortex-A55 quad-core. Avoid single and dual-core processors for multi-app deployments.
- RAM: 8GB minimum. 16GB recommended if running Immich ML features plus Jellyfin transcoding. Most NAS models cap at 16GB; check the spec before buying.
- RAM upgradeability: Many NAS models ship with 4GB but can be upgraded. Check that the model supports user-upgradeable RAM before purchasing a 4GB unit with the intention to upgrade.
- Storage: SSDs or NVMe for the Docker volumes and application data. HDDs for media and photo storage. Running containers and databases on spinning HDDs introduces latency that affects app responsiveness under load.
Recommended Models for a Multi-App Stack in Australia
The models below are currently available from Australian retailers. Prices are approximate and sourced from Mwave, Scorptec, and PLE. Always verify current pricing before purchasing, as NAS prices have been volatile through 2025-2026.
| Model | Synology DS925+ |
|---|---|
| Bays | 4-bay |
| Processor | AMD Ryzen R1600 dual-core, 2.6GHz (3.1GHz boost) |
| RAM (stock) | 4GB DDR4 ECC (expandable to 32GB) |
| AU Price | From $980 (Mwave, Scorptec, Computer Alliance) |
| Docker support | Yes, via Container Manager |
| Hardware transcoding | No (AMD Ryzen R1600 does not include Quick Sync) |
| Verdict | Strong CPU for Immich and Nextcloud. Upgrade RAM to 16GB for comfortable multi-app use. Not ideal if Jellyfin transcoding is the priority. |
| Model | Synology DS425+ |
|---|---|
| Bays | 4-bay |
| Processor | Intel Celeron J4125, 2.0GHz (2.7GHz burst) |
| RAM (stock) | 2GB DDR4 (expandable to 6GB) |
| AU Price | From $785 (Mwave, Scorptec, Computer Alliance) |
| Docker support | Yes, via Container Manager |
| Hardware transcoding | Yes (Intel Quick Sync. H.264 and H.265) |
| Verdict | Good Jellyfin hardware transcoding via Quick Sync. RAM ceiling of 6GB is the constraint for Immich ML stack. Better suited to Jellyfin-first deployments. |
| Model | QNAP TS-464 |
|---|---|
| Bays | 4-bay |
| Processor | Intel Celeron N5095, 2.0GHz (2.9GHz burst), quad-core |
| RAM (stock) | 8GB DDR4 (expandable to 16GB) |
| AU Price | From $989 (Mwave Australia, Scorptec, PLE) |
| Docker support | Yes, via Container Station |
| Hardware transcoding | Yes (Intel Quick Sync. H.264, H.265) |
| Verdict | 8GB stock RAM makes this the most accessible entry point for a full multi-app stack without an immediate RAM upgrade. Quad-core N5095 handles Immich and Jellyfin better than J4125-based alternatives. |
| Model | QNAP TS-473A |
|---|---|
| Bays | 4-bay |
| Processor | AMD Ryzen V1500B quad-core, 2.2GHz |
| RAM (stock) | 4GB DDR4 ECC (expandable to 64GB) |
| AU Price | From $1,269 (Scorptec, PLE, Computer Alliance) |
| Docker support | Yes, via Container Station |
| Hardware transcoding | No (AMD Ryzen V1500B lacks Quick Sync) |
| Verdict | Highest expandable RAM in this tier (64GB). Excellent for Immich and compute-heavy containers. Not the best choice if Jellyfin transcoding is the priority. Pair with a GPU passthrough setup if transcoding matters. |
RAM upgrade tip: The QNAP TS-464 ships with 8GB and is the easiest entry point for a multi-app stack without an immediate upgrade. If you are buying a 4GB model with the intent to upgrade, confirm the exact RAM type and maximum supported capacity in the vendor's spec sheet before purchasing. Third-party RAM is generally compatible but check the hardware compatibility list, particularly for ECC models.
Docker Port Conflicts and Container Management
Each Docker container exposes services on specific ports, and two containers cannot use the same host port. Port conflicts are one of the most common issues when deploying multiple containers on a NAS for the first time.
Common default ports for home self-hosting apps:
- Immich: Port 2283 (web UI)
- Jellyfin: Port 8096 (HTTP), 8920 (HTTPS)
- Vaultwarden: Port 80 and 443 (or commonly remapped to 8080/8443)
- Nextcloud: Port 8080 (commonly remapped)
- Home Assistant: Port 8123
- Nginx Proxy Manager: Ports 80, 81 (admin), 443
If you are running a reverse proxy (recommended), you typically expose only the reverse proxy on ports 80 and 443, and route traffic to each container by domain name or subdomain. This also simplifies SSL certificate management via Let's Encrypt integration built into tools like Nginx Proxy Manager.
Both Synology (Container Manager) and QNAP (Container Station) provide GUI interfaces for managing Docker containers. QNAP's Container Station also supports Kubernetes via KubeVirt for more advanced deployments. For most home self-hosting use cases, the GUI tools are sufficient and remove the need to work directly with Docker Compose files, though Docker Compose remains the most portable and reproducible way to define multi-container stacks.
Storage Architecture: Separating App Data from Media
Running containers on HDD storage is workable but suboptimal. Databases (Immich uses PostgreSQL, Jellyfin uses SQLite by default) are read/write-intensive and benefit significantly from SSD storage. A practical architecture for a multi-app NAS:
- NVMe SSD (M.2 cache or dedicated volume): Container volumes, application databases, configuration files. 500GB is sufficient for most home deployments.
- HDD volume (RAID 1 or RAID 5): Photo library, media library, file shares, backups. Size according to your data.
Many 4-bay NAS models include M.2 NVMe slots that can host SSDs separately from the main drive bays. The QNAP TS-464 has two M.2 NVMe slots. The Synology DS925+ supports NVMe expansion via the SNV3500 SSD series. Check the spec sheet for each model, as M.2 slot availability varies widely.
If there are no M.2 slots, a dedicated SATA SSD in one of the drive bays used as an SSD volume for app data is the next best option. Losing one bay reduces storage capacity but meaningfully improves application responsiveness.
How Many Apps Can One NAS Handle?
This is a practical question with no universal answer. The limiting factor is usually RAM, followed by CPU at peak load. As a rough guide for a NAS with 8GB RAM and a quad-core processor:
- Immich (with ML): 2-3GB RAM. High CPU during initial library processing, then moderate.
- Jellyfin (direct play only): 500MB RAM. Negligible CPU.
- Vaultwarden: 50MB RAM. Negligible CPU.
- Nginx Proxy Manager: 100-200MB RAM. Negligible CPU.
- System OS overhead: 1-2GB RAM.
Total: approximately 4-5GB RAM with the stack above. This is comfortable on 8GB. Adding Nextcloud would push it toward 6GB, still workable. Adding Jellyfin software transcoding on top of active Immich ML processing on 8GB RAM is where you start seeing resource pressure.
The practical limit on 8GB RAM is typically 4-6 lightweight-to-medium containers. Beyond that, either upgrade RAM or be selective about which apps run with ML/AI features enabled.
Australian Buyers: What You Need to Know
NAS pricing in Australia is currently running 10-20% above US levels, driven by lower stock allocations, higher freight costs, and smaller market volumes. This affects the value calculation when comparing a dedicated NAS to repurposing older PC hardware for self-hosting.
The models recommended in this guide are available from Australian retailers including Scorptec, Mwave, PLE Computers, and Computer Alliance. Scorptec and PLE carry the widest range and have staff who can advise on compatibility questions. For a first self-hosting deployment, buying from a specialist rather than Amazon AU is worthwhile: if you have setup questions or the unit behaves unexpectedly, the ability to speak to someone who understands the product is valuable.
NAS-class hard drive prices have risen significantly from early 2025 levels. If you are planning a build, buy drives and the NAS together to lock in a total cost, rather than buying the NAS now and planning to add drives later at unknown future prices.
Australian Consumer Law protections apply when purchasing from Australian retailers. NAS manufacturers do not have service centres in Australia. If a unit fails, the warranty process runs through the retailer, then the distributor, then the vendor in Taiwan. Expect 2-3 weeks minimum for resolution. For a NAS running critical self-hosted services, factor this into your resilience planning.
NBN upload speeds also affect some self-hosted app use cases. The typical NBN 100 plan delivers approximately 17-20Mbps upload. If you are accessing Immich or Nextcloud remotely and uploading large files or photo library imports over your home internet connection, this upload ceiling is the bottleneck, not the NAS hardware. NBN 250 and NBN 1000 plans offer significantly better upload, particularly on Fibre to the Premises connections.
Common Mistakes When Stacking Apps on a NAS
The Need to Know IT team sees the same three mistakes repeatedly from people who have attempted a multi-app NAS setup:
- Buying on storage capacity alone. A NAS marketed as "perfect for home storage" with a dual-core 1.4GHz processor and 1GB RAM will not run a modern self-hosted photo management stack. Storage and compute are separate considerations. Check the processor and RAM spec before purchase.
- Running all container volumes on spinning HDD. Database-backed apps like Immich and Nextcloud have high random I/O requirements. Running their data volumes on HDDs is slow and puts unnecessary write load on drives that are also serving media. Use SSD storage for container volumes, even if it is just a single SATA SSD in one bay.
- Exposing apps directly to the internet without HTTPS. Self-hosted apps like Vaultwarden and Nextcloud that handle credentials or private data must be served over HTTPS. Deploying them on plain HTTP and forwarding port 80 to the internet is a significant security risk. A reverse proxy with automatic Let's Encrypt certificates (Nginx Proxy Manager is beginner-friendly) is the correct approach.
Next Steps and Practical Checklist
Before deploying a multi-app NAS stack, work through the following:
- List every app you plan to run and note its idle and peak RAM requirements
- Total the RAM requirements and add 1.5-2GB for OS overhead. If the total exceeds the NAS's RAM, either choose a higher-RAM model or trim the app list
- Check whether any apps require hardware transcoding and confirm the NAS model exposes that capability to Docker containers
- Plan storage architecture: SSD for app data and databases, HDD for media and files
- Decide on your remote access approach before deploying. If your ISP uses CGNAT, Tailscale is the practical solution
- For Vaultwarden and other credential-storing apps, configure HTTPS via a reverse proxy before opening any external access
- Test the stack at low load first, then simulate peak load (import a large photo batch while streaming video) to verify the NAS handles it
For more on Docker and container management on NAS, see our guides on best NAS for Docker and home automation in Australia and best NAS for Nextcloud in Australia. For hardware recommendations across different use cases, our best NAS Australia guide covers the full market.
Can I run Immich and Jellyfin at the same time on a NAS with 4GB RAM?
It is possible but constrained. The Immich stack alone (server, ML container, Redis, PostgreSQL) uses 2-3GB RAM at idle with ML features enabled. Jellyfin in direct-play mode adds around 500MB. On 4GB RAM with 1-1.5GB reserved for the OS, you are at the limit before any peak processing begins. The practical options are: upgrade the RAM before deploying both apps, disable Immich's ML features to reduce its footprint, or choose a NAS model that ships with 8GB rather than planning to upgrade a 4GB unit.
Does Jellyfin require hardware transcoding on a NAS?
No, but software transcoding on a NAS processor is resource-intensive and will noticeably affect other running apps. If your media library is primarily H.264 at 1080p or lower bitrates and your client devices support direct play (most modern TVs, streaming sticks, and mobile devices do), transcoding may rarely trigger. If you have HEVC/H.265 or AV1 content, or clients that cannot handle higher bitrates, hardware transcoding becomes important. Check that the NAS model explicitly supports hardware transcoding in Docker containers, not just in the NAS vendor's native media apps.
Is it safe to run Vaultwarden on a NAS exposed to the internet?
Yes, if correctly configured. Vaultwarden must be served over HTTPS, which requires either a reverse proxy with a valid SSL certificate or a Cloudflare tunnel. Plain HTTP access to a password vault over the internet is not acceptable. Nginx Proxy Manager is the most beginner-friendly reverse proxy for this use case and includes automatic Let's Encrypt certificate management. Ensure Vaultwarden is kept updated, as it is an active project with regular security releases. If you are not confident configuring HTTPS correctly, keep Vaultwarden on your local network and use Tailscale for remote access.
What is the best NAS for running multiple self-hosted apps in Australia?
The QNAP TS-464 is the most practical starting point in 2026. It ships with 8GB RAM (no immediate upgrade needed), has a capable Intel Celeron N5095 quad-core processor with hardware transcoding support, includes M.2 NVMe slots for SSD storage of container volumes, and is available from Australian retailers from around $989. The Synology DS925+ is a strong alternative with a more powerful AMD Ryzen R1600 processor and 32GB RAM ceiling, but lacks hardware transcoding for Jellyfin and starts at $980 for a 4GB unit that will need a RAM upgrade for a full stack. For Synology users who want Quick Sync hardware transcoding, the DS425+ at $785 is the entry point, though its 6GB RAM ceiling limits Immich's ML capabilities.
How do I avoid port conflicts when running multiple Docker containers on a NAS?
Map each container to a unique host port in the Docker configuration. Most containers allow you to change the host port they bind to while keeping the container's internal port the same. For example, if two apps both want to use port 8080, remap one of them to port 8081 on the host. The better long-term approach is to run a reverse proxy (Nginx Proxy Manager is the most accessible option) that handles all incoming traffic on ports 80 and 443 and routes it to the correct container by hostname. This means only the reverse proxy is exposed externally and you manage routing by subdomain rather than managing individual ports.
Can I run self-hosted apps on a NAS without a static IP address in Australia?
Yes. Most Australian home internet connections use dynamic IP addresses, and many NBN connections also operate behind CGNAT (Carrier-Grade NAT), which prevents standard port forwarding from working at all. Tailscale is the most reliable solution: it creates a private VPN mesh between your devices using relay servers to traverse CGNAT, works on all major platforms, and has a free tier sufficient for personal use. Cloudflare Tunnels are another option for apps you want to expose via a public domain name without a static IP. DuckDNS combined with a reverse proxy handles the dynamic IP case if CGNAT is not present.
Planning a self-hosted NAS build? Our NAS buying guide covers the full Australian market with current pricing and availability across Synology, QNAP, Asustor, and Ugreen.
See Best NAS Australia