CMS Hosting
WordPress wurde auf der VM installiert, eingerichtet und mit einem eigenen Theme gestaltet.
Webarchitektur Projekt
WordPress, aber als kontrollierte Infrastruktur.
Ein CMS hinter einem Nginx Reverse Proxy: TLS am Edge, WordPress isoliert auf localhost und MariaDB nur im internen Container-Netz.
HTTPS enforced
Security headers active
Backend not public
Architecture
Eine einfache Website, technisch sauber geschichtet.
Die sichtbare Website ist nur der erste Eindruck. Entscheidend ist die Trennung der Komponenten: Der Reverse Proxy ist die einzige öffentliche Eintrittsstelle, während CMS und Datenbank abgeschirmt bleiben.
01
Internet
Besucher erreichen ausschließlich HTTP/HTTPS auf der VM.
02
Nginx
TLS-Terminierung, HTTP-Redirect, Security-Header und Weiterleitung zum internen CMS.
03
WordPress
Das CMS läuft im Container und ist nur lokal über 127.0.0.1:8080 erreichbar.
04
MariaDB
Die Datenbank besitzt keinen öffentlichen Port und bleibt im internen Docker-Netz.
Project Scope
Was diese Umsetzung nachweist.
Die Projektarbeit zeigt nicht nur eine installierte WordPress-Seite, sondern den vollständigen Weg von Domain-Auflösung über HTTPS und Reverse Proxy bis zur isolierten Backend-Struktur. Damit entsteht ein klarer Übergang von der Architektur zur konkreten Umsetzung: Jede sichtbare Funktion ist mit einer technischen Entscheidung im Server-Setup verbunden.
Reverse Proxy
Nginx ist die einzige öffentliche Schnittstelle und kontrolliert den gesamten Zugriff.
Security Hardening
HTTPS, HSTS, CSP, X-Frame-Options, X-Content-Type-Options und neutrale Server-Header sind aktiv.
Dokumentation
Architektur, Konfigurationszeilen, Screenshots, Tests und Post-Mortem werden nachvollziehbar gemappt.
Hardening
Der Browser sieht nur, was er sehen soll.
Die Antwort-Header zeigen den Reverse Proxy als kontrollierte Sicherheitsgrenze. Versionsdetails werden reduziert, HTTPS wird erzwungen und Browser-Schutzmechanismen sind aktiv.
ServerWebserver
Strict-Transport-Securitymax-age=31536000
X-Frame-OptionsSAMEORIGIN
X-Content-Type-Optionsnosniff
Content-Security-Policyframe-ancestors 'self'
CMS Layer
Design und Betrieb bleiben getrennt.
Das Theme liefert die visuelle Schicht, WordPress verwaltet Inhalte und Docker kapselt die Laufzeit. Dadurch bleibt die Umsetzung nachvollziehbar: jede Funktion der Architektur lässt sich einer Konfiguration zuordnen.
- Eigenes WordPress-Theme statt Standard-Template
- Persistente Volumes für CMS und Datenbank
- Reverse Proxy als einziger externer Zugriffspunkt
Über mich
Zwischen Webdesign, Code und Infrastruktur.
Ich bin Raphael Wagner und beschäftige mich gerne mit Webdesign, klarer Struktur und sauberer technischer Umsetzung. Normalerweise arbeite ich eher mit modernen Frontend-Stacks wie Next.js, React, TypeScript und je nach Projekt auch Astro. WordPress war für mich daher ein neuer, bewusst gewählter Zugang.
Vor kurzem habe ich mit Structiva mein eigenes Webdesign-Projekt gestartet. Unter https://structiva.at entwickle ich Websites, die Gestaltung und Technik zusammenbringen: individuell statt Baukasten, visuell prägnant und mit einem stabilen technischen Fundament.
Der Einstieg in moderne Webentwicklung kam für mich auch durch eine Workouttracker-App, die ich mit KI-Unterstützung entwickelt habe. Dort habe ich mich intensiver mit Next.js, React, TypeScript, Authentifizierung, Datenmodellen und AI-gestützten Trainingsfunktionen beschäftigt.
Diese Projektarbeit war für mich besonders spannend, weil ich eine WordPress-Seite einmal vollständig selbst aufsetzen wollte: vom CMS über Docker und MariaDB bis zum Nginx Reverse Proxy mit HTTPS und Security-Headern.
Hosting Context
Vom Homelab zur Projekt-VM.
Auch abseits dieser Projektarbeit beschäftige ich mich mit Hosting-Setups. Für Structiva nutze ich eine eigene Proxmox-Umgebung mit getrennten Containern, Cloudflare Tunnel, Nginx und einem statischen Next.js Export. Öffentlicher Traffic läuft dabei über Cloudflare, intern wird gezielt an die passende Web-Instanz weitergeleitet.
Structiva
Proxmox · Cloudflare Tunnel · Nginx · Next.js Export
WEBA Projekt
VM · Docker Compose · Nginx Reverse Proxy · WordPress
Lerneffekt
Statisches Frontend und dynamisches CMS technisch vergleichen
Verification
Geprüft und dokumentiert.
Die wichtigsten Anforderungen wurden direkt am Live-System geprüft: HTTP leitet auf HTTPS weiter, Nginx liefert die Security-Header aus, WordPress ist nur über 127.0.0.1:8080 erreichbar und MariaDB besitzt keinen öffentlichen Port.