cloud-host

Modelle, Apps, Agenten, Harnesses und Abrechnung als sieben getrennte Ebenen verstehen. Der Atlas ordnet Ollama, ChatGPT, Codex, Claude und Gemini ein, erklärt lokale und cloudbasierte Inferenz, Multi-Agent-Arbeit, Hardware, Memory, RAG, Skills und MCP.

Wozu: eine belastbare Auswahl für den eigenen Entwickleralltag treffen. Mit Kompatibilitätsmatrix, Kostenbeispielen, Datenschutz-Check, Quellenverzeichnis und konkreter Einordnung für Windows, WSL2, IntelliJ und Java-Projekte.

Der breite Vergleich von Anthropic, OpenAI, Google und Ollama: Modellfamilien, Apps und Coding-Harnesses, Abos gegen API-Abrechnung, Kontextfenster, Token- und Cachekosten, Denkmodi sowie Bild- und Videomodelle.

Wozu: Produkte und Tariflogik nebeneinander nachschlagen, Kostenfallen erkennen und Tokenverbrauch senken. Zusätzlich mit Cursor, Copilot, Perplexity, Grok, Buzz, Hermes Agent und einem alphabetischen Glossar.

Was würde sich ändern, wenn die acht Spring-Boot-Dienste als Jakarta-EE-Anwendungen auf Open Liberty liefen? WebSphere traditional gegen Liberty, server.xml und Features, JNDI, Sicherheit und MP JWT mit demselben Keycloak, die Übersetzung Baustein für Baustein, Source-to-Image, ImageStreams und den konkreten Pilotumbau von catalog-service.

Wozu: Der gemessene Engpass des bestehenden Stacks waren acht JVM-Kaltstarts. Liberty hat ein anderes Startprofil – die Seite läuft auf die Frage hinaus, ob die gestaffelte Reihenfolge dann noch nötig wäre. Werte zum bestehenden Stack sind gemessen, alle Liberty-Zahlen ausdrücklich als Schätzung gekennzeichnet.

Die einzige Seite ohne einen einzigen Befehl. Netz und Ports, Deployment, Ablauf, Zustände, Datenhoheit – erst für die Hetzner-Landschaft, dann für den CRC-Cluster mit der Bibliothek darauf. Zuletzt die Bauteile von innen: Container gegen VM, Image und Schichten, Docker gegen Podman, Compose gegen Kubernetes, Kubernetes von innen, Registries, Ingress/Route, ConfigMap/Secret, Helm, Jenkins, Git, Kafka, Keycloak, JWT, DNS, TLS – und zuletzt vier zum Nachschlagen: wo die Zeit hingeht (mit den gemessenen Werten), was welchen Neustart überlebt, welches Fehlerbild wohin zeigt, und wo ein Passwort überall liegt.

Wozu: das Ganze sehen, statt es aus vierunddreißig Anleitungen zusammensetzen zu müssen. Farbe trägt Bedeutung – derselbe Ton heißt überall dasselbe. Enthält auch die Zeichnung, die den Doppelausleih-Fehler erklärt: vorher Lesen-Prüfen-Schreiben, nachher ein bedingtes UPDATE.

Rahmen: was das für die Rolle des Cloud-Host bedeutet – wissen, tun, betreiben – sortiert DevOps mit OpenShift: die Rolle des Cloud-Host.

Fortsetzung: die OpenShift-Themen führt der OpenShift-Atlas weiter – eigene Nummerierung, 65 Diagramme, EX280-Deckungsmatrix, inzwischen mit zweiundzwanzig Hands-on-Anleitungen darunter Konfiguration nachschauen, Project/oc/ServiceAccount, RBAC/SCC, Helm, Secrets, NetworkPolicy, Service/Route/Probes, die Build-Kette, OLM, Operator-Reconcile/Service-CA, Cluster-Betrieb, Logging/MCO/etcd, OVN/Router/Mesh, S2I bis Rollout, SNO/CRC/Deploy-Weg, Workload-Feinschliff, Kern/Auth, Tekton, GitOps, Legacy-Modernisierung, Middleware und SPA-Frontend.

