📖 Chapter 10 — Cloud Services

The cloud as part of the system. Not instead of the NAS — alongside it.

Learning Objectives

• Define the role of cloud services in a home infrastructure
• Choose between hybrid, cloud-only, and local-only architectures
• Set up Cloudflare Tunnel for public-facing services
• Use cloud storage (Backblaze B2, Wasabi, S3) for cold archive and offsite backup
• Know when cloud makes sense and when it doesn't

Introduction

The conversation was clear: the home lab is the primary platform, but the cloud is part of the system. The cloud isn't a replacement for the NAS; it's a complement. Specific workloads belong in the cloud (cold archive, public services, GPU training). Specific workloads belong on the NAS (active projects, family data, low-latency access). The chapter is about which is which, and how to wire them together.

The hybrid model

For TK's build, the architecture is hybrid: the NAS is the source of truth, the cloud is the offsite backup, the public face, and the burst-compute extension. The split:

• On the NAS: all primary data, all running services, the family experience, the creator's active projects, the lab's VMs and containers.
• In the cloud: the offsite backup (Backblaze B2), the public-facing services (Cloudflare Tunnel), the burst GPU when needed (Vast.ai, RunPod), the domain DNS (Cloudflare), the email (if needed), the password manager's emergency access.

The pattern: local is the working copy, cloud is the safety net and the public face. Never the other way around (no "the cloud is the primary, the NAS is the cache" — the latency and the cost rule that out for family-sized use).

When to use cloud

Use the cloud for:

• Offsite backup. The cheapest insurance against fire, flood, theft. ~$6/TB/month at Backblaze B2, less for Glacier. For TK's Media/Archive (5-10 TB), the cost is $30-60/month.
• Public-facing services. Anything the world needs to reach (a family blog, a project website for a client, a public dashboard). Cloudflare Tunnel gives you a public URL without exposing the NAS.
• Burst compute. AI/ML training that needs a GPU for a few hours. Vast.ai, RunPod, Lambda Labs rent GPUs for $0.50-2/hour. Cheaper than buying a $2000 GPU you'll use 10 hours a year.
• Domain DNS. Cloudflare is the de facto standard. Free tier covers homelab use.
• Email. A small VPS or a service like Proton Mail or Fastmail is easier than running Postfix on the NAS.
• Out-of-band access. If the home network is down, cloud services (Tailscale's coordination server, Cloudflare's DNS) are still reachable.

When NOT to use cloud

Don't use the cloud for:

• Primary family data. Photos, videos, documents. The latency (especially for video) is too high; the ongoing cost is too high; the privacy is questionable.
• Active creative projects. The DaVinci Resolve timeline, the Premiere project, the Logic session. These need 100+ MB/s sustained; cloud storage doesn't deliver that.
• Lab state. The running VMs, the in-flight experiments, the data being processed. These belong on local fast storage.
• Anything privacy-sensitive that the family uses. The family photos are family photos. Putting them in someone else's cloud is a different privacy posture than keeping them at home.

The principle: the data you can lose is fine in the cloud; the data you can't lose is local-first. The cloud is a copy, not the source.

Cloudflare Tunnel (the public face)

From Volume 1, Chapter 8: Tailscale is the right way to access the NAS remotely. But for public-facing services (a project website, a public Jellyfin for a friend, a personal blog), Cloudflare Tunnel is the right answer.

The setup:

1. Sign up at cloudflare.com. Add your domain (e.g., aidalee.com).
2. Install cloudflared on the NAS (or on a small VPS).
3. Authenticate: cloudflared tunnel login.
4. Create a tunnel: cloudflared tunnel create homelab.
5. Configure the tunnel to route traffic: cloudflared tunnel route dns homelab project.aidalee.com.
6. Add the tunnel as a service: a config file that maps public hostnames to local services.

The pattern: a YAML config file that looks like:

tunnel: homelab
credentials-file: /root/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: project.aidalee.com
    service: http://localhost:8080
  - hostname: dashboard.aidalee.com
    service: http://localhost:3001
  - service: http_status:404

Each public hostname is routed to a local service. Cloudflare handles TLS, DDoS protection, and the public DNS. The NAS doesn't need any ports open to the internet.

Cloudflare Access (authentication)

For services you want public but authenticated (a family blog with login, a private dashboard, an internal tool), Cloudflare Access adds a login wall. Free for up to 50 users.

The setup: in the Cloudflare Zero Trust dashboard, add an application, configure the access policy (which emails, which identity providers — Google, GitHub, etc.), and the service is wrapped in a login.

Use case: TK's data science dashboard, the Immich admin panel, a personal Grafana instance. The dashboard is reachable at a public URL, but you have to log in with your Google account first.

Cold archive in Backblaze B2

