Groundlens
DE
DE EN
DE
DE EN
Menu
Prüfen, ob es passt Sagen Sie uns, welche Arbeit immer wieder unnötig Aufwand macht oder liegen bleibt. Wir prüfen kostenlos, was – wenn überhaupt – sinnvoll ist.
← Alle Beiträge

DockerDevOpsNext.jsFastAPI

Schlanke und vorhersagbare Deploys auf einem VPS

Ich habe den Auslieferungsprozess umgebaut: kleinere Container, schnellere Deploys, sichere Defaults. Jede Änderung senkte Reibung, bis Releases Routine statt Risiko wurden.

Von Mirko Imperio Trotta

Ein elegantes, modernes Frachtschiff gleitet unter strahlend blauem Himmel über ruhige, spiegelglatte See. An Bord befinden sich ordentlich gestapelte Container in einem geordneten Raster. Einige Container sind dezent mit Fachbegriffen wie „Docker“, „Next.js“ und „FastAPI“ in einer modernen, minimalistischen Schriftart beschriftet. Die Farbpalette ist kühl und klar – Blau- und Grautöne mit sanften Akzenten in Orange oder Gelb. Das Bild soll Klarheit, Schnelligkeit und Zuverlässigkeit vermitteln. Der Stil sollte eine semi-realistische digitale Illustration oder ein leicht stilisierter Realismus sein. Hohe Detailgenauigkeit. Seitenverhältnis 16:9.

Kontext

Wenn du mitliest, habe ich Deployments gestrafft, Analytics rechtskonform gemacht, Publishing in Echtzeit gebracht und Human-in-the-Loop-Freigaben ergänzt.

Jetzt verfolge ich dasselbe Ziel aus einem anderen Winkel: das System leicht, schnell und kontrollierbar halten.

Was sich geändert hat

Die Seite lief, aber jedes Deploy war schwer. Zu viele Schritte. Zu viel Zeit. Ich habe die Images so umgebaut, dass nur noch läuft, was laufen muss—ohne Ballast.

In der Praxis heißt das:

  • Updates, die Minuten brauchten, sind in Sekunden durch.
  • Ein identisches Artefakt läuft überall: Dev, Staging, Produktion.
  • Releases sind ruhig, rückrollbar und per Default sicher.

Es geht weniger um Tools, mehr um Disziplin: identisch halten, vorhersagbar machen, einfach wiederherstellen.

Implementierungsnotizen

  • Frontend: Next.js 15 Multi-Stage-Build auf node:22-slim; das finale Image enthält nur .next/standalone.
  • Backend: Python Multi-Stage-Build auf python:3.11-slim; Abhängigkeiten im Build-Stage gebacken; Runtime läuft als nicht-root appuser (UID/GID 1001).
  • Konfiguration: Ein Image pro Service; compose.production.yaml, compose.staging.yaml und compose.override.yaml setzen Env/TAG und Settings.
  • Cleanup als Nächstes: Entfernen des alten /app/content-Kopierschritts im Frontend-Image nach vollständiger Sanity-Migration.

Warum das zählt

Ein schlanker Prozess gibt Zeit zurück. Weniger Überraschungen, geringere Kosten, klarere Verantwortung. Das skaliert—vom Solo-Setup bis ins größere Team.

Was als Nächstes kommt

Migrationsreste trimmen und die Runtime-Isolation anziehen. Kleine, stetige Schritte, die Produktion langfristig ruhig halten.

Kurz gesagt

Weniger Verschwendung. Mehr Kontrolle. Gleicher Standard über alle Umgebungen.

Steckt dahinter wiederkehrende Arbeit?

Sagen Sie uns in der kostenlosen Prüfung, was immer wieder passiert. Wir prüfen, ob Groundlens der richtige nächste Schritt ist.

Prüfen, ob es passt