Der Rahmen über allen OpenShift-Anleitungen dieser Sammlung: was der Cloud-Host wissen, tun und dauerhaft betreiben muss – als sortierte Landkarte mit Verweisen, nicht als weitere Einzelanleitung. Dazu ein eigener Abschnitt zum Zusammenspiel mit dem Entwickler-Team bei einer neuen Anwendung (wer liefert was, wer ist im Ernstfall zuständig), ein durchgängiges Beispiel von Build über GitOps und Operator bis Backup, plus Checklisten für Einstieg, Alltag und Notfall.

Wozu: zuerst hier lesen, dann gezielt in die passende Tiefenanleitung springen – statt sich aus zweiundzwanzig Einzelseiten selbst eine Reihenfolge zu bauen.

Fortsetzung der Diagrammserie, eigene Nummerierung: OpenShift wirklich verstehen, Breite zuerst. Blöcke 0 und A–J – Fundament, Workloads, Build-Kette, Operatoren, CI/CD, Netz, Betrieb, Legacy-Migration, Middleware, Frontend. Jedes Thema mindestens ein Inline-SVG mit Kreuzverweisen und projektverankerten Punkten.

Wozu: die EX280-Themen und der Bibliothek-Betrieb an einem Ort, als Landkarte. Mit Deckungsmatrix, Fortschritts-Stolperdraht und Rail je Block. Plan und Regeln am Seitenende.

Den Hetzner-SNO-Aufbau aus den Installationsskripten ableiten, CRC sicher vermessen und den realen Weg von Git über lokalen Jenkins und Tailscale bis zu den laufenden Pods mit ausschließlich lesenden Statusabfragen inventarisieren.

Wozu: zwei OpenShift-Cluster sicher auseinanderhalten, Ein-Node-Grenzen richtig einordnen und Fehler zuerst der passenden Schicht Laptop, Tunnel, CI oder Cluster zuordnen.

Der einmalige Teil, den alle anderen Anleitungen voraussetzen: Konto & 2FA, API-Token, hcloud CLI (Command-Line Interface), SSH-Key, Firewall-Prinzip, cloud-init-Grundmuster, die Skripte konfigurieren.

Wozu: steht einmal hier statt in jeder Anleitung. Die Dienst-Guides zeigen dann nur noch ihren eigenen Teil. Abbau/Kill-Switch: Server-Snapshot & Restore.

Alles aus den Anleitungen im Webpanel statt per hcloud: Projekt ≠ Server erklärt, der Server-Wizard Feld für Feld, Firewall/Netzwerk/Volumes/Snapshots, Server verwalten, Kosten.

Wozu: nachschlagen, wo im Panel was liegt – plus die Projekt-Strategie (prod / staging / eigenes Projekt für Wegwerf-Server).

Tarifwahl, Customer Control Panel, Server Control Panel, Netzwerk, Firewall, eigene Images und ISO-Dateien, Snapshots, OAuth-basierte REST-API und die andere Vertragslogik verständlich nebeneinander. Die mitgelieferten PowerShell-Werkzeuge automatisieren vorhandene Server, Stromzustand und Snapshots.

Wozu: die vorhandenen Hetzner-Anleitungen korrekt auf Netcup übertragen, ohne Hetzners Lösch-/Snapshot-Modell oder Cloud-API fälschlich vorauszusetzen.

Was stehen muss, bevor ein Dienst dauerhaft läuft: 2FA, Tailscale, Backups außer Haus, Monitoring, Log-Limits, DNS/DMARC, Impressum, Recovery-Zugänge.

Wozu: die kurze Liste gegen die typischen Anfangsfehler – einmal durchgehen und abhaken.

Server sauber stoppen → Snapshot → löschen → identisch neu aufbauen. Was sich ändert (die IP!), feste Primary IP (Internet Protocol) oder Dynamic DNS (cf-dns.ps1), und die vier Kill-Switch-Ebenen für den Kostenschutz.

Wozu: nur zeitweise gebraucht – ~0,30 €/Monat für den Snapshot statt ~8 für den laufenden Server. scripts/snapshot.ps1 für einen oder mehrere Server.

Wie der Client unter Windows mit einer WSL2-Linux-VM oder einem Hetzner-Server redet. Connections lokal ↔ Server umschalten, Images/Container ansehen, Podman vs. Docker, und „Cannot connect to Podman“ beheben. Bezogen auf diese Installation.

