TODO — Set Up Rancher (Later)

Status: Deferred — cluster is running fine without this for now Context: The router-africa-prod K3s cluster on the [redacted] Droplet ([redacted-ip]) was deployed without Rancher, since no Rancher server existed yet. This doc picks up that thread whenever you’re ready.

---

Why this is worth doing eventually

Rancher gives you a management UI on top of the K3s cluster already running: cluster-wide monitoring (CPU/memory across nodes and pods without installing anything extra), a visual view of deployments/pods/logs instead of kubectl commands, and — most relevantly for Router.Africa’s growth — a much easier path to horizontal scaling later (Rancher’s UI over Kubernetes’ native autoscaling, rather than hand-editing YAML). None of this is required for Bifrost to run; it’s an operational convenience layer.

---

Step 1 — Decide where Rancher itself runs

Rancher needs its own compute — it shouldn’t run on the same Droplet as Bifrost/K3s/Postgres, since that box is already sized tightly for just that workload. Options:

• A new, small dedicated Droplet for Rancher (2GB+ RAM recommended for Rancher itself)
• An existing box elsewhere if you have spare capacity
• A managed Kubernetes service (e.g. DOKS) if you’d rather not manage the underlying OS for Rancher’s own host

Whichever you choose, treat this as a separate piece of infrastructure from the Router.Africa gateway cluster — don’t consolidate them onto one node.

---

Step 2 — Install Rancher

On the dedicated Rancher server, the fastest path is the official Docker quickstart (fine for getting started; move to a proper HA Helm install before relying on it for production):

docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  --privileged \
  rancher/rancher:latest

Once it’s up, get the bootstrap password:

docker logs <container-id> 2>&1 | grep "Bootstrap Password:"

Log into the Rancher UI at https://<rancher-server-ip>, complete the initial setup (set a real admin password, confirm the server URL).

For a production-grade install instead of the quickstart, use Rancher’s Helm chart on its own small Kubernetes cluster (K3s works fine for this too) — check Rancher’s current docs for the Helm install steps at that point, since chart versions and values shift over time.

---

Step 3 — Import the existing Router.Africa cluster

Once Rancher is running:

1. In the Rancher UI: Cluster Management → Import Existing → Generic
2. Name it (e.g. router-africa-prod)
3. Rancher generates a kubectl apply command with a registration URL + one-time token — copy it exactly from the UI (don’t reuse an old one, tokens are single-use/time-limited)
4. Run it on the [redacted] Droplet, where kubectl is already configured:

   curl --insecure -sfL https://<your-rancher-server>/v3/import/<token>.yaml | kubectl apply -f -

5. Back in the Rancher UI, wait for the cluster to show Active

From that point on, you can manage the cluster either via kubectl/helm directly on the Droplet (as we’ve been doing) or through the Rancher UI — both control the same cluster.

---

Step 4 — What to revisit once Rancher is in place

• Cluster monitoring — enable it under Cluster → Monitoring in the Rancher UI for CPU/memory visibility without extra setup
• Scaling — once additional nodes are added to the cluster (more Droplets or a managed node pool), Rancher’s UI is the easier place to configure autoscaling than hand-editing Helm values directly
• Access control — if others on the team need cluster access, Rancher’s RBAC/user management is a much friendlier layer than sharing kubectl config files directly

---

Not blocking anything today

The Router.Africa Bifrost deployment on [redacted] runs fully via kubectl/helm without Rancher — this is a “nice to have later” layer, not a dependency. Pick this up whenever there’s a natural moment (e.g. when a second node/Droplet gets added, or when someone else on the team needs cluster visibility without shell access).