How the servers run — from the URL you type to the page you see

LIVEIs everything up right now?

Each site is checked from the outside every 60 seconds. Full status page → status.bit-habit.com.

Loading live status…

10 SECONDSThe whole thing in one sentence

One small server runs every bit-habit.com website. You type an address, it finds the right app, and sends the page back.

Want to know how it picks "the right app"? Keep reading.

1 MINUTEWhat happens when you open startpage.bit-habit.com

Follow one request from your browser to the page. Six steps.

1. Find the server. Your browser asks DNS "where is this address?" Every *.bit-habit.com name points to one server IP: 158.180.71.122.
2. Knock on the front door. The request arrives at Traefik — the program that receives every request, listening on ports 80 and 443.
3. Force HTTPS. If you came on plain http (port 80), Traefik sends you to secure https (port 443). It's a permanent redirect (status 308).
4. Lock the connection. Traefik proves the site is genuine with its certificate — that's the padlock in your browser bar.
5. Route to the app. Traefik reads the address startpage.bit-habit.com and forwards the request to the matching app.
6. Answer. The startpage app builds the page and sends it back. Done.

5 MINUTESThe parts, named — and what's running

The server runs k3s, a small version of Kubernetes. Kubernetes is just a manager that starts apps, restarts them if they crash, and routes traffic to them. Here are its parts, in plain terms.

And here is how those parts connect for a single app — a Deployment keeps Pods running, a Service gives them one address, an Ingress maps the hostname to that Service, and Traefik (with a cert from cert-manager) is the door:

What's running here

About 20 apps share this one server. A few you can visit:

DEPLOYSThe other direction — how the code gets here

Everything above follows a request inward: browser → Traefik → app. This section follows code outward: laptop → GitHub → server → live. It is the half of the story people most often guess wrong.

Following one git push

1. You push to main.
2. GitHub Actions wakes up and opens an SSH connection to the server, using a deploy key kept as a repository secret.
3. The server ignores what Actions asked for. That key is pinned in authorized_keys with a forced command: no matter what command arrives, only one script runs. Even a leaked key can do nothing else on the box.
4. The script pulls the repo (git reset --hard origin/main — an exact mirror, so the server never drifts).
5. It is already live. nginx serves that folder straight off the disk (a hostPath mount), so there is no image to build and no Pod to restart. About ten seconds, end to end.

Two layers, deployed differently

It matters which of these you changed — they do not travel the same road.

Three repos ship themselves this way today:

TODAYWhere every setting actually lives

A fair question to ask of any platform: is the whole thing in one git repo? Almost. Every service that matters is in git — either this repo, or its own. What is left over is small, and worth naming precisely rather than worrying about.

The cluster, right now

PATHSEvery config, and exactly where it lives

"Where is that configured?" is the question you actually ask at 2am. There are three places a setting can live here, and only one of them is this git repo. Here is all three, with real paths.

1 · In this git repo

On GitHub as bookseal/bit-habit-infra, checked out on the server at /home/ubuntu/workspace/bit-habit-infra.

2 · In the app's own git repo

Two services keep their Kubernetes manifests next to their code, and deploy themselves. This is a normal, defensible layout — the service stays self-contained, at the cost of this repo no longer being the complete picture.

3 · On the host — k3s's own directories

These are not in the repo, and mostly cannot be. They belong to k3s itself.

And the leftovers

GITOPSArgoCD — the idea, and what it would actually take

GitOps is one idea in one sentence: put the desired state in git, and let a program inside the cluster continuously make reality match it. That's it. ArgoCD is the most common program for doing that. Here is what changes, and what it would cost here.

The one thing that changes: push becomes pull

Today, everything pushes into the cluster from outside — GitHub Actions SSHes in, or a human runs kubectl apply. The cluster is passive; it never looks at git. GitOps inverts that: a controller runs inside the cluster and pulls from git forever.

The loop, precisely

What installing it actually looks like

Five commands. The wildcard DNS and certificate already cover a new subdomain, so the UI is reachable with no DNS or TLS work.

# 1. a namespace to live in
kubectl create namespace argocd

# 2. install ArgoCD itself (one big official manifest)
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 3. let Traefik handle TLS, so ArgoCD serves plain http internally
kubectl -n argocd patch deployment argocd-server --type json \
  -p '[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--insecure"}]'

# 4. route argocd.bit-habit.com to it (wildcard cert already covers this name)
kubectl apply -f apps/argocd/ingress.yaml

# 5. tell ArgoCD which repo and paths to watch — this file already exists
kubectl apply -f apps/argocd/application.yaml

Step 5 is the whole idea, and it is already written in this repo:

spec:
  source:
    repoURL: https://github.com/bookseal/bit-habit-infra.git
    targetRevision: main        # watch the main branch
    path: base                  # watch this folder
  syncPolicy:
    automated:
      prune: false              # do NOT delete things removed from git (safety)
      selfHeal: true            # DO undo hand-edits made in the cluster

THE GAPWhat to grow, in order

Honest scorecard: what this platform would need before GitOps is even possible, ranked by what actually matters. There is exactly one real blocker, and it is not the services — it is the secrets.

WORDSEvery term on this page, in plain language

This page uses jargon that sounds like it assumes you already know it. You don't have to. Here is every word, defined once, with where it actually shows up here.

1 HOURGo deeper

How a new site gets added

1. Put the app in the cluster — a small Deployment (the app) and a Service (its inside address).
2. Add one line to the routing list — an Ingress rule: newsite.bit-habit.com → that Service.
3. Apply it (kubectl apply). That's all: the wildcard DNS and wildcard certificate already cover the new subdomain, so it's reachable over HTTPS right away.

See the real configs

It is all plain YAML in the public repo. A whole small app is often just this:

apiVersion: apps/v1
kind: Deployment            # keep N copies of my app running
metadata: { name: myapp }
spec:
  replicas: 1
  selector: { matchLabels: { app: myapp } }
  template:
    metadata: { labels: { app: myapp } }
    spec:
      containers:
        - name: web
          image: nginx:alpine
---
apiVersion: v1
kind: Service               # one stable address for those copies
metadata: { name: myapp-svc }
spec:
  selector: { app: myapp }
  ports: [{ port: 80, targetPort: 80 }]

The key files that run this platform (click to view on GitHub):

Go further

• Live status (anyone): status.bit-habit.com — every site's up/down and response time, checked from the outside.
• Deep view (operators): headlamp.bit-habit.com — real pods, logs, and resource use (sign-in required).
• Source: github.com/bookseal/bit-habit-infra — every manifest and setting.

● Open the full status page →