Wozu: verstehen, warum podman images nach cloud.ps1 up die Server-Images zeigt – und die lokale Maschine wieder ans Laufen bekommen.

Kostenloses, gehostetes OpenShift von Red Hat. Kein Server, keine Kreditkarte. Zwei feste Projekte, begrenzte Quota, Pods laufen max. 12 h, alles weg nach 30 Tagen.

Wozu: heute noch mit oc anfangen – Projects, Routes, S2I-Builds, Pipelines, GitOps, Dev Spaces – ohne irgendetwas aufzusetzen.

Podman oder Docker auf einem einzelnen Server. Umschalter im Kopf passt alle Befehle, die cloud-init-Datei und das Skript an.

Wozu: mehrere Container laufen lassen, ohne den Laptop-Luefter zu quaelen. Der einfachste Weg – gleicher Workflow wie lokal (podman run, docker compose), nur remote.

Einen Netcup-x86-vServer bestellen, per SSH absichern und wahlweise als Docker-, Podman- oder k3s-Host betreiben. Mit SCP-Firewall, automatisiertem Start/Stopp, kubeconfig, Datenpfaden und API-gesteuerten Snapshots.

Wozu: kleine Dienste, VPN, Testsysteme und leichtes Kubernetes dauerhaft günstig betreiben. Der VPS Lite 1 G12s ist der empfohlene Einstieg.

Vollständiges, leichtes Kubernetes in einem Binary (~512 MB RAM Overhead), als systemd-Dienst. kubeconfig wird auf den Laptop geholt.

Wozu: echtes Kubernetes lernen und betreiben – Deployments, Services, Ingress, Helm – ohne den Ballast eines großen Clusters. Später um weitere Nodes erweiterbar.

Ein ganzes OpenShift (OKD 4) auf einem einzigen Server – API (Application Programming Interface), Web-Console, Router, interne Registry, alle Cluster-Operatoren. SCOS (CentOS Stream CoreOS) per kexec aus dem Rescue, bootstrap-in-place, scripts/sno.ps1 steuert alles.

Wozu: den echten OpenShift-Workflow mit Web-Console üben – oc new-project, oc new-app, Routes, BuildConfigs, SCCs (Security Context Constraints) – ohne 3-Node-Cluster. Löst die alte MicroShift-Fassung ab (deren Installations-Repo ist tot). Braucht WSL2 (Windows Subsystem for Linux 2). RAM (Random Access Memory) ist der Engpass (OKD ~11 GB), Vorgabe cpx52 / 24 GB (Gigabyte).

Offiziellen SNO-Installationsweg mit platform.none, DNS, SCP-Firewall, install-config.yaml, generierter Ignition-Konfiguration und einer per API ins Netcup-DVD-Laufwerk eingelegten Fedora-CoreOS-ISO ausführen. Das Werkzeug begleitet ISO-Erzeugung, Einlegen und Warten auf den Installationsfortschritt.

Wozu: echtes OKD auf einem Netcup-VPS lernen. Kein Hetzner-Rescue-/kexec-Trick, sondern Netcups eigener ISO- und Bootreihenfolge-Weg.

Ein echter mehrknotiger OpenShift-Cluster (OKD 4): 3 schedulebare Control-Plane-Nodes, platform: none, Hetzner Load Balancer, privates Netz, DNS über nip.io, Fedora CoreOS per coreos-installer.

Wozu: OpenShift so betreiben, wie es in echt aussieht – HA-etcd, Web-Console, Cluster-Operatoren, Worker-Nodes, Updates. Achtung: teuer und aufwendig – erst die anderen drei probieren.

Einen lokalen podman compose-/Helm-Microservices-Stack (Spring + Postgres/Kafka/ Keycloak/Observability) in drei Stufen auf Hetzner bringen: nur Infra → ganzer Stack → Helm auf k3s.

Wozu: die Infra deiner Lernprojekte (Testcontainers, infra/, Helm, kind) mit den Cloud-Guides verbinden – mit den Kafka-/Keycloak-/Secrets-Fallen und CI-Deploy.

Das ganze Projekt (8 Spring-Services + Angular-Frontend + Postgres/Kafka/Keycloak/ Observability) auf einem k3s-Cluster – 1 Node oder HA (Hochverfügbarkeit) mit 3 Nodes.

