Synology NAS setup — analysis, alternatives & what we left out

Part 1

The steps, re-examined

Each guide step made one choice for clarity. Here's the reasoning and the roads not taken — and an honest word about which jobs a NAS is actually good at.

DSM, SSH & Container Manager — the foundation

We chose: enable SSH and install Container Manager (Synology's Docker app) as the way to run everything.

Why: a NAS has no winget, brew, or apt. Almost everything you'd want to run lives in a Docker container, and Container Manager is the supported GUI for that. SSH gives you the copy-paste command line the guide leans on.

Alternatives worth knowing

Container Manager (GUI) vs. SSH + the docker CLI — the guide uses SSH and sudo docker run because it's copy-pasteable. You can do the same work entirely in the Container Manager window (Registry → download image → launch with a settings form) if you'd rather not touch a terminal. Same containers, two front ends.
Synology packages vs. Docker — some tools (Tailscale) ship as a native Synology package, which is simpler and survives DSM updates better than a hand-built container. Prefer the package when one exists.
The honest framing: running coding agents on a NAS is fiddly. The CPU is slow, there's no GPU, and keeping a long-lived container healthy across reboots is more babysitting than it's worth. Most people should run the agents on a PC or Mac (see the Windows and Mac guides) and use the NAS only for the two always-on jobs it's genuinely good at: Tailscale and Ollama.

2–4

The three agents (Claude Code · Codex · Gemini)

We chose: npm global installs inside a Node container.

Why: one consistent install method, and a Node container is the cleanest way to get npm onto a NAS that doesn't ship it.

Alternatives & notes (May 2026)

Claude Code now runs on Opus 4.7 (87.6% on SWE-bench Verified) with Agent Teams, Agent View, /goal workflows, and auto mode — but the slow NAS CPU is exactly where you'll feel the difference. This is the strongest argument for running it on a real machine.
Codex got a GPT-5.5 refresh that several 2026 rankings now place at #1 for raw coding — a real reason to keep it in the rotation, not just as a backup.
Run the agents elsewhere, keep the data here. The cleanest pattern: agents on your laptop, your files on the NAS, both on the same tailnet. You get fast tools and the always-on store.
If you prefer a window with diffs and a chat pane, all three also have VS Code extensions — but on a NAS the editor doesn't belong on the box itself; the editor route below covers why and how.

Tailscale — where the NAS shines

We chose: the official Synology Tailscale package, signed in with one account.

Alternatives

Synology Tailscale package vs. a Docker Tailscale container — the package is the right default: it's maintained by Synology, survives DSM updates, and needs no networking flags. A Docker Tailscale container gives more control (subnet routing, custom flags) but is more to set up and more to break. Use the package unless you have a specific reason not to.
ZeroTier and Netbird — open-source mesh-VPN competitors; Netbird is self-hostable end to end. Both have Synology community packages.
Cloudflare Tunnel — exposes one service publicly without opening ports; different job than Tailscale (publish vs. private mesh).
We didn't cover Tailscale ACLs in the guide — they're how you stop, say, the kids' laptop from reaching your Ollama or DSM. Covered in Security below.

Ollama — the always-on model server

We chose: the official Ollama Docker image + llama3.2 as a safe first model.

Alternatives & honest limits

The hardware ceiling is real. A NAS has no GPU. On an x86 "Plus" model (DS920+, DS1522+) Ollama will run small models slowly; on ARM/value models it really can't run models at all. Treat this as "a small model is always available," not "fast inference."
Better small models to try: gemma3 (small/fast) and the small qwen3 variants are friendlier on a CPU-only box than larger ones. Skip the big reasoning models here — they'll crawl.
The real value is availability, not speed. Because the NAS never sleeps and is on Tailscale, one modest model is reachable from every device in the house. For anything heavy, point your agents at a GPU machine or the cloud (see the cloud guide).

Optional · the editor route

The editor route — VS Code on your laptop, code on the NAS

A NAS isn't a workstation. Running VS Code on DSM is the wrong instinct — there's no real desktop, the CPU is modest, and even a code-server container competes with the always-on jobs you actually bought the NAS for (Tailscale, Ollama, file shares). The right pattern is different: run VS Code on your laptop and reach the NAS via Remote-SSH, so the editor lives where it's fast and the files live where they're safe. Here is the honest, fully-detailed editor path for a NAS-centered setup.

The two real paths on a NAS

Path A (recommended): VS Code on your laptop + Remote-SSH into the NAS. Install VS Code on the Mac, PC, or Linux box you actually work from; install the official Remote Development extension pack; then Connect to Host… using the SSH user you enabled in Control Panel → Terminal & SNMP. Your editor shows the NAS's files, terminal, and AI extensions as if they were local. The NAS keeps doing its real job; the editor doesn't tax it.
Path B (browser-based, niche): linuxserver/code-server in Container Manager. A full VS Code in a browser tab, served by the NAS. Useful if your only client is a Chromebook, iPad, or work-issued machine you can't install apps on — and not much else. Pin it to your tailnet only (never publish to the open internet) and keep it on a small CPU/RAM cap so it can't starve the always-on jobs.

Set up Path A — laptop VS Code + Remote-SSH to the NAS

Enable SSH on the NAS (Control Panel → Terminal & SNMP → Enable SSH service) — and turn it off again when you're done editing. See Part 5.
Install VS Code on your laptop: winget install Microsoft.VisualStudioCode on Windows, brew install --cask visual-studio-code on Mac, or via your distro's repo on Linux. (VSCodium if you want the no-telemetry build.)
Install the Remote Development extension pack from the VS Code marketplace.
Connect: F1 → Remote-SSH: Connect to Host… → enter your-user@your-nas-tailscale-name. Use SSH key auth, not password — generate a key, push the public half into /var/services/homes/your-user/.ssh/authorized_keys on the NAS.
Open a shared folder as the project root (e.g. /volume1/code) — VS Code remembers it as a recent host so future opens are one click.

Set up Path B — code-server in Container Manager (only if you really need browser-based)

Container Manager → Registry, pull lscr.io/linuxserver/code-server:latest.
Create the container with these settings: bind /volume1/code to /config/workspace, set PASSWORD (and ideally HASHED_PASSWORD), set SUDO_PASSWORD if you want sudo inside. Map port 8443.
Reach it over Tailscale only. Open http://your-nas-tailscale-name:8443 from a tailnet device. Never add this port to the DSM reverse proxy with a public name; never port-forward 8443 on your router.
Cap resources: in the container's Resources settings, give code-server no more than 1 CPU and 1–2 GB RAM so it can't starve Ollama or Tailscale during a heavy build.

Pick one or two AI extensions, not all of them

Claude Code for VS Code (Anthropic, official) — works inside a Remote-SSH window; the agent runs on the NAS, the editor on your laptop. The natural pick.
GitHub Copilot + Copilot Chat — autocomplete plus a chat panel backed by multiple models (Claude Sonnet 4.6, GPT-5.5, Gemini 2.5). Subscription required.
Cline (formerly Claude Dev) — agentic coding inside VS Code; bring your own key, including a local Ollama on the NAS — the most NAS-native pairing on this page.
Continue — open-source, bring-your-own-model; point it at the NAS's Ollama for a fully-local loop.
Codex VS Code extension / Gemini Code Assist — the editor companions to the CLIs you might also be using.

Five minutes to set it up well

SSH key auth only. No password logins — Synology brute-force attempts are constant if SSH is reachable, even on Tailscale.
Don't connect as the DSM admin. Make a dedicated non-admin SSH user that owns only the project folders. DSM admin should never be an SSH identity.
Lock down what extensions can read. Add .env, .git, node_modules, .secrets/, and any private folders to files.exclude in .vscode/settings.json on the NAS side so extensions don't index them. Especially important here because Remote-SSH gives extensions reach into every share the user can read.
Take a Btrfs snapshot before you let an agent loose on a shared folder — same advice as Part 5, but doubly true once an editor is in the loop.
Turn off SSH when you're done. The cheap habit that closes the biggest door on the NAS.

Pros — what the editor route gives you

Remote-SSH lets the right machine do each job — the laptop runs the editor at full speed; the NAS runs Ollama, holds the files, and is always on. No compromise.
You see diffs visually. When the agent rewrites 12 files in /volume1/code/projectX, you see the diff before accepting.
Inline autocomplete (Copilot in particular) lowers friction on routine code in a way no CLI can.
code-server unlocks browser/iPad workflows — useful if the NAS is the only thing you control and your client device is a Chromebook.
Multi-cursor and structural refactors the agent doesn't bother with — large mechanical renames are still faster as a human editor move.
Rich extension ecosystem — language servers, GitLens, Docker, every linter — all running through the Remote-SSH window into the NAS.

Cons — what it costs you

Running an editor on the NAS is mostly a bad idea. code-server eats RAM and CPU the always-on jobs (Tailscale, Ollama, backups) actually need. Use it only when Remote-SSH isn't an option.
Remote-SSH still needs SSH open. That's a second door on the NAS (the first being DSM). Turn SSH off when you're not editing — the box that holds everything deserves the tightest discipline.
Extension supply-chain risk is bigger here. A malicious VS Code extension running over Remote-SSH can read every file in every share the SSH user can reach. Be picky about extensions; review what each requests; use a non-admin SSH user.
Telemetry, by default. Microsoft VS Code reports usage data; each AI extension reports its own. VSCodium and a tightened telemetry.telemetryLevel are the answer if that matters.
The NAS's CPU caps how interactive code-server can feel. A "Plus" model is fine for light editing; a value model will be sluggish.
It's not designed AI-first. Cursor and Windsurf are VS Code forks that are. Both work over Remote-SSH; both may be the better front-end if you want editor-first AI on a NAS backend.

When to pick which

Stay terminal-only (over SSH or the agents container) if: you do most real work on a laptop already and only touch the NAS for occasional file edits. Simplest, safest.
Use VS Code on your laptop + Remote-SSH if: you want a real editor for code that lives on the NAS — multi-file diffs, an AI extension or two, no extra load on the NAS itself. The recommended route for most people.
Use code-server on the NAS if: your client is a Chromebook, iPad, or locked-down work machine — i.e. you literally can't install VS Code locally. Otherwise prefer Remote-SSH.
Use Cursor or Windsurf on the laptop if: you want the editor experience and care most about how the AI feels. Both work over Remote-SSH into the NAS.
Don't pile on every option. Pick one path and stick with it for a while — the cost of switching between editors mid-project is higher than the benefit of trying them all.

🪟The honest take: the NAS is the always-on store, not the editor. Putting a graphical editor on it is fighting its strengths. Let the laptop you actually type on do the editing — over Remote-SSH or, if you must, in a browser tab pointed at code-server. Either way, the NAS keeps doing what it's good at: holding your files, running Tailscale, and serving Ollama to everyone in the house.

Part 2

What we left out — and why

The guide is deliberately a clean spine: get Tailscale and Ollama running always-on, with the agents available in a container. That clarity has a cost — and on a NAS, the omissions are mostly about protecting the data the box holds. Here they are, honestly, with the reason each was cut.

Left out	What it is	Why it was cut
Hermes Agent	Nous Research's self-improving, model-agnostic coding agent	Now added as the bonus 4th agent — but it needs Python and is heavier than the others, so a NAS is a poor host. Better on a PC or Mac; on the NAS it belongs in a Python-capable container at most.
DSM 2-factor authentication	A second login factor on the DSM admin account	The single highest-value control on a NAS, and it was assumed rather than taught. The box holds all your files — turn this on. See Security.
DSM firewall rules	DSM's built-in firewall to restrict which IPs/ports can reach the NAS	Cut for length, but it's how you keep DSM, SSH, and Ollama from being reachable by anything but your tailnet. Belongs on every NAS.
Disabling SSH when idle	Turning the SSH service back off once you're done	The guide turns SSH on and leaves it on. Best practice is to enable it only while you're working and disable it after — fewer open doors.
Hyper Backup	Synology's backup app (to another disk, NAS, or cloud)	Out of scope for an AI-stack guide, but the NAS holds your originals — an off-box backup is non-negotiable before you treat it as a server.
Btrfs snapshots	Instant, space-cheap point-in-time copies of a shared folder (Btrfs volumes)	The cheapest undo button on a NAS. Take one before any config change so a bad container or setting is a one-click revert.
A reverse proxy	DSM's built-in reverse proxy to put clean names + TLS in front of services	Skipped to keep things simple. Useful once you run more than one web service — but never use it to publish DSM, SSH, or Ollama to the open internet.
"It holds everything"	The plain fact that the NAS stores all your data	Not a tool — a mindset the guide didn't state outright. The NAS is the highest-value target on your network. That single fact should drive every security choice below.

🧭The pattern: on a PC the omissions were about capability (Git, Python, MCP). On a NAS the omissions are about protection — because this box is where your photos, documents, and backups live. The fixes aren't optional extras; they're what makes a NAS safe to leave always-on.

Part 3 · what the AI crowd is actually using

Trending & cool — tools worth a look

Scanning the developer conversation on X and GitHub in May 2026, here's what's hot that the guide doesn't yet mention. Most of these are happiest on a real machine — but worth knowing about wherever you run your agents.

OpenCode

The open-source CLI agent everyone's talking about — 150K+ stars, ~6.5M monthly devs. LSP integration, multiple parallel sessions, shareable session links. The strongest "free, bring-your-own-model" alternative to Claude Code.

Warp 2.0

A terminal that's also an agent cockpit — runs Claude Code, Codex, and others in one windowed UI with panes. Nice if the bare terminal feels stark.

Goose · OpenHands

Goose (from Block) and OpenHands are open-source autonomous agents that take a goal and run a long multi-step job. The frontier of "set it and walk away."

GitHub Spec Kit

93K+ stars. A "spec-driven development" workflow that teaches any agent (Claude Code, Copilot, Gemini, etc.) to plan before it codes. Tessl and Kiro play in the same space.

MCP servers

The plug-ins that matter: chrome-devtools-mcp (let an agent drive Chrome), filesystem, GitHub, database connectors. This is the fastest-moving, highest-leverage area right now.

Qwen 3.6-Plus (local)

An agentic open model with a 1M-token context and MCP-native tool use — a serious local option if your hardware can handle it. (A NAS can't; a GPU machine can.)

⚖️Why these aren't in the main guide: they're powerful but move fast, need more setup, or assume comfort with the basics. The guide's job is to get you to "it works." This list is your "now go further." Honorable mentions from the same conversation: Amazon Q Developer CLI, Sourcegraph Amp, Qwen Code, Crush, Plandex, Kimi CLI, Aider, Cline.

Part 4 · the next wave

Getting ready for Mythos

Mythos is Anthropic's first model specialized for one domain: defensive cybersecurity. Announced April 7 2026 as the engine of Project Glasswing, it has already found a 27-year-old vulnerability in OpenBSD and bugs in FFmpeg. It is invitation-only ($25 / $125 per million tokens), shipped to 12 founding orgs and 40+ critical-infrastructure partners — not a download. Full briefing →

You won't run a Mythos-class tool on the NAS — but the NAS is the most important thing on your network for it to one day analyze, because it holds everything. So "getting ready" here means keeping the box that holds all your data hardened, and your environment set up so a specialized model could be pointed at something useful:

Get on MCP now. Specialized models reach your code and infrastructure through MCP. A working MCP setup today (on your real machine) is the plug Mythos-class tools will use tomorrow.
Have your data reachable over Tailscale. A security model is only useful pointed at your systems. The NAS on your tailnet = the highest-value asset, ready to be analyzed.
Tighten the NAS first (Part 5). The irony: you can't safely point a vulnerability-finding model at a sloppy, internet-exposed NAS. Hardening the box that holds everything is the prerequisite, not the reward.
Keep a clean Anthropic account & current Claude Code. Access to new models lands through the same account and tooling you already use.
Watch Glasswing. If you run anything critical (a business, rentals, client sites), the initiative is where defensive tooling will surface first.

🔭Honest take: as an individual you won't get Mythos itself soon. What you can do is build the habits — MCP, a private network, and a hardened NAS that holds everything safely — that make any future specialized model immediately useful. That's the real "future-proofing" (see the tool map).

Part 5 · don't skip this

Securing the install — the part most guides skip

You're installing tools that can read your files, run commands, and reach the internet, plus a private network and a local model server — all on the one box that holds every file you own. That's a lot of power in a high-value place. Here's how to keep it from biting you — NAS specifics first, then universal rules.

⚠Lead with this: the NAS holds all your files — photos, documents, backups. That makes it the highest-value target on your whole network. Everything below follows from one rule: harden the NAS hardest, because if anything on your network deserves the strongest locks, it's the box that holds everything.

NAS specifics — harden the box that holds everything

Turn on 2-factor authentication on DSM. The single most important control. A leaked admin password should not be enough to reach your files — require a second factor.
Never expose DSM, SSH, or the Ollama container port to the internet. No port-forwarding port 5000, 22, or 11434 on your router; no public reverse proxy in front of them. Reach all of them over Tailscale only.
Turn on the DSM firewall. Control Panel → Security → Firewall — allow only your LAN and your tailnet to reach DSM/SSH/Ollama, deny the rest.
Disable SSH when you're not using it. The guide turns it on; turn it back off once you're done. Fewer open doors on an always-on box.
Keep DSM and your packages updated. Synology ships security fixes regularly — an outdated NAS facing the world is how these boxes get hit.
The Ollama Docker container has no authentication. Publishing port 11434 puts an open, password-free model server on the network. It's only safe because it's behind Tailscale — never let that port reach the open internet.
Take a Btrfs snapshot before changes. On a Btrfs volume, snapshot the relevant shared folder before any config or container change — a bad setting becomes a one-click revert.

⚠Real incident (Feb 2026): Check Point Research disclosed that a malicious config could redirect Claude Code's traffic via the ANTHROPIC_BASE_URL setting and exfiltrate your API key in plaintext. Anthropic patched it before disclosure — the lesson stands: keep Claude Code updated, install only from official sources, and be suspicious of any config that reroutes where a tool "phones home."

Protect your keys & logins

Never paste API keys into files you might share or commit. Anthropic + GitHub run secret-scanning that auto-deactivates leaked Claude keys — helpful, but don't rely on it. Use the browser login flow (no key on disk) where you can.
Don't leave keys in plaintext on a shared NAS folder — it's exactly where they'd be discovered. Rotate a key the moment you suspect it leaked; give helpers their own keys, never yours.

Keep the agents on a leash

Block agent access to secrets. Configure Claude Code's permissions to deny reading .env files, SSH keys, .secrets, and certificates — and to not read its own config (which could be used to manipulate it).
Start agents in ask-before-acting mode; only loosen once you trust the workflow. Don't run "auto/yolo" modes in a container that can see your shared folders.
Mount only the project folder into the container, not the whole NAS — limit what the agent can even see.

Supply chain (the install commands themselves)

npm install -g, pip install, and docker run all run other people's code. Only use the exact official images and sources in the guide; don't paste install one-liners from random blog posts or X replies.
Prefer the official Synology package over a hand-built container when one exists (it's signed and maintained).
Keep everything updated — DSM, packages, and the container images you pull.

Lock down Ollama & Tailscale

Ollama: the published port 11434 is an open model server with no password. Only reach it behind Tailscale — never on a public IP or open Wi-Fi.
Tailscale ACLs: in the admin console, restrict who can reach port 11434 and DSM/SSH, and who can SSH where. Turn on key expiry so a lost device drops off. Tailscale's new Aperture (alpha) can even keep API keys off your devices entirely, behind your tailnet identity.

✓ Good shape when: DSM has 2FA on, the firewall is up, nothing (DSM, SSH, Ollama) is exposed to the internet, SSH is off when idle, DSM and packages are current, you've snapshotted before changes, no keys sit in plaintext, agents can't read your secrets, and Ollama + DSM are Tailscale-only. That's a NAS — the box that holds everything — you can leave always-on without flinching.

The Synology setup, under the microscope.