From Volume 6, Chapter 1: the offsite backup. For the Media/Archive (creator's cold archive), the right answer is Backblaze B2. The setup:

1. Sign up at backblaze.com. Create a B2 bucket.
2. Generate an application key (the credentials for rclone or the TrueNAS cloud sync task).
3. Configure a TrueNAS Cloud Sync Task: source tank/Media/Archive, destination the B2 bucket, schedule weekly or monthly.
4. Enable B2's "Lifecycle Rules" to move files older than 90 days to a cheaper storage class (if you don't need fast access).

Cost: $6/TB/month for hot storage, $1.50/TB/month for cold. For 5 TB of media archive, $30/month hot or $7.50/month cold. The recovery time is minutes from hot, hours from cold.

For TK's archive, hot is fine; the family might want to retrieve an old project. The $30/month is worth the fast recovery.

The "S3-compatible" pattern

Backblaze B2, Wasabi, AWS S3, MinIO (self-hosted) all speak the S3 API. The tools that work with one work with all. The pattern:

• rclone for one-off syncs and mounts
• TrueNAS Cloud Sync Tasks for scheduled backups
• MinIO (self-hosted S3) if you want S3 without the cloud (useful for app data, the data science stack, the lab's internal storage)

For most home labs, the S3-compatible tools are enough; you don't need to learn the cloud-specific APIs.

Burst GPU in the cloud

For AI/ML training that needs a GPU, the cloud is the right answer for occasional workloads. The pattern:

1. Set up a training script that runs in a container.
2. Push the container to Docker Hub (or GHCR).
3. Sign up at Vast.ai, RunPod, or Lambda Labs.
4. Spin up a GPU instance (RTX 4090, A100, H100) for the duration of the training.
5. Pull the data from B2 (or from the NAS via Tailscale), run the training, push the results back.
6. Shut down the instance.

Cost: $0.50-2/hour for a mid-range GPU, more for the high-end. For a 4-hour training run on an RTX 4090, ~$5. The cost of the same training on a $2000 GPU you'd use 10 hours a year: $200 amortized over 10 hours = $20/hour. The cloud is cheaper for occasional use.

The "what about a VPS" question

A VPS (Virtual Private Server) is a small cloud machine. The use cases for a home lab:

• Out-of-band access. A tiny VPS (1 vCPU, 1 GB RAM, $5/month) running Tailscale's coordination if the home network is down.
• Public services that don't fit on the NAS. A blog, a Mastodon instance, a small game server.
• Lightweight always-on services. A monitoring endpoint, a DNS updater, a Wireguard hub.

For most home labs, a single small VPS is enough. Oracle Cloud's free tier (4 vCPU, 24 GB RAM, forever) is a popular choice. Hetzner, DigitalOcean, Vultr are the standard providers.

Cost budgeting

For TK's hybrid setup, a realistic monthly budget:

For a hybrid home lab that includes offsite backup, public services, and burst GPU, $65-85/month is the realistic cost. The trade-off: cheaper than the equivalent on-premises hardware, with the cloud's flexibility.

The "lock-in" question

Cloud services have lock-in: the data, the tools, the integrations are easier to keep on the same cloud than to move. The mitigations:

• Use S3-compatible storage (B2, Wasabi, MinIO). Moving between providers is a config change, not a data migration.
• Use open standards (CalDAV, CardDAV, IMAP, Syncthing, rclone, restic). Avoid the proprietary sync clients (Google Drive, Dropbox, OneDrive) for the primary data.
• Self-host what you can. Tailscale beats Cisco AnyConnect. Vaultwarden beats LastPass. Immich beats Google Photos. The more you self-host, the less the cloud owns your workflow.

The principle: use the cloud for what it's good at (offsite, public, burst); self-host for what you can. Don't outsource the things you can do at home; do outsource the things you can't.

Engineering Note

Summary

The cloud as part of the system. Hybrid architecture: local is primary, cloud is offsite and public. Cloudflare for DNS, Tunnel, and Access. Backblaze B2 for cold archive. Vast.ai or RunPod for burst GPU. A small VPS for out-of-band access. Budget $65-85/month for the realistic hybrid setup. Use S3-compatible storage and open standards to avoid lock-in. The cloud is a complement, not a replacement.

Checklist

• ⬜ Set up Cloudflare DNS for your domain
• ⬜ Install cloudflared on the NAS; create a tunnel
• ⬜ Route any public-facing services through the tunnel
• ⬜ Add Cloudflare Access for any service that needs authentication
• ⬜ Set up Backblaze B2 (or similar) for offsite backup
• ⬜ Configure TrueNAS Cloud Sync Tasks for the cold archive
• ⬜ Sign up for a burst-GPU provider (Vast.ai / RunPod) if you'll train models
• ⬜ Monthly: review the cloud bill; check for runaway services

Volume 4 is complete

The lab as a system, networking, virtualization, Docker, VMs, reverse proxies, monitoring, home automation, when to expand, cloud services. The home lab is now a complete platform. Volume 5 is the data scientist's perspective on the same infrastructure: Jupyter, data formats, pipelines, ML, sharing, remote development, reproducibility.

Ch 10 · v0.1 · drafted from the original ChatGPT conversation, July 2026