Wozu: konkreter Komplett-Runbook für library-enterprise-platform – deploy.ps1, Bitnami-Infra, Ingress/TLS (Transport Layer Security), Frontend-Build.

Dasselbe Projekt (8 Spring-Services + Angular-Frontend + Infra), aber über die echte vierstufige Jenkins-Pipeline auf den OKD-Single-Node: Jenkins baut die Images, pusht in OKDs interne Registry, deployt per Helm.

Wozu: das Zusammenspiel lernen – Registry-Auth, ServiceAccount-Rechte, Helm-Overlays, DB-Secrets, Probe-Timing, Split-Horizon-Keycloak, local-path- Storage auf SCOS, Edge-TLS. Mit jeder Falle dokumentiert (25 Stück).

Derselbe Stack wie bei Jenkins → OKD, aber auf OpenShift Local im Laptop: gleiche Helm-Charts, gleiche Bitnami-Infra, eigenes Umgebungs-Overlay. Ende-zu-Ende getestet mit 13 Pods und drei Edge-Routen.

Wozu: den ganzen Cluster-Ablauf ohne laufende Serverkosten üben – und die Grenze sehen, an der ein Single-Node kippt: acht JVM-Kaltstarts parallel treiben die Load auf 157 und legen den API-Server lahm. Mit gestaffeltem Rollout und Messwerten je Dienst.

Betrieb und Diagnose der CRC-VM, unabhängig vom Projekt: Dimensionierung, VM-Disk auf die SSD und Cache per Junction auf die große Platte, der Console-Pod der 5 GB pro Stunde schreibt, und wie man Load-Werte liest.

Wozu: die drei Dinge kennen, an denen CRC tatsächlich scheitert – zu wenig Platte, zu langsamer Speicher, zu wenig CPU. Inklusive der Falle, dass der Bundle-Download seit 2.63 an einer Junction abbricht, der laufende Betrieb aber nicht.

Denselben CI-Jenkins statt auf Hetzner lokal im enterprise-infrastructure-Compose fahren – jenkins_home 1:1 aus dem letzten Snapshot (Jobs, Credentials, Build-Historie). Mit dem podman-compose-Socket-Umweg unter Windows.

Wozu: den zweiten Server sparen. Wie ein benanntes Volume den kaputten Bind-Mount-Pfad umgeht, die podman-machine-Prereqs, Deploy-Trigger – und die Build-Fehler #18–#22 mit Fix. Rückweg: jenkins.ps1 up.

Als DevOps in der OpenShift-Web-Konsole zurechtkommen: die zwei Perspektiven, die Landkarte der Menüs, eine App im Blick behalten. Und wo welche Konfiguration liegt – DB-Passwort, Endpunkt, App-Einstellung, Cluster-Config, Node-Config – je mit Konsolen-Weg und oc-Befehl.

Wozu: nicht mehr suchen. Plus: ein CrashLoopBackOff Schritt für Schritt, der Secret-Klartext-Hinweis, und wo die Konsole aufhört und die CLI anfängt.

Helm einmal von Hand am echten Chart durchspielen, bis das mentale Modell sitzt: den Chart lesen, helm template, install und das Release-Secret ansehen, einen Wert ändern mit helm diff und upgrade --atomic, ein kaputtes Upgrade und der Rollback, Drift von Hand erzeugen.

Wozu: verstehen, dass Helm nur Schablone plus Verlauf ist – und wo es aufhört (verwaiste Objekte, keine Drift-Korrektur, Daten und Hooks laufen nicht zurück). Am Ende der reale Jenkins-Aufruf je Dienst.

Secrets von Hand durchspielen: die Typen anlegen, als env vs als Mount konsumieren und den Unterschied live sehen, der Klartext-Weg, Verschlüsselung at-rest einschalten (aescbc), Pull-Secrets für eine private Registry, Rotation ohne Ausfall, und der Weg raus aus Git.

Wozu: wissen, dass ein Kubernetes-Secret keine Verschlüsselung ist – und die drei Modelle, die es aus Git heraushalten: Sealed Secrets, External Secrets Operator, SOPS.

RBAC und SCC von Hand durchspielen: view/edit/admin live vergleichen, mit can-i/who-can prüfen, warum RBAC additiv ist. Dann scheitert ein Pod unter restricted-v2 und gewinnt live eine andere SCC über add-scc-to-user.

