VPS-Infrastruktur-Blueprint

              ░░░░░░░░░░░░
         ░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒░
       ▒▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▒
      ▒▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒
      ▒▓▒▒▒▒▓▓▓▓▓▓▓▒▓▓▓▓▒▒█▒▒▒▒▒▓▒
      ▒▓▒▒▒▒▒▓▓▓▓▓██▓▒▒▓█▒█▓▒▒▒▒▓▒
      ▒▓▒▒▒▒▓█▓▓▓▓▒██▒▒▓█▒█▓▒▒▒▒▓▒
       ▒▓▓▓▒▓▓▓▓▓▓▓▒▓▓▓█▓▒████▓▓▒
         ░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒░
       ░      ░░░░░░░░░░░░      ░
      ▒▓░                      ░▓▒
      ▒▓▓▓▒░░░            ░░░▒▓▓▓▒
      ▒▓▒▒▒▓▓▓▓▓▓▒▒▒▒▒▒▓▓▓▓▓▓▒▒▒▓▒
      ░▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓░
        ░▒▒▓▓▓▓▓▓▓▒▒▒▒▓▓▓▓▓▓▓▒▒░
             ░░░▒▒▒▒▒▒▒▒░░░
      ▒▓░                      ░▓▒
      ▒▓▓▒░░                ░░▒▓▓▒
       ░▒▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▒░
          ░░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▒▒░░

              ▓▓▓▓▓▓▓▓▓▓▓▓
         ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
         ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓      ▓▓▓▓▓▓▓▓▓▓▓▓      ▓
      ▓▓▓                      ▓▓▓
      ▓▓▓▓▓▓▓▓            ▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
             ▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓                      ▓▓▓
      ▓▓▓▓▓▓                ▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
          ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

Der VPS begann als funktionierender Host und wurde zu einem reproduzierbaren System. Der Blueprint zeichnet auf, was eine einzelne Installation überdauern muss: Grenzen zwischen öffentlichen und privaten Diensten, Speicherrollen, aktivierte Units, Deployment-Annahmen und die Tests, die das korrekte Verhalten einer rekonstruierten Maschine belegen.

Problem

Ein laufender Server ist nicht seine eigene Dokumentation. Konfiguration kann abweichen, Laufzeitzustand kann wichtige Annahmen verbergen und eine Disk-Kopie erklärt nicht, weshalb ein Dienst exponiert oder isoliert ist.

Gestaltung

• das Ziel inventarisieren, bevor Datenträger oder Mounts ausgewählt werden
• Dienstverhalten bewahren, statt Kennungen einer einzelnen Maschine fest einzuprogrammieren
• Quellcode und Wiederaufbau-Anleitungen in privaten Forgejo-Repositories halten
• allgemeine Host-Topologie von der auslieferbaren Medienimplementierung trennen
• Mounts, Listener, Dienste und öffentliche Routen nach Änderungen validieren
• statische Websites aus versionierten Releases bereitstellen, die ein atomarer Symlink auswählt
• die für Produktion kanonische Ausgabe auf einem öffentlichen Vorschau-Host mit ausdrücklichem noindex testen

Grenze der statischen Kante

Die Portfolio-Auslieferung wird als Caddy-Konfiguration deklariert und nicht als erinnerter Serverzustand behandelt. Produktion und Vorschau verwenden dasselbe gebaute Artefakt, während der Vorschau-Host sein eigenes Indexierungsverbot ergänzt. Restriktive Response-Header, inhaltsspezifisches Caching, echte Fehlerantworten auf sensible Anfragen und ein aufbewahrtes vorheriges Release schaffen ein prüfbares Deployment- und Rollback-Modell.

Die Verifizierung der Search-Console-Inhaberschaft ist bewusst auf die kanonische HTTPS-Apex-Domain beschränkt. Sie erweitert weder Indexierung noch Verifizierung auf Dienst-Subdomains.

Eine Produktionskorrektur als Wiederaufbaubeleg

Eine aktuelle Korrektur der Medienaufnahme hat dasselbe Modell an einem zustandsbehafteten Dienst angewendet. Vor der Änderung eines einzelnen Klassifizierers wurden das aktive Skript, die Unit und die betroffenen Stream-/Sidecar-Paare in einem nur für root lesbaren Snapshot gesichert. Der Ersatz wurde syntaktisch geprüft, durch gezielte Dateinamentests abgedeckt, mit dem deklarierten Besitzer und Modus installiert, unabhängig neu gestartet und sowohl anhand seiner Live-Prüfsumme als auch anhand der resultierenden Jellyfin-Eintragszahlen verifiziert. Danach wurden die exakt ausgelieferte Revision und die aktualisierte Herkunftsdokumentation zu Forgejo übertragen.

Diese Abfolge ist wichtiger als die Grösse des Patches. Selbst eine kleine Namenskorrektur kann Bibliotheksidentität, Metadatengruppierung und sichtbare Karten verändern. Der Blueprint behandelt deshalb Anwendungsdateien und den betroffenen Zustand als gemeinsame Änderungsgrenze, während unabhängige Dienste, Mounts und öffentliche Routen ausserhalb des Eingriffs bleiben.

Ergebnis

Der Host lässt sich als eine Menge deklarierter Verantwortlichkeiten verstehen statt als Sammlung erinnerter Shell-Befehle. Der Bridge-Arbeitsbereich trägt den Wiederherstellungskontext, Forgejo bewahrt die Projektgeschichte und der laufende VPS bleibt ein Deployment-Ziel statt der einzigen Quelle der Wahrheit.

Mögliches Nebenprojekt: IRC-gestützte Sprachräume

Ein künftiges Experiment könnte das selbst gehostete IRC-Netz um einen leichtgewichtigen Mumble-Sprachdienst erweitern. Dauerhafter Text bliebe in IRC und ZNC; Mumble würde latenzarme, jederzeit verfügbare Sprachräume für Freunde bereitstellen. Eine schmale Bridge könnte genau einen IRC-Kanal mit genau einem Mumble-Raum für Text und optionale Anwesenheitsmeldungen verbinden, ohne private Nachrichten, Audio oder administrative Befehle zu vermischen.

Die nützliche Form bleibt bewusst klein: eine Einladungsseite, ein Mumble-Link mit einem Klick, gültiges TLS, Rollen für Gäste, Freunde und Operatoren, eine öffentliche Lobby und private Freundeskanäle. Die Bridge würde Mumbles Ice-Schnittstelle nur über Loopback, mit eigenem Secret und strikter Ratenbegrenzung verwenden. Dies ist als mögliches Nebenprojekt dokumentiert, nicht als bereitgestellter Dienst oder verbindlicher Roadmap-Punkt.

Erkenntnis

Reproduzierbarkeit ist mehr als Installationsautomatisierung. Ein nützlicher Blueprint dokumentiert ebenfalls Vertrauensgrenzen, die Bedeutung von Fehlern, Abnahmetests und alles, was nie öffentlich werden darf.