====== Cloud & Containerization ======

This page collects notes about cloud usage, Docker/Kubernetes, and how they fit with self-hosting.

===== When to Use the Cloud =====

From discussions, the main reasons to use cloud providers instead of only home servers:

  * **High availability**: you need uptime that survives home power or ISP failures.
  * **Global latency**: you have users spread across regions.
  * **Bandwidth**: your home upload bandwidth is too low.

Examples where cloud can make sense:

  * Public-facing APIs and websites.
  * Latency-sensitive services (e.g. game backends).
  * Off-site backups.

For purely personal or family tools (RSS, blog, small git hosting), many participants preferred **self-hosting at home** for privacy and cost reasons.

===== Docker and Compose =====

Key patterns around Docker:

  * Use **docker-compose** to describe services:
    * One `docker-compose.yml` per application stack.
    * Declare networks, volumes, environment variables explicitly.

  * Persist data in named volumes or host directories:
    * For databases: always mount `/var/lib/postgresql` (or equivalent) somewhere persistent.
    * Keep config files versioned in Git.

  * Common services containerized:
    * Reverse proxies (nginx, Traefik).
    * Databases (PostgreSQL, MariaDB).
    * Queue systems (Redis, RabbitMQ).
    * Web apps (Node.js, Python, Go, Rust).

===== Kubernetes: Use with Caution =====

Kubernetes was mentioned a few times, usually with a note of caution:

  * Powerful but heavy for small personal setups.
  * High cognitive overhead:
    * Pods, deployments, services, ingress, secrets, persistent volumes, etc.

General consensus from the tone of the discussions:

  * For **small-scale self-hosting**, Kubernetes is often overkill.
  * Prefer:
    * Simple Docker-Compose stacks.
    * Orchestrators like Nomad if you truly need scheduling.
    * Or even plain systemd services for a few long-lived daemons.

===== Good Practices for Cloud-Hosted Services =====

When you do host services in the cloud:

  * **Infrastructure as Code (IaC)**:
    * Use Terraform, Ansible, or similar to capture VM and network configuration.
    * Avoid hand-tuning servers with undocumented changes.

  * **Backups and secrets**:
    * Keep encrypted secrets (e.g. with Ansible Vault, sops).
    * Store backups in multiple regions if running in a single cloud vendor.

  * **Cost awareness**:
    * Watch for creeping costs: log storage, managed DBs, data transfer.
    * Use basic monitoring (Grafana/Prometheus, netdata, provider dashboards) to avoid surprises.