Wozu: verstehen, dass dieselbe RBAC-Binding entscheidet, welche SCC ein Pod bekommt – und die richtige Fix-Reihenfolge (Image, Chart-Override, erst zuletzt SCC).

NetworkPolicy von Hand durchspielen: default-allow live sehen, eine deny-all-ingress-Policy anlegen und den Traffic wirklich brechen, gezielt wieder erlauben, die Selektoren podSelector/namespaceSelector/ipBlock, mehrere Policies die sich summieren.

Wozu: die DNS-Falle und die Probes-Falle kennen, bevor sie im echten Cluster zuschlagen – und wie Egress-Policy funktioniert.

Service, Route und Probes von Hand durchspielen: einen Service anlegen und per DNS auflösen, den Selector live kaputt machen, eine edge-Route mit Wildcard-Zertifikat anlegen, eine readiness-Probe live scheitern lassen.

Wozu: sehen, wie ein Pod aus dem Verkehr fliegt, ohne zu sterben – und readiness (raus/rein) und liveness (Neustart) nie wieder verwechseln.

Die Build-Kette von Hand durchspielen: mit oc new-app starten, ein BuildConfig live bauen lassen, einen echten Webhook auslösen, die Tag-Falle am eigenen ImageStream nachstellen und per Um-Taggen freigeben, feature/develop/main auf Test/QS/Prod abbilden und das Ergebnis mit einem winzigen Helm-Chart wirklich deployen.

Wozu: verstehen, warum ein Tag allein die Tag-Falle nicht löst, wie ein BuildConfig-Webhook den Branch prüft – und wie die Bibliothek das alles bewusst vereinfacht (kein BuildConfig, ein Overlay statt Branch-per-Stage).

OLM von Hand durchspielen: eine OperatorGroup anlegen, eine Subscription mit Manual-Approval abonnieren, den InstallPlan live genehmigen, die CSV-Phasen bis Succeeded verfolgen – am Beispiel OpenShift GitOps.

Wozu: die fünf OLM-Objekte einmal wirklich gesehen haben, statt nur den Hub-Klick zu kennen – und wissen, wie man sauber wieder deinstalliert.

Am eingebauten Service-CA-Operator den Reconcile sichtbar machen: internen TLS-Schlüssel und CA-Bundle anfordern, das Secret löschen und seine automatische Neuerzeugung beweisen. Optional eine echte ArgoCD-Custom-Resource untersuchen.

Wozu: Soll- und Ist-Zustand nicht nur als Diagramm verstehen, interne Service-Zertifikate sicher einsetzen und Operator-Probleme über Status, Events und Logs verfolgen.

Cluster-Betrieb von Hand durchspielen: oc get co lesen und einen kaputten ClusterOperator debuggen, einen ServiceMonitor und eine PrometheusRule live anlegen, ein PVC anlegen und die WaitForFirstConsumer-Binding sehen.

Wozu: oc get co als ersten Reflex verinnerlichen – und verstehen, warum ein Upgrade auf OKD-SNO oft eher ein Rebuild ist als oc adm upgrade.

Eine Logzeile bis Node oder Logging-Stack verfolgen, die gerenderte MachineConfig eines Nodes bis zu ihren Quellen zurückverfolgen und ein echtes etcd-Backup auf genau einem Control-Plane-Node erzeugen und extern sichern.

Wozu: Clusterzustand diagnostizieren und sichern, ohne auf einer SNO versehentlich einen MachineConfig-Neustart oder einen destruktiven Restore auszulösen.

Einen Request von der ClusterIP über EndpointSlice und OVN bis zur Pod-IP verfolgen, die generierte HAProxy-Konfiguration einer Route lesen und Service Mesh 3 von der früheren Maistra-Generation unterscheiden.

Wozu: DNS-, Service-, OVN-, Router- und Mesh-Fehler an der richtigen Schicht diagnostizieren und erkennen, wann ein Service Mesh nur unnötigen Overhead erzeugt.

Eine kleine Node.js-Anwendung aus lokalen Quellen mit S2I bauen, den neuen Digest am ImageStreamTag nachweisen und per Image-Trigger bis zum neuen ReplicaSet und Pod verfolgen.

Wozu: assemble und run verstehen, Tag und Digest trennen und ImageChange sowie die ConfigChange-Wirkung eines Kubernetes-Deployments praktisch unterscheiden.

