Last updated: 2026-06-30

The short version: Most Synology and QNAP NAS units sold in the last three years have enough CPU, RAM, and (on higher-end models) GPU or NPU headroom to run a real local LLM through Docker and Ollama. You don't need a dedicated AI rig — you need the box already humming in your closet, configured correctly so it never touches the public internet.

If you've been putting off self-hosted AI because it sounded like a separate hardware project, it isn't anymore. Your NAS is already on 24/7, already has redundant storage, and already sits behind your router. Turning it into a private inference server is mostly a software decision, not a hardware purchase.

This guide walks through the setup on both major NAS platforms, what hardware tier you actually need, and — the part most tutorials skip — how to back up and remotely access the thing without creating the exact privacy hole you built this to avoid.

Why a NAS Instead of a Dedicated AI Box

A purpose-built AI workstation with a discrete GPU will always out-run a NAS on tokens per second. That's not the comparison that matters for most people.

The case for the NAS:

It's already running. No new power draw, no new noise, no new device to secure and patch.
Storage is already redundant. RAID arrays on Synology (SHR) and QNAP (RAID 5/6) mean your model files, embeddings, and chat logs survive a drive failure without extra work.
It's already on your private network with proper access controls, assuming you've done basic hardening (see the checklist near the end).
It's good enough for 7B–14B parameter models, which cover the vast majority of personal use: drafting, summarizing, document Q&A, code review on small snippets.

What it's not good for: training, fine-tuning, or running 70B+ models at usable speed without add-in GPU hardware. If you need that, this guide pairs well with our air-gapped AI workstation setup guide for a dedicated rig. For everyday private AI use, the NAS you already own is enough.

What Hardware You Actually Need

Before installing anything, check what you're working with:

Minimum viable (4B–7B models, usable but not fast):

4+ CPU cores, x86-64 (ARM-based NAS units will struggle badly — check your model)
8GB RAM minimum, 16GB comfortable
Examples: Synology DS923+, QNAP TS-464

Good performance (7B–14B models at conversational speed):

16–32GB RAM
A NAS with PCIe expansion for a GPU card, or a model with a built-in NPU
Examples: Synology DS1823xs+, QNAP TVS-h674 with PCIe GPU add-in

Best in class (NAS-tier — still not a gaming PC):

QNAP's GPU-equipped TVS series with an Nvidia card installed
32GB+ RAM
This tier can run 14B–32B quantized models at acceptable speed

