Files

T

jeffryandClaude Opus 5 cc66e227a3 the published surface, on a fresh root

This repository is now the public half of a split: six documents saying what to
decide, and one gap. How the cluster is built moved to jeffry/homelab-impl, which
is private because its README is an inventory of chart versions and image tags.

History starts here deliberately, and not as tidiness. The previous history
contained that inventory, and this repository is public — a deletion commit would
have removed it from the tree and left it in the log. A fresh root can only carry
what is in it.

Two pointers rewritten rather than deleted: private-access.md and .loom/README.md
both directed a reader to TAILSCALE.md and README.md at the root, which are now
private. They now say a fuller reference exists, that it is private, and how to
ask — because a public page naming a private thing as its answer is the failure
this project has now hit four times.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-07 15:19:14 -04:00

2.4 KiB

Raw Permalink Blame History

The git host

git.hypertheory-labs.dev, on the public internet, with a real certificate. This is where the loom/* repositories live.

SSH is on 2222, and it is not optional to know

Git-over-SSH does not pass through Traefik — it is raw TCP, on a LoadBalancer that binds a host port on every node. Port 22 is held by each node's own sshd, so the service is on 2222.

ssh://git@git.hypertheory-labs.dev:2222/<org>/<repo>.git

A clone URL without the port will not work, and the failure looks like an authentication problem rather than a wrong port.

ssh -T -p 2222 git@git.hypertheory-labs.dev     # "Hi there, <name>!" once a key is registered

Permission denied (publickey) from a node IP is the success case for an unregistered key — the server answered and offered its host key.

Registration is closed

One account. The anonymous landing page serves no sign-up link. If you need access, somebody creates it for you.

Two things that will surprise you

Sessions do not survive a restart. There is no Redis or valkey here — cache and session are in memory, deliberately. The queue is on disk and does survive. With one user this is nearly free; it stops being free if this ever grows real users.

If the control-plane node is down, this is down. The repository volume is pinned to it and cannot move. Postgres is unaffected — it replicates — but the git objects live on a volume that cannot be rescheduled. See storage.

Never pin the chart below what is deployed

Gitea does not migrate its schema backward. An older chart fails in the configure-gitea init container with "database is for a newer Gitea", the rollout hangs, and the old pod keeps serving.

Check helm history before setting a version. This has already happened once.

The container registry

Gitea has one. Access to it is not worked out, and that is an open problem rather than an omission — see gaps/.

Checking this is still true

Verified 2026-09-03, after a rebuild from scratch.

kubectl get svc gitea-ssh -n gitea         # EXTERNAL-IP = node IPs, 2222/TCP
kubectl get ingress -n gitea               # CLASS=traefik, git.hypertheory-labs.dev
curl -sS -o /dev/null -w "%{http_code}\n" https://git.hypertheory-labs.dev/

2.4 KiB Raw Permalink Blame History