Die drei Fundament-Bausteine von Hand durchspielen: oc new-project live verfolgen und sehen wie viel mehr entsteht als ein Namespace, mit oc api-resources und oc explain die API selbst erkunden, eine eigene ServiceAccount anlegen und binden.

Wozu: verstehen, dass ein Project keine stärkere Isolation ist als ein Namespace – und dass Rechte und SCC immer von der ServiceAccount kommen, nie vom User.

Vier Bausteine von Hand durchspielen: Deployment vs DeploymentConfig live vergleichen, einen Pod per nodeSelector gezielt (nicht) platzieren, eine Quota live gegen einen Deploy laufen lassen, env vs Mount live vergleichen wenn sich eine ConfigMap ändert.

Wozu: verstehen, warum eine Quota ohne LimitRange alles blockiert – und warum eine ConfigMap-Änderung im laufenden Pod manchmal ankommt und manchmal nicht.

Mit oc api-resources live trennen, was reines Kubernetes ist und was die OpenShift-Schicht dazugibt, dann einen HTPasswd Identity Provider live anlegen, sich als neuer User anmelden und Rechte per oc adm policy nachtragen.

Wozu: verstehen, dass ein Login nur die Identität gibt, nie die Rechte – und welche Objekte ein Chart auf reinem Kubernetes zum Laufen bringen, welche nicht.

Den OpenShift-Pipelines-Operator installieren, einen echten Task mit mehreren Steps schreiben, zwei Tasks über einen Workspace zu einer Pipeline verketten, einen PipelineRun live beobachten.

Wozu: den Gegenentwurf zu Jenkins-im-Cluster sehen – flüchtige Build-Pods statt eines dauerhaften Master-Pods, der mit den eigenen Diensten um CPU konkurriert.

Den OpenShift-GitOps-Operator installieren, eine Application anlegen, live Drift erzeugen und von selfHeal zurückdrehen lassen, ein Secret über Sealed Secrets statt im Klartext versionieren, den Rebuild-Ablauf als Checkliste durchgehen.

Wozu: verstehen, warum „Git ist das Soll, der Cluster ist das Ist“ mehr ist als ein Merksatz – und was ein Rebuild aus Git ehrlich wiederherstellt und was nicht.

Sechs typische Bruchstellen einer alten WebSphere-App live durchspielen: die zufällige UID unter restricted-v2 provozieren und mit einer SA-Brücke fixen, ein readOnlyRootFilesystem mit emptyDir aufbrechen, Sticky Sessions per Cookie testen, einen EJB-Timer als CronJob nachbauen, eine Datenquelle ohne Rebuild umkonfigurieren.

Wozu: die Symptome (CrashLoopBackOff, Permission denied, plötzlich ausgeloggte Nutzer) einmal selbst provoziert und behoben haben, statt sie nur aus einem Diagramm zu kennen.

Eine Lizenz-Schranke im Entrypoint live provozieren und fixen, das echte Pull-Secret und Entitlement-Secret im Cluster nachsehen, reale Image-Größen vergleichen, eine passthrough-Route gegen einen selbstsignierten Testserver aufbauen.

Wozu: die vier Reibungspunkte kommerzieller Middleware-Images (CrashLoopBackOff wegen Lizenz, unauthorized beim Pull, Riesen-Images, TLS-Konsolen) einmal selbst gesehen haben.

Eine SPA per Nicht-Root-nginx mit try_files ausliefern, den fehlenden CORS-Header live am Preflight sehen und per Pfad-Routing umgehen, ein echtes PKCE-Codepaar mit openssl erzeugen, env.js aus einer ConfigMap laden statt es ins Build zu backen.

Wozu: verstehen, warum „Network error“ im Browser oft ein CORS-Problem ist, obwohl der Server geantwortet hat – und wie dasselbe Image in jeder Umgebung eine andere Config bekommt, ohne Rebuild.

Eine WordPress-Site auf einem Cloud-Server mit CloudPanel (gratis, WP-optimiert), Cloudflare davor und Backups – oder gleich der gemanagte Hetzner-Webhosting-Tarif.

Wozu: eine echte Webseite/Blog/Shop betreiben. Enthält den Hetzner-Sonderfall Port 25 gesperrt und den Vergleich Cloud-Server vs. managed Webhosting.