If your NAS is ARM-based (many budget Synology models — check Synology's CPU spec page for your exact model), stop here and consider a Raspberry Pi 5 or a used mini PC instead. Ollama's ARM support exists but performance on NAS-grade ARM chips is poor enough that it's not worth the frustration.

Setting Up Ollama on Synology

Synology's DSM (DiskStation Manager) supports Docker through Container Manager, available free on DSM 7.2+.

Step 1: Install Container Manager

Open Package Center → search "Container Manager" → Install. On older DSM versions this package is called "Docker."

Step 2: Pull and run the Ollama image

Open Container Manager → Registry → search ollama/ollama → Download (pick latest).

Then create the container manually rather than through the GUI wizard, so you can set the right port binding and volume mount:

```bash

SSH into your Synology (enable SSH in Control Panel → Terminal & SNMP first)

sudo docker run -d \

--name ollama \

-v /volume1/docker/ollama:/root/.ollama \

-p 127.0.0.1:11434:11434 \

--restart unless-stopped \

ollama/ollama

```

Note the 127.0.0.1:11434:11434 binding — this is the single most important line in this entire guide. It binds Ollama's API to localhost only, meaning nothing outside the NAS itself can reach it directly. We'll cover remote access properly in a later section, but never skip this step in favor of -p 11434:11434, which exposes the port to your whole LAN (and potentially the internet, if UPnP is enabled on your router).

Step 3: Pull a model and test

```bash

sudo docker exec -it ollama ollama pull llama3.1:8b

sudo docker exec -it ollama ollama run llama3.1:8b "Summarize the purpose of a NAS in one sentence."

```

If that returns a coherent answer, your local LLM is live.

Setting Up Ollama on QNAP

QNAP's equivalent is Container Station, available through the App Center on QTS and QuTS hero.

Step 1: Install Container Station from App Center if it isn't already present.

Step 2: Create the Ollama container

Container Station has a "Create" wizard, but for the same reason as above, use the YAML/advanced mode so you control the port binding:

```yaml

version: "3"

services:

ollama:

image: ollama/ollama

container_name: ollama

restart: unless-stopped

ports:

- "127.0.0.1:11434:11434"

volumes:

- /share/Container/ollama:/root/.ollama

```

Paste this into Container Station's "Create Application" → YAML editor and deploy.

Step 3: If your QNAP has a GPU installed, add the GPU passthrough flags so Ollama can use it — QNAP's documentation for your specific GPU model (Nvidia cards are best supported) has the exact --gpus all equivalent for Container Station's interface. Without this, Ollama falls back to CPU inference, which works but is noticeably slower.

Step 4: Pull and test, same commands as above via SSH or Container Station's built-in terminal.

Connecting a Chat Interface

Running Ollama headless via curl gets old fast. Open WebUI gives you a ChatGPT-style interface running entirely on your NAS.

```bash

sudo docker run -d \

--name open-webui \

-p 127.0.0.1:3000:8080 \

-v /volume1/docker/open-webui:/app/backend/data \

--add-host=host.docker.internal:host-gateway \

-e OLLAMA_BASE_URL=http://host.docker.internal:11434 \

--restart unless-stopped \

ghcr.io/open-webui/open-webui:main

```

Again — bound to 127.0.0.1 only. Access it from a browser on the NAS itself, or read on for the right way to reach it from other devices. We cover the full multi-user setup with model switching in our Open WebUI setup guide if you want RAG and multiple accounts.

Accessing Your NAS AI Remotely Without Exposing It

This is where most NAS AI tutorials get dangerous: they tell you to forward port 3000 or 11434 through your router so you can reach your chat interface from your phone. Don't.

Port-forwarding an LLM interface to the public internet means anyone who finds it — and Shodan-style scanners actively look — can query your models, see your chat history if storage isn't locked down, and burn your NAS's CPU for free. Synology's own QuickConnect and QNAP's myQNAPcloud have both been the subject of real exposure incidents when users forwarded ports carelessly.

The correct approach is a VPN tunnel into your home network, not a port opened to the world. Proton VPN supports router-level configuration on DD-WRT, OpenWRT, and several commercial routers — once your router runs as a VPN endpoint, your phone or laptop connects in from anywhere and reaches your NAS's local IP exactly as if you were home. No port ever opens to the internet.

Affiliate Disclosure: This article may contain affiliate links. If you make a purchase through these links, we may earn a small commission at no extra cost to you. We only recommend products we genuinely believe in. This helps support our work and allows us to continue providing free content.

A lighter-weight alternative if you just need encrypted document storage rather than full server backups: keep your source documents — the ones you're feeding into RAG — in an encrypted Proton Drive folder and pull a local copy onto the NAS only when actively indexing. That way the canonical sensitive copy lives encrypted in the cloud, and the NAS only ever holds a working copy behind your firewall.

When to Route Out to the Cloud Anyway

A NAS-hosted 8B or 14B model is excellent for private document work — summarizing contracts, drafting internal notes, querying your own files via RAG. It is not a good fit for anything that needs current information, since these models' knowledge is frozen at training time and a home NAS isn't going to run a live web-search agent well.

For that category of query — "what changed in this library's API last month," "current pricing for X," general research that doesn't touch anything sensitive — Perplexity is a faster and more accurate tool than forcing your NAS to answer from a stale knowledge cutoff. The discipline that makes this work long-term: if the question involves your own private files or business context, it goes to your NAS. If it's general, current-events research, it goes to Perplexity.

Hardening Checklist Before You Call It Done

[ ] Ollama bound to 127.0.0.1 inside its container, never 0.0.0.0 or a raw port mapping to your LAN
[ ] Open WebUI (or any chat UI) bound to 127.0.0.1 as well
[ ] No router port forwards for 11434, 3000, or any AI-related port
[ ] UPnP disabled on your router (check Advanced settings — most consumer routers ship with it on)
[ ] Remote access goes through a VPN (Proton VPN router config or Tailscale), never a forwarded port
[ ] DSM/QTS itself is updated and 2FA is enabled on the admin account — a compromised NAS admin login defeats everything above
[ ] Docker volumes backed up on a schedule to encrypted storage, not plaintext cloud sync
[ ] If running RAG over sensitive documents, source files are encrypted at rest when not actively in use

Summary

You likely already own the hardware for a private AI server — it's the NAS sitting in your closet. Docker and Ollama turn it into a capable local LLM host in under an hour, and the privacy payoff is real: your prompts, your documents, and your chat history never leave your network. The setup steps are the easy part. The discipline that actually matters is the same in every self-hosted AI guide on this site — bind to localhost, never forward the port, and access remotely through a VPN instead of opening your NAS to the public internet.

Start receiving our weekly private AI setup guide — practical hardening techniques, model recommendations, and workflow templates for privacy-conscious engineers. No tracking pixels. Unsubscribe anytime.

Subscribe to the PrivateAI Weekly →

Running this on a NAS model we didn't cover, or hit a snag with GPU passthrough? This guide gets updated as Synology and QNAP ship new Container Manager/Container Station releases.