Tessera · Plattform-Infrastruktur
Aufbau, Kosten und der goldene Schnitt
Stand 2026-08-11 · Preise live von der Hetzner-API (nbg1) · aus dem Claude-Artefakt „Tessera — Infrastruktur, Kosten, USDC“.
Vier Bilder: was heute läuft, wohin es wächst, wie Nutzer in USDC bezahlen — und die eine Konstante, die Preis, Marge und Wachstum regiert.
01Heute — drei Maschinen, klare Rollen
Mit einer strukturellen Schwäche: auf der Forge-Box teilt sich die Build-Last die Maschine mit Seed und Registry. Die Härtungen vom 10./11.08. (Swap, mem-limit, Prune-Schwelle) federn das ab, lösen es aber nicht.
tessera-ci10,19 € / M
cx33 · 4 Kerne · 8 GB RAM · 75 GB
- ▪radicle-node —
seed.tessera.at, Quelle für Flux - ▪zot —
oci.tessera.at, alle Images - ▪Explorer, Suche, Caddy, restic stündlich
- ▪cib + buildah — Builds auf derselben Maschine
mosaik-cp-119,19 € / M
cx43 · 8 Kerne · 16 GB · Talos, Single-Node
- ▪tessera-web, -oidc, -pds, -registry, -index
- ▪ledger, skytess, cadence, start-complex
- ▪Flux zieht Manifeste vom Seed, Images aus zot
selfbot25,19 € / M
cax31 · 8 Kerne · 16 GB · ARM
- ▪Coolify: mbdrone, salzgrotte, murmel …
- ▪Media-Stack, Uptime Kuma
- ▪nicht Teil der Tessera-Kette
| Posten | Was | € / Monat |
|---|---|---|
| tessera-ci | cx33 — Forge + CI | 10,19 |
| mosaik-cp-1 | cx43 — Cluster | 19,19 |
| Volumes | 80 GB (PVCs + Snapshots) | ~4,20 |
| Primary IPs | 2 × IPv4 (Tessera-Anteil) | ~1,20 |
| Tessera gesamt | ~35 € | |
| selfbot | cax31 + 3 IPs — privat, getrennt gerechnet | ~27 € |
02Zielbild — Plattform für fremde Nutzer
Zwei Änderungen gegenüber heute, beide additiv: die Builds ziehen auf Wegwerf-VMs, und der Cluster wächst pro ~25–30 Mandanten-Apps um eine Worker-Node. Die Forge schrumpft, sobald die Builds weg sind — kein Schritt erfordert einen Umbau des vorherigen.
Forge (tessera-ci → cx23)6,59 € / M
cx23 reicht ohne Build-Last · wächst mit Storage, nicht Compute
- ▪Seed + Explorer — Quelle für Flux, bleibt langweilig
- ▪zot-Registry — per Volume erweiterbar
- ▪cib-Broker — nur Steuerung, baut nichts mehr selbst
Build-VM0,031 € / h
cx43 aus Snapshot · Boot ~30 s · Hard-Timeout · danach gelöscht
- ▪fremder Code auf Hardware, die danach nicht mehr existiert
- ▪kann nur die eigene VM zerlegen — geteilte Infrastruktur bleibt unberührbar
Warm-Pool: die VM lebt bis zum Ende ihrer bezahlten Stunde und nimmt weitere Builds an — Minutenwahrheit trotz Hetzner-Stundenabrechnung. 0 Builds = 0 €.
↓Manifeste + signierte Images
mosaik: cp-1 + Worker19,19 € / Node
~25–30 Mandanten-Apps je Worker (512 MB / 0,5-CPU-Klasse)
- ▪pro Mandant: Namespace + hartes ResourceQuota + NetworkPolicy
- ▪kein Tenant-Pod ohne Limits — technisch erzwungen, nicht vereinbart
- ▪Node dazu erst, wenn zahlende Nutzung sie füllt (Regel 2) · später: Worker auf Dedicated (AX42 ≈ 52 €) ≈ 4× Leistung pro Euro
| Stufe | Auslöser | Fix € / M | Variabel |
|---|---|---|---|
| Heute | nur eigene Apps | ~35 | — |
| Stufe 1 | erste externe Nutzerephemere Builder + Quotas + Alerting; Forge noch cx33 | ~35 | Builds nach Verbrauch |
| Stufe 1b | Forge auf cx23 verkleinert | ~31 | + Builds |
| Stufe 2 | Auslastung ≥ 61,8 % → 1. Worker | ~50 | + Builds |
| Stufe 3+ | Nodes entlang der Fibonacci-Folge | +19,19 / Node | + Builds |
| Später | ab ~3–4 Cloud-Nodes: Worker auf Dedicated | ≈ 52 / AX42 | + Builds |
Traffic: 20 TiB pro Server inklusive. Jede Stufe ist Erweiterung, keine Migration.
03Bezahlt wird in USDC — über Hyperliquid
Prepaid-Guthaben statt Rechnungen: kein Mahnwesen, kein Forderungsausfall. Die Identität selbst ist gratis und braucht keine Wallet — die Wallet-Pflicht steht erst vor den Ressourcen (Bauen, Hosten) und ist dort zugleich das Spam-Gate. Die Zahlungszuordnung existiert in Tessera schon: jede Identität kann ihre Wallet-Adresse registrieren.
Abgebucht wird täglich, abgerechnet im Zyklus — kein Kalendermonat. Die Zeitleiter ist dieselbe wie in den Boards: Minute → Tag → Sprint (14 Tage) → Zyklus (28 Tage, die Abrechnungseinheit) → Epoche (13 Zyklen). Der Kalender ist am Montag der ISO-KW1 verankert — der erste Abrechnungstag liegt oft noch im alten Kalenderjahr (Epoche 2026 beginnt am Mo 29.12.2025) — und Zyklus 13 schluckt den Jahresrest: in 53-Wochen-Jahren ist er 35 Tage lang, sein zweiter Sprint 21, und kostet dann ehrlich seine echte Länge. Anbieterpreise kommen in €/Monat und werden auf den Tag normiert: €/Monat · 12 ÷ 365,25.
Der Kreislauf
Nutzer lädt Guthaben auf.
USDC-Transfer auf der Hyperliquid-L1 an die eine Tessera-Treasury-Adresse — Transfers zwischen Hyperliquid-Konten sind gebührenfrei: $5 gesendet, $5 angekommen. Zuordnung über die Absenderadresse = die in der Tessera-Identität registrierte Wallet. Keine Deposit-Adressen-Infrastruktur nötig.
↓Hyperliquid Info-API / WebSocket
Eigener Watcher schreibt Guthaben gut.
Ein kleiner Listener (~200 Zeilen) sieht Ledger-Updates der Treasury, matcht den Absender aufs Tessera-Konto und bucht Micro-USD in die Plattform-Datenbank — dieselbe µ$-Einheit, in der die Zaps schon rechnen. Der interne Ledger ist die Wahrheit; die Chain ist nur der Zahlweg.
↓Guthaben am Konto
Gate: kein Guthaben, kein Build.
Der Broker prüft vor jedem Run Identität + Saldo. Nach dem Run kommt die Abrechnung maschinenlesbar zurück — der Preis ist ein Feedback-Signal, gegen das Build-Agenten optimieren. Saldo ≤ 0: Builds blocken sofort, Hosting bekommt 8 Tage Gnadenfrist, dann Scale-to-zero (nichts wird gelöscht).
{ "duration_s": 241,
"infra_usd_micro": 2500,
"fee_usd_micro": 1545,
"total_usd_micro": 4045 }↓µ$-Debits: infra + fee getrennt gebucht
Gegenrechnung auf der Betreiberseite.
Monatlich gebündelt: Hyperliquid → Arbitrum ($1 flat) → Börse (~0,2 %) → EUR → Hetzner-Rechnung. Die getrennte fee-Buchung macht den Rohertrag pro Monat direkt ablesbar — konsumierbar für die Ledger-App.
↺prepaid rein, verbrauchsgenau raus — der Kreislauf trägt sich ab dem ersten Nutzer
„Reicht noch bis …“
Hosting ist Reservierung: Tagespreis konstant → Saldo ÷ Tagesrate ist eine harte Untergrenze, auf den Tag genau.
Builds sind Verbrauch: geschätzt aus dem gleitenden Schnitt des letzten Sprints/Zyklus (µ$/Tag) — die Größenordnung entwarnt: ein Build ~0,4 ct gegen ~6,4 ct Hosting/Tag bei Tier 2.
Anzeige konservativ: „mindestens bis X (nur Hosting), bei deinem Build-Verhalten bis Y“.
Kein Überziehen möglich
Das Gate prüft vor jedem Build den Saldo — ein Build kann das Konto nie überziehen, nur der nächste wird verweigert.
Optional deckelt der User seine Builds pro Zyklus selbst: $1 $2 $3 $5 (Fibonacci) — dann ist auch der worst case exakt Hosting + Deckel, zugleich Schutz vor einer Amok laufenden Pipeline.
Saldo ≤ 0: Builds blocken sofort, Hosting 8 Tage Gnadenfrist, dann Scale-to-zero — nichts wird gelöscht.
Warum es sich trägt
38,2 % jedes Preises sind Marge (Regel 1) — bei 100 gehosteten Apps ~59 €/Zyklus Rohertrag, die Fixkosten sind allein davon gedeckt.
Die Identität ist gratis (ein Login-Nutzer kostet fast nichts) — Break-even tragen die Margen: ~55 gehostete Slots; Builds und Speicher-Stufen senken die Zahl.
Micropayments, für die Kartenzahlung zu teuer wäre (Stripe ≈ 30 ct + 2,9 %), sind auf Hyperliquid gebührenfrei.
Die ehrlichen Haken
Onboarding: Nutzer brauchen USDC auf Hyperliquid — für Krypto-Native trivial, sonst Reibung; Base als zweiter Zahlweg ist später nachrüstbar.
Offramp-Pflicht: Hetzner nimmt kein USDC — Börsen-Konto und monatlicher Tausch gehören zum Betrieb.
Steuern (AT): USDC-Einnahmen sind Umsatz zum Tageskurs, USt-pflichtig — von Tag eins in die Buchhaltung.
Kursrisiko klein, aber real: USDC-Depeg 2023 ist passiert — zügig offrampen, nicht horten.
04Das φ-Modell — wachsen wie ein Schneckenhaus
Eine einzige Konstante regiert Preis, Marge, Headroom, Ausbau-Trigger, Reserve, Tarif-Leiter und sogar die Anbieterwahl. Null willkürliche Parameter — und Selbstähnlichkeit: das System verhält sich bei 10 Nutzern wie bei 10 000, nur größer. Kein Wert wird je festgelegt; jeder wird aus drei öffentlichen Inputs berechnet: Anbieterpreisliste, φ, Fibonacci.
φ² = φ + 1 — das Neue ist die Summe des Bestehenden · 1/φ = φ − 1 ≈ 0,618
Der Preis ist der goldene Schnitt der Kosten
P = ⌈C · φ⌉ µ$ ⟹ Marge/Kosten = Kosten/Preis = 1/φ
Die Marge verhält sich zu den Kosten wie die Kosten zum Preis — der Preis ist wörtlich golden geschnitten. Margenanteil konstant 1/φ² ≈ 38,2 %. Weil P proportional zu C bleibt, optimiert jede Build-KI weiter exakt das Richtige: Verbrauch. C enthält den Build-Overhead; Aufrundung auf ganze µ$ gehört dem Betreiber.
Bei 1/φ Auslastung, in Fibonacci-Schritten
u ≥ 1/φ ≈ 61,8 % ⟹ nächste Kammer · Nodes ∈ {1, 2, 3, 5, 8, 13…}
Headroom damit immer 1/φ² ≈ 38,2 % — dieselbe Proportion wie die Marge. Jede Stufe ist ~φ-mal die vorige, und jede neue ist die Summe der beiden vorangegangenen: die Kammer-Rekursion des Nautilus. Bei Verdopplung der Nutzer trifft man eine Kaufentscheidung, nicht doppelt so viele.
Die Marge finanziert die nächste Kammer, bevor sie gebraucht wird
Ausbau nur wenn u ≥ 1/φ UND R ≥ K(nächste Stufe)
Zwei goldene Tore vor jeder Erweiterung: die aktuelle Kammer ist zu 61,8 % gefüllt und die Reserve deckt die nächste. Wachstum ist per Konstruktion vorfinanziert — nie Schulden, nie Vorleistung auf Verdacht. Entnahme im selben Schnitt: 61,8 % der Marge in die Reserve, 38,2 % an den Betreiber.
Identität gratis, bezahlt wird Fibonacci
Tiers: 1·2·3·5·8 × (256 MB / 0,25 CPU) · Aufladung: $5 $8 $13 $21 $34 $55
Das Konto selbst kostet nichts — wie bei Google, nur self-owned: ein reiner Login-Nutzer verbraucht fast nichts und ist der Trichter für „Login mit Tessera“. Bezahlt werden reservierte Ressourcen; Speicher über dem Gratis-Deckel (1 GB) und die eigene Domain als Handle sind die Premium-Stufen. Gnadenfrist 8 Tage, Squatting-Schutz technisch statt monetär.
Die Plattform ist ihr eigener erster Tenant
d = Σ Marge / F · Drift = |Σ infra-Buchungen − Anbieterrechnung| → 0
Eigene Apps zahlen denselben Preis ins selbe Ledger — keine versteckte Subvention. Live publiziert: Fixkosten F, Auslastung u, Deckungsgrad d (d ≥ 1 = die Plattform trägt sich; davor keine Entnahme), Reserve R und die Drift — weicht die Summe der infra-Buchungen von der echten Anbieterrechnung ab, ist das ein sichtbares Messproblem, bevor es ein Vertrauensproblem wird.
Der Anbieter ist eine Variable, kein Bekenntnis
C = min über Anbieter(p) · Wechsel, wenn p_neu ≤ p_alt / φ
C ist immer der günstigste verifizierte Anbieterpreis pro Einheiten-Klasse. Wird ein Anbieter um mehr als 1/φ günstiger (~38 %), ist der Wechsel Pflicht, darunter schützt die Hysterese vor Migrations-Churn. Weil P = ⌈C·φ⌉ gilt, geht jede Ersparnis per Formel an die Nutzer durch; halber Anbieterpreis halbiert F und M gleichermaßen, der Break-even in Stückzahlen bleibt.
Preistabelle
| Einheit | Kosten C | Preis P = ⌈C·φ⌉ | Marge (38,2 %) |
|---|---|---|---|
| Build-Minute (cx43, 8 Kerne)0,0307 €/h ÷ 60, via Warm-Pool | 0,051 ct | 0,083 ct | 0,032 ct |
| Typischer Build (4 min) | ~0,25 ct | ~0,40 ct | ~0,15 ct |
| Hosting-Slot 2er-Tier (512 MB / 0,5 CPU)19,19 € ÷ 30 Slots ÷ 1/φ-Packung, auf 28 Tage normiert | 0,95 € / Zyklus | 1,54 € / Zyklus | 0,59 € / Zyklus |
| 100 gehostete Apps | ~95 € / Zyklus | ~154 € / Zyklus | ~59 € / Zyklus |
Die Spirale
r(θ) = a · φ^(2θ/π) — jede Kammer ist eine Ausbaustufe
Gelesen als Plattform: jede Vierteldrehung ist eine Ausbaustufe (1 → 2 → 3 → 5 → 8 → 13 Nodes), betreten erst, wenn die aktuelle Kammer zu 61,8 % gefüllt und die nächste aus der Reserve bezahlt ist. Die Kurve sieht auf jeder Zoomstufe identisch aus — genau deshalb explodieren die Kosten nie: Wachstum hat bei jeder Größe dieselbe Form.
Ehrliche Fußnote: ob die Marge 1,3 oder φ beträgt, entscheidet kein Naturgesetz — φ ist eine gewählte Konvention. Ihr Wert liegt darin, dass eine Konstante alles regiert und nichts je „getunt“ werden muss. Zum Vergleich: GitHub Actions verlangt $0,008/min für 2 Kerne; Tessera verlangt mit voller φ-Marge $0,0008/min für 8 Kerne — ~40× besseres Preis-Leistungs-Verhältnis, die Marge ist für Nutzer unsichtbar.
Preise: Hetzner Cloud API, nbg1, 2026-08-11 · Volumes 0,052 €/GB·M · Dedicated-Preis (AX42) Näherung · Hyperliquid: L1-Transfers gebührenfrei, Withdrawal nach Arbitrum $1 flat · Steuer-/Rechtshinweise sind Orientierung, keine Beratung.