Einen dauerhaften Netcup-x86-VPS mit CloudPanel und WordPress betreiben. Mit SCP-Firewall, Cloudflare-DNS und -Proxy, Full-strict-TLS, SMTP, externem Backup und Offline-Snapshot.

Wozu: der vollständige Netcup-Gegenweg zur Hetzner-Anleitung. Die öffentliche IPv4 kann cf-dns.ps1 direkt über die Netcup-SCP-REST-API ermitteln.

Dein eigener Bitwarden-Server (winzig, Docker + Caddy-HTTPS). Offizielle Bitwarden-Apps, Autofill überall, alle sonst kostenpflichtigen Funktionen frei.

Wozu: Passwörter, Tokens und Notizen zentral, mit Autofill auf allen Geräten, unter eigener Kontrolle. Ohne eigenen Server → Proton Pass Free (in der Anleitung).

Dateien, Kalender, Kontakte, Fotos, Office – unter cloud.seb4u.com. Mit den Fallen: der Cron-Job, RAM/Redis/PHP (PHP Hypertext Preprocessor), S3-Primaerspeicher, Collabora, .well-known, Backup mit getestetem Restore.

Wozu: das „persoenliche Cloud“-Ding, das die meisten wirklich wollen – AIO (All-in-One) vs manuelles Compose, Updates nur eine Hauptversion pro Schritt.

Eigener Mailserver (Mailcow) für die Domain. Der Aufbau ist schnell – die Arbeit steckt in Port 25 (Support-Ticket), IP-Reputation und Deliverability.

Wozu: volle Kontrolle über E-Mail. Mit ehrlicher Einschätzung (für eine Person meist Zoho/Proton besser), rDNS, allen DNS-Records, mail-tester, Warmup, Migration von Zoho.

Blog, Doku oder Landingpage aus Markdown: Hugo oder Astro generiert HTML (Hypertext Markup Language), dann Cloudflare Pages (gratis, Domain + TLS, Git-Deploy) oder ein nginx-Container auf dem Server.

Wozu: schnell, wartungsarm, keine Datenbank. Mit Bildern & Performance, Kommentaren (giscus), Suche (Pagefind), Analytics ohne Cookies und WordPress-Migration.

Kleiner Server, Projekte per rsync / scripts/deploy.ps1 hoch, erreichbar unter Subdomains von seb4u.com – aber hinter Cloudflare Access (Login) und über einen Cloudflare Tunnel: kein offener Port, keine Server-IP im DNS.

Wozu: eigene Projekte / Demos online stellen, aber nur für dich (bzw. eine E-Mail-Liste). Statische Seiten + Apps, SSH (Secure Shell) nur übers Tailnet, Backup, Kosten.

Statt pro Anleitung ein Server: eine Basis, ein Reverse Proxy (Traefik), ein Compose-Stack pro Dienst. WordPress samt Datenbank ausführlich, geteilte vs. eigene DB, Backup pro Dienst, Betrieb.

Wozu: WordPress + Vaultwarden + weitere Dienste sauber nebeneinander – mit den Regeln (ein 443, Blast Radius, Ressourcen) und einer Checkliste, wann man doch trennt.

Subdomain-Plan für seb4u.com + Rezepte: öffentliche Website (nginx / Cloudflare Pages / WordPress), selbst-gehostete Dienste (Nextcloud, Gitea, Status-Seite, RSS, Wiki …), und Cloudflare-only (Weiterleitungen, Pages, Workers – kein Server).

Wozu: nachschlagen, welche Subdomain zu welchem Dienst gehört – plus DNS-Records erklärt (A/CNAME/MX/TXT/SRV, SPF/DKIM/DMARC, TTL & Proxy).

seb4u.com von easyname zu Cloudflare Registrar transferieren (Webhosting weg, E-Mail zu Zoho). 7 Schritte: easyname-CDN-Option abschalten → Cloudflare-Zone auf Full → Nameserver → Transfer freigeben → Zoho-Mail.

Wozu: die Domain günstig und ohne Upselling halten. Enthält die Partial→Full- Umstellung, die „geparkt“-DNS-Records und die Zoho-Mail-Records (MX/SPF/DKIM/DMARC).

Cloudflare von Grund auf: Proxy, SSL-Modi, Cache, statische Site auf Pages deployen, DNS, Zero Trust Access als Login, eigener Server per Subdomain (DNS oder Tunnel), WAF. Dashboard-Stand 2025/2026.

Wozu: seb4u.com auf Pages betreiben und verstehen, was Proxy, Cache und Access tun – plus Subdomain auf den OKD-/Hetzner-Server ohne offenen Port.

WireGuard-Mesh über Laptop, Server und Telefon: feste Adressen + DNS-Namen, kein offener Port mehr am Server. Mit MagicDNS, Tailscale SSH (keine Keys), Auth-Keys für cloud-init, ACLs, Subnet-Router, Exit-Node.

Wozu: in ~6 Anleitungen die Voraussetzung – hier ausführlich. SSH / kubectl / Postgres nur noch übers Tailnet, Firewall komplett zu.

Die eine Seite mit aktuellen Hetzner-Preisen (nach der Erhöhung Juni 2026), jedem Nebenposten, was ohne laufenden Server weiterkostet, IPv4 (Internet Protocol Version 4) sparen, den vier Kill-Switch-Ebenen und „so prüfe ich die Rechnung“.

Wozu: Hetzner hat kein Ausgabenlimit. Mit Rechner und drei Beispielrechnungen – alle anderen Anleitungen zeigen hierher.

Verschlüsselte, automatische Backups mit Restic auf eine Hetzner Storage Box – Dateien und Datenbank-Dumps, Aufbewahrungsregeln, systemd-Timer, Totmann-Schalter zur Überwachung.

Wozu: die Daten, die der Snapshot nicht gut abdeckt – mit einem getesteten Restore (einzelne Datei bis kompletter Neuaufbau).

Uptime Kuma (ist es erreichbar?), Netdata (was macht der Server?), ntfy (Push aufs Telefon). Mit sinnvollen Checks, Alarmen ohne Rauschen, Status-Seite, Totmann-Schalter.

Wozu: erfahren dass etwas kaputt ist, bevor die Nutzer es melden – und wissen, warum. Plus: wo der Monitor laufen soll (nicht auf dem überwachten Server).

Von git push zum laufenden Dienst: GitHub Actions baut, schiebt nach GHCR (GitHub Container Registry), deployt per SSH über Tailscale (kein offener Port). Secrets in Environments, DB-Migrationen, Rollback, Pull-Modell, self-hosted Runner, Jenkins.

Wozu: deployen ohne Handarbeit – die automatisierte Fassung von scripts/deploy.ps1. Vollständiger Workflow zum Kopieren, plus k3s/Helm.

Passwörter und Tokens raus aus .env: verschlüsselt in Git, entschlüsselt nur auf Server/CI/Compose. Schlüssel, .sops.yaml, Rotieren, Zugriff entziehen – plus wann Vaultwarden/Infisical/Vault besser passt.

Wozu: reproduzierbar statt .env-auf-der-Platte, mit Historie – und die CI kennt idealerweise keine Secrets.

Einen öffentlichen Server absichern, in Reihenfolge: SSH härten, Auto-Updates, nftables (+ die Docker-Firewall-Falle), CrowdSec, sysctl, Docker-Hardening, auditd, mit Lynis prüfen.

Wozu: wenn Tailscale/kein-Port nicht geht und 80/443 offen muss. Mit einer Liste, was Übertreibung ist – und alles ab cloud-init.

S3-kompatibler Speicher für Backups, App-Assets, statische Seiten, große Medien – Hetzner Object Storage oder MinIO/Garage selbst. Client, Policy, Versioning & Lifecycle, Website mit Cloudflare davor, App-Integration.

Wozu: „wächst unbegrenzt“ statt Volume – mit einer Tabelle, wann Object Storage / Volume / Storage Box, und Hetzner vs R2 vs B2.

Was im Notfall zu tun ist – ohne im Notfall nachzudenken: die ersten 5 Minuten, dann je Szenario (Server kompromittiert, Daten verloren, Region-Ausfall, DNS, Secrets geleakt, Ransomware), der Wiederaufbau von Null und eine Checkliste zum Ausdrucken.

Wozu: bindet Snapshot, Backup, DNS, Secrets und Hardening zusammen. Vorher lesen und ausdrucken, nicht erst im Ernstfall.