Home

NAS-as-Code

Welcome to the wiki for my NAS-as-Code project 👋

This project is the result of my journey to fully automate the build and management of my Home Server (NAS) using Infrastructure-as-Code principles. What started as an Azure DevOps experiment has evolved into a full GitHub-based CI/CD solution using Ansible and GitHub Actions.

📝 I'm planning a blog series on osotechie.com that will walk through this project in detail. This wiki serves as the living reference documentation alongside those posts.

What is this?

A single push to main provisions my entire NAS from scratch — packages, users, disks, shares, Docker, backups, the lot. No manual SSH, no clicking around, no "I'll remember how I set that up" (spoiler: I never do 😅).

The Two Repos

This project is split across two repositories:

Repo	Purpose
nas-as-code	OS-level provisioning — packages, users, disks, shares, services
nas-containers-as-code	Docker container stacks deployed over SSH

The nas-as-code repo (this one) is the foundational layer. It provisions the NAS to the point where it's ready to accept container workloads. The nas-containers-as-code repo then deploys all the Docker stacks on top.

🔗 Container deployment docs live in the nas-containers-as-code wiki.

Quick Links

• Architecture — how all the pieces fit together
• Secrets & Credentials — Azure KeyVault, GitHub secrets, token replacement
• Provisioning Pipeline — the GitHub Actions workflow that builds the NAS
• Day 2 Operations — adding disks, secrets, rebuilding

The Migration from Azure DevOps

This project originally lived in Azure DevOps as my first foray into DevOps automation. The migration to GitHub brought a few key improvements:

• Visibility — the repos are public, shareable, and now documented (you're reading it!)
• GitHub Actions — simpler YAML, better marketplace, native secret management
• Environment matrix — test and production environments with strategy-based deployment
• Community patterns — action pinning, Dependabot, and reusable workflows

The decision to keep two separate repos (rather than consolidating) came down to separation of concerns and independent deployment cadences. More on that in the Decision Log.