Expertise · Infrastruktur und Betrieb

Wir setzen die Anwendung auf einen Server, den wir kontrollieren, mit reversibler Veröffentlichung, geprüften Sicherungskopien und einem Ort, an dem sichtbar ist, wenn etwas ausgefallen ist.

Hosting, Inbetriebnahme, Monitoring und Kontinuität für Webanwendungen und Plattformen mit Datenbank. Wir arbeiten auf Infrastruktur, die der Kunde beanspruchen kann: virtuelle Maschinen bei europäischen Anbietern, nginx, überwachte Prozesse, Container, selbst gehostete Datenbank. Enthält die Antwort auf die Frage „wo stehen meine Daten eigentlich“.

Ein Projekt besprechen

Bereits gebautWir betreiben auf diese Weise mehrere eigene Systeme, und die Konfigurationen liegen in Repositories, nicht nur auf Servern. Diese Website läuft auf nginx mit Next.js 16 unter PM2, bei OVHcloud București. Die Assistenzplattform läuft auf Microsoft Azure, Poland Central, mit MySQL, Redis und RabbitMQ in Containern, die an die lokale Oberfläche angebunden sind. Eine eigene Bürgerplattform verwendet systemd-Einheiten mit Veröffentlichung durch atomaren Symlink-Wechsel, täglich geprüfter Sicherungskopie und einer separaten Retention-Aufgabe, die nur läuft, wenn diese Sicherung erfolgreich war. Ein internes Board wird über einen eigenen Runner veröffentlicht, mit GitHub-Aktionen, die auf vollständigen Fingerprint fixiert sind, und mit automatischem Zurückrollen auf die vorherige Version, wenn die Health-Prüfung nach der Veröffentlichung fehlschlägt. Die zu nennende Einschränkung: Der Automatisierungsgrad unterscheidet sich von System zu System. Die Veröffentlichung dieser Website erfolgt weiterhin manuell, und die Datenbankmigrationen werden bewusst von Hand angewendet. Wir verkaufen keine automatische Kette, die wir nicht überall haben.

Eine App, die auf dem Laptop läuft, und eine, die in Produktion läuft, unterscheiden sich durch Dinge, die in der Oberfläche nicht sichtbar sind: was geschieht, wenn der Prozess um drei Uhr nachts stirbt, was geschieht, wenn eine Veröffentlichung misslingt, wo die Protokolle landen, wer zuerst erfährt, dass etwas ausgefallen ist, und von wo die Datenbank wiederhergestellt wird, wenn die Platte verschwindet. Dieser Dienst befasst sich genau mit diesem Teil.

Die grundlegende Wahl, die wir vorschlagen, ist die Infrastruktur, die der Kunde beanspruchen kann: eine virtuelle Maschine bei einem europäischen Anbieter, nginx vorne, Prozesse unter einem Supervisor, Container dort, wo es sinnvoll ist, selbst gehostete Datenbank dort, wo Unabhängigkeit wichtiger ist als Bequemlichkeit. Nicht, weil verwaltete Plattformen schlecht wären — sondern weil man eines Tages alles mitnehmen und gehen können will, und wenn das nicht von Anfang an bedacht wurde, lässt es sich nicht mehr günstig nachholen.

Die Frage nach der Datensouveränität hat nur eine ehrliche Antwort: eine geprüfte. Der Standort wird durch Abfrage des Metadaten-Dienstes der virtuellen Maschine und des Adressregisters bestätigt, nicht durch das Lesen der Marketingseite des Anbieters. Der Unterschied ist nicht theoretisch — für eine Übertragung innerhalb des Europäischen Wirtschaftsraums gilt das Kapitel über Übermittlungen im Gesetz 195/2024 schlicht nicht. Eine von uns durchgeführte Migration hat eine Plattform von einer in den Vereinigten Staaten gehosteten Datenbank auf einen selbst gehosteten Stack in der Europäischen Union verlagert, genau aus diesem Grund.

Was wir nicht versprechen: dass alles automatisch ist. Schema-Migrationen wenden wir absichtlich von Hand an, weil eine automatisch auf Produktion angewendete Migration durch eine Kette, die nicht weiß, was in der Tabelle steht, die übliche Art ist, wie Daten verloren gehen. Die Veröffentlichung des Codes wird automatisiert; die Änderung der Datenbankstruktur bleibt eine menschliche Entscheidung, mit frischer Sicherungskopie im Hintergrund.

Was dazugehört

Die Arbeit, nach Bestandteilen

Reversible Veröffentlichung mit Prüfung danach, nicht nur davor

Die Veröffentlichung endet nicht, wenn die Dateien auf dem Server angekommen sind, sondern wenn eine echte Anfrage beweist, dass die neue Version die ausgelieferte ist. In einer der Implementierungen synchronisiert das Skript das Verzeichnis, behält die vorherige Version daneben und extrahiert dann den Paketnamen aus der ausgelieferten Seite; anschließend prüft es unter der öffentlichen Adresse, ob genau diese Datei ausgeliefert wird. Falls nicht, kehrt es selbst zur vorherigen Version zurück. Das ist nicht theoretisch: Der Mechanismus hat ein im Verzeichnis des Runners verbliebenes altes Paket erkannt und eine Veröffentlichung annulliert, die sonst erfolgreich gewirkt hätte.

Atomarer Versionswechsel mit dem Prozess unter systemd

Die Alternative zu „anhalten, darüber kopieren, starten“ ist das Versionsverzeichnis plus ein in einem einzigen Schritt umgeschalteter symbolischer Link. Die systemd-Einheit zeigt immer auf den stabilen Pfad, und ein Rollback bedeutet das Umschalten des Links zurück. Die Einheit hat eine Neustartpolitik bei Fehlern mit kurzer Pause, maximale Ausfallzeit und Systembeschränkungen: keine Privilegieneskalation, geschütztes Dateisystem, unzugängliche Home-Verzeichnisse, mit einer expliziten Liste von Pfaden, in die geschrieben werden darf.

nginx davor, mit für den realen Fall geschriebenen Limits

TLS-Terminierung mit automatischer Zertifikatserneuerung, HSTS mit einer Laufzeit von einem Jahr und Einbeziehung der Subdomains, Komprimierung mit Mindestgrößenschwelle, statische Ressourcen mit langer Ablauffrist und unveränderlicher Kennzeichnung, und die Anwendung an die lokale Schnittstelle gebunden, damit sie nicht direkt aus dem Internet erreichbar ist. Die Ratenlimits werden nach Verkehrstyp festgelegt, nicht global. Eine bezahlte Lektion sollte erwähnt werden: Unter HTTP/2 zählt das Verbindungslimit die Streams, nicht die Verbindungen — bei einem kleinen Wert lehnt ein einziger Seitenaufruf seine Schriftarten und Skripte selbst mit 429 ab.

Sicherungskopie, die überprüft wird, nicht nur ausgeführt

Täglich geplante Aufgabe, mit Start beim nächsten Boot, falls die Maschine zur vorgesehenen Zeit ausgeschaltet war, und mit zufälliger Verzögerung, damit nicht alles in derselben Sekunde startet. Der Export der Datenbank wird komprimiert, und wenn die resultierende Datei leer ist, wird die Ausführung als Fehler behandelt — ein Export, der „erfolgreich“ endet und null Bytes erzeugt, ist der übliche Weg, erst nach sechs Monaten festzustellen, dass keine Kopie existiert. Die Dateien im Objektspeicher werden separat synchronisiert. Eine 100 % lokale Kopie überlebt den Verlust der Festplatte nicht, deshalb geht die Kopie auch außerhalb der Maschine, in ein Speicherkonto in der Europäischen Union mit geografischer Replikation, Versionierung, umkehrbarer Löschung und automatischem Ablauf — mit Zugriff über verwaltete Identität, damit keine Speicherschlüssel auf der Festplatte existieren.

Die geplante Löschung läuft nur nach einer erfolgreichen Kopie

Die Aufbewahrungsaufgabe hängt ausdrücklich von der Kopieraufgabe ab und startet danach. Eine Bereinigung ohne frische Kopie ist die einzige Form von Löschung, von der es kein Zurück gibt. Anders als das Kopieren holt das Löschen verpasste Ausführungen nicht nach: Wenn die Maschine ausgeschaltet war, wird am nächsten Tag nicht zweimal gelöscht. Jeder Lauf schreibt eine Zeile in eine Ausführungstabelle, und vor der ersten echten Aktivierung läuft die Aufgabe mindestens eine Woche im Leerlauf, während das Protokoll gelesen wird.

Alarme, die nicht lügen und nicht spammen

Eine geplante Aufgabe, die 200 zurückgibt, bedeutet nicht, dass die Aufgabe funktioniert hat. Unser Ausführungs-Wrapper liest den Antwortkörper und sucht darin nach Teilausfällen, danach sendet er eine Warnung mit Frequenzbegrenzung, damit ein Dienst, der den ganzen Tag ausgefallen ist, nicht sechsundneunzig identische Nachrichten erzeugt. Der Grund, warum es das gibt: Ein täglicher Bericht war elf Tage hintereinander tot, und die einzige Spur war eine Lücke in einer Tabelle, die niemand ansah. Die geplante Aufgabe war alle elf Male ausgelöst worden.

Veröffentlichungskette, die nicht von upstream umgeleitet werden kann

Die Aktionen im Integrationsfluss sind auf den vollständigen Commit-Fingerprint fixiert, nicht auf ein Label. Im März 2026 wurde eine populäre Aktion von den Labels `v1`…`v45` auf bösartigen Code umgeleitet und erreichte in 24 Stunden über 23.000 Repositories; ein Fingerabdruck verschiebt sich nicht. Der Flow speichert keine Credentials in der Arbeitskopie, und die Veröffentlichung läuft nicht über ein Token: Sie läuft über einen eigenen Runner auf der Zielmaschine, mit punktuell vergebenen Rechten. So liegt kein Zugriffsschlüssel für den Server auf der Codierungsplattform.

Container mit Limits, Gesundheitsprüfungen und Protokollen, die die Festplatte nicht füllen

Jeder Dienst hat eine Neustartpolitik, eine eigene Gesundheitsprüfung (Datenbankbereitschaft, ein Statuspunkt der Anwendung), CPU- und Speicherlimits, wo die Last es verlangt, sowie eine Protokollrotation auf Ebene der Container-Engine mit maximaler Größe und Dateianzahl. Die Datenbankports werden an die lokale Schnittstelle gebunden, niemals öffentlich. Pflichtvariablen werden so deklariert, dass der Container die Ausführung verweigert, wenn sie fehlen, statt mit einem gefährlichen Standardwert zu starten.

Selbst gehostete Datenbank, wenn Unabhängigkeit zählt

Vollständiger Stack in Containern — Datenbank, Authentifizierung, REST-Schnittstelle, Echtzeitkanal, Dateispeicher, Zugangstor — mit ausdrücklich aktivierten Erweiterungen und mit an die Maschine angepassten Speicher- und Verbindungsparametern, nicht bei den Standardwerten belassen. Migrationen sind versionierte Dateien im Repository und werden manuell angewendet, mit Neustart der Komponente, die ihr Schema im Speicher hält. Der Grund für diese Wahl ist einfach: Eine von außerhalb der Europäischen Union verwaltete Plattform kann technisch hervorragend und dennoch rechtlich ungeeignet sein.

Wie es aussieht

Der Weg, Schritt für Schritt.

Wir inventarisieren, was vorhanden ist und was verloren gehen kann

Was tatsächlich auf der Maschine läuft, unter welchem Supervisor, mit welchen Versionen, mit welchen offenen Ports; welche Sicherungskopien existieren und ob eine davon jemals wiederhergestellt wurde; welche Geheimnisse in die Repositories gelangt sind; worin der Unterschied zwischen der Konfiguration im Repository und der Datei auf dem Server besteht. Der letzte Punkt sorgt fast immer für Überraschungen — wir selbst haben einen dokumentierten Fall, in dem die Datei auf dem Server direkt, außerhalb des Repositories, bearbeitet wurde und daneben eine Sicherungskopie mit Zeitstempel hinterließ. Wir liefern das Inventar und die Liste der Single Points of Failure.

Wir legen die Basis: Server, nginx, Prozesse, Hardening

Firewall, die Eingaben standardmäßig ablehnt und nur das Nötige öffnet, Schutz gegen wiederholte Authentifizierungsversuche, dimensionierter Swap-Speicher, nginx mit TLS und automatischer Erneuerung, die Anwendung an die lokale Schnittstelle gebunden, der Prozess-Supervisor so konfiguriert, dass er beim Booten startet. Wir liefern die Konfigurationen im Repository, nicht nur auf der Maschine, damit die nächste Person sie nicht aus dem Gedächtnis rekonstruieren muss.

Wir machen die Veröffentlichung wiederholbar und reversibel

Veröffentlichungsskript mit der vorherigen Version, die erhalten bleibt, Gesundheitsprüfung nach der Veröffentlichung und automatische Rückkehr bei Fehlern. Wo Team und kontinuierliche Integration vorhanden sind, wird ein eigener Runner auf der Zielmaschine hinzugefügt, mit an den Fingerabdruck gebundenen Aktionen und ohne Credentials in der Arbeitskopie. Wir liefern das schriftliche Verfahren und eine im Beisein des Kunden ausgeführte Rückkehr — eine ungeprüfte Rückkehr ist keine Rückkehr.

Wir richten die Sicherungen, die Aufbewahrung und die Alarme ein

Tägliche Sicherung mit der Prüfung, dass die Datei nicht leer ist, Sicherung außerhalb der Maschine in einer Region der Europäischen Union, Aufbewahrungsaufgabe, die nur nach einer erfolgreichen Sicherung läuft und eine Spur hinterlässt, plus Alarme mit Ratenbegrenzung, die den Inhalt der Antwort lesen, nicht nur den Statuscode. Wir liefern eine tatsächlich durchgeführte Testwiederherstellung und ihr Protokoll.

Wir übergeben die Schlüssel und schreiben auf, was nicht gemacht wurde

Zugang im eigenen Konto, Betriebsdokumentation, Liste der geplanten Aufgaben und — obligatorisch — die ehrliche Liste der Dinge, die nicht automatisiert wurden und warum. Bei uns bleiben fast immer zwei auf der Liste: Schema-Migrationen, absichtlich manuell ausgeführt, und die Veröffentlichung dieser Website, die noch manuell ist.

Die Schichten einer Installation, von unten nach oben: die virtuelle Maschine in einer bestätigten europäischen Region, die Container-Engine mit Log-Rotation, die Datenbank mit täglich geprüftem Backup und externer Sicherung, die Prozesse unter Supervisor mit Neustart bei Fehlern, nginx mit TLS und Ratenbegrenzung — und seitlich die Veröffentlichungskette mit aufbewahrter vorheriger Version und automatischem Rollback.

Die Daten

Was wir anfassen, wo die Daten liegen und wie lange sie bleiben

Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.

Wo die Daten tatsächlich liegen und wie sie geprüft werden: Der Ort wird von der Maschine aus bestätigt, nicht aus der Dokumentation: Der Metadatendienst des Anbieters nennt die tatsächliche Region, und das Adressregister nennt das Land. Unsere Systeme stehen bei OVHcloud, București, România und auf Microsoft Azure, Poland Central — beide im Europäischen Wirtschaftsraum. Die Sicherungskopien der Bürgerplattform liegen in einer nördlichen Region der Union, mit Replikation in eine zweite Region ebenfalls in der Union. Diese Zeilen haben eine längere Liste von Orten ersetzt, die wir nicht bestätigen konnten.
Was wir während der Arbeit sehen: Konfiguration, Protokolle, Datenbankschema und Prozesszustand. Der Inhalt personenbezogener Daten ist nicht Teil der Arbeit; wo eine Fehlersuche dennoch ein Beispiel erfordert, wird ein dafür erstellter Fall verwendet. Administrativer Zugriff wird für die Dauer des Eingriffs namentlich gewährt und am Ende entzogen — und der Entzug wird geprüft, nicht angenommen.
Die Protokolle und wie lange sie leben: Die Webprotokolle dieser Website werden täglich rotiert, mit vierzehn aufbewahrten Exemplaren, mit Leserechten, die auf die Administratorengruppe beschränkt sind. Auf Container-Ebene erfolgt die Rotation durch die Container-Engine, mit festgelegter Größe und Anzahl von Dateien, damit ein geschwätziger Dienst nicht die Festplatte füllt und die Datenbank stoppt — die banalste Art, eine Produktion ausfallen zu lassen.
Die Geheimnisse liegen nicht im Repository: Sensitive Werte kommen aus Umgebungsdateien mit restriktiven Rechten, von der Systemeinheit gelesen, nicht in die Einheit geschrieben — denn die Definition einer Einheit und das Systemprotokoll sind für mehr Menschen lesbar, als man denkt. In der Veröffentlichungs-Kette wird die Umgebungsdatei der Produktion nicht über die Code-Plattform geführt: Sie wird lokal auf die Maschine kopiert und unmittelbar nach dem Build gelöscht. Wenn wir eine bestehende Infrastruktur übernehmen, ist der erste Durchgang immer ein Inventar der in Speicherorten gelandeten Geheimnisse, mit Rotationsplan.
Kontinuität: was passiert, wenn wir gehen: Die Übergabe bedeutet eigenen Kontozugriff beim Infrastruktur-Anbieter, den Speicherort mit allen Serverkonfigurationen, die Veröffentlichungs- und Rückkehrprozedur, die Wiederherstellungsprozedur der Sicherungskopie — getestet, nicht nur geschrieben — und die Liste der geplanten Aufgaben mit dem, was jede macht. Der Schutz gegen versehentliches Löschen wird von Anfang an auf die Ressourcen-Gruppe der Produktion gesetzt.

Ein Fall

Ein täglicher Bericht, der seit elf Tagen nicht mehr lief, in einem System, in dem alles 200 zurückgab

Die Ausgangslage

In einer eigenen internen Plattform erzeugen mehrere automatische Routinen täglich Berichte und bereinigen Daten. Die Aufgaben wurden innerhalb der Anwendung gestartet, mit Zählern im Prozess. Nichts deutete auf ein Problem hin: Der Dienst war gestartet, die Adresse antwortete, die Protokolle enthielten keine Fehler.

Was wir gebaut haben

Der tägliche Bericht fehlte seit elf Tagen, und die einzige Spur war eine Lücke in einer Tabelle, die niemand ansah. Es kamen zwei getrennte Fehler ans Licht. Der erste: Ein innerhalb der Anwendung gestarteter Zähler setzt sich bei jedem Neustart des Dienstes zurück, also wird eine Routine mit einem Intervall, das länger ist als das Intervall zwischen den Veröffentlichungen, nie ausgelöst. Der zweite, hinterhältigere: Die Routine war alle elf Mal korrekt ausgelöst worden und hatte jedes Mal den Code 200 zurückgegeben — aber der Antwortkörper enthielt partielle Fehler, die niemand las.

Was dabei herauskam

Die Planung wurde aus der Anwendung heraus verlagert, in einen System-Planer, dem Neustarts egal sind. Die Ausführung wurde in ein Skript gehüllt, das pro Lauf eine Protokollzeile schreibt, den Antwortkörper nach Fehler-Schlüsseln durchsucht und eine Meldung an einen Messaging-Kanal sendet — mit Frequenzbegrenzung, damit eine den ganzen Tag ausgefallene Abhängigkeit nicht neunzigsechs identische Nachrichten erzeugt. Eine 200-Antwort mit internen Fehlern hat jetzt einen eigenen Status, getrennt vom Erfolg.

Was der Fall nicht sagt

Nichts davon war im klassischen Sinn ein Infrastrukturproblem: Der Server lief, die Festplatte hatte Platz, der Prozess lebte. Genau deshalb dauerte es elf Tage. Die teuersten Betriebsfehler sind nicht die Ausfälle — die sieht man — sondern die Dinge, die Erfolg melden, ohne etwas zu tun. Die Gesundheitsprüfung, die zählt, fragt nicht „bist du gestartet?“, sondern „hast du getan, was nötig war, so oft wie nötig?“.

Fragen

Was uns die Leute fragen, bevor sie anrufen

Wo werden unsere Daten tatsächlich liegen?

Dort, wo Sie wählen, und wir prüfen, dass es wirklich dort ist. Unsere Systeme stehen bei OVHcloud, Bukarest, und auf Microsoft Azure, Poland Central, beide im Europäischen Wirtschaftsraum, und der Standort wurde bestätigt, indem der Metadatendienst der virtuellen Maschine und das Adressregister abgefragt wurden — nicht durch Lesen der Anbieterdokumentation. Die Prüfung zählt: Für eine Übermittlung innerhalb des Europäischen Wirtschaftsraums gilt das Kapitel zu Übermittlungen aus dem Gesetz Nr. 195/2024 nicht, und es sind keine besonderen Genehmigungen erforderlich. Außerhalb davon entsteht ein Garantien-Dossier.

Warum ein eigener Server und nicht eine verwaltete Plattform?

Nicht immer. Eine verwaltete Plattform ist die richtige Wahl, wenn das Team klein ist, der Verkehr unregelmäßig ist und nichts im Stack Anforderungen an die Residenz hat. Der eigene Server wird in drei Situationen zum besseren Argument: wenn Daten in einer bestimmten Jurisdiktion bleiben müssen, wenn die Kosten in großem Maßstab unvorhersehbar werden und wenn Sie alles mitnehmen und gehen können wollen. Wir haben auch die umgekehrte Migration für ein eigenes System gemacht: von einer in den Vereinigten Staaten gehosteten Datenbank zu einem selbst gehosteten Stack in der Europäischen Union, mit acht Containern — Datenbank, Authentifizierung, REST-Oberfläche, Echtzeit, Speicherung, Metadaten, Dashboard und Zugangstor.

Was passiert, wenn eine Veröffentlichung schiefgeht?

Es wird zurückgekehrt, und vorzugsweise automatisch. Die vorherige Version bleibt neben der neuen auf dem Datenträger, und nach der Veröffentlichung fordert eine Prüfung die echte Seite an und bestätigt, dass die ausgelieferte Datei die gerade gebaute ist; wenn nicht, kehrt das Skript automatisch zurück. Wo wir die atomare Umstellung des symbolischen Links verwenden, ist die Rückkehr ein einziger Vorgang. Das ist keine Broschürenbeschreibung — der Mechanismus hat bereits eine Veröffentlichung mit einem alten Paket erwischt, das im Arbeitsverzeichnis des Runners geblieben war, und sie abgebrochen.

Machen Sie Sicherungskopien? Wie oft und testen Sie sie?

Täglich dort, wo wir es gebaut haben — und das betonen wir, weil eine automatische Kopie nicht von selbst entsteht, wenn Sie eine Anwendung auf einen Server verschieben. Die Kopie läuft zu einer festen Stunde, wird beim nächsten Boot wiederhergestellt, wenn die Maschine ausgeschaltet war, und wenn der Export leer ausfällt, wird die Ausführung als Fehlschlag behandelt. Die Kopie geht auch außerhalb der Maschine, in eine Region der Europäischen Union, mit Replikation, Versionierung, reversibler Löschung und automatischem Ablauf. Der Wiederherstellungstest ist Teil der Lieferung: Eine nie wiederhergestellte Kopie ist eine Annahme, keine Kopie.

Wer erfährt zuerst, wenn etwas ausfällt?

Es hängt davon ab, was wir gebaut haben, und das verdient es, ohne Schnörkel gesagt zu werden. Gesundheitsprüfungen auf Container-Ebene und Statuspunkte der Anwendungen existieren; die Alarmierung an einen Messaging-Kanal, mit Frequenzbegrenzung, existiert dort, wo wir sie gebaut haben. Ein Statusprüfpunkt, den niemand abfragt, ist keine Überwachung — es ist eine Seite. Wenn Sie echte Überwachung wollen, ist das eine separate Stufe, mit einem externen Beobachter, der regelmäßig abfragt, und einem Alarmempfänger, der geweckt werden darf.

Wenden Sie bei jeder Veröffentlichung automatisch Datenbankmigrationen an?

Nein, und das ist eine bewusst getroffene Entscheidung, kein Versehen. Die Veröffentlichungs-Pipeline baut und kopiert Code; das ist alles. Schemaänderungen sind versionierte Dateien im Repository, werden manuell angewendet, mit einer frischen Sicherung im Hintergrund, und Komponenten, die ihr Schema im Speicher halten, werden danach neu gestartet. Eine automatisch in Produktion angewendete Migration durch einen Prozess, der nicht weiß, was in der Tabelle steht, ist der übliche Weg, auf dem Daten unwiederbringlich verloren gehen.

Wie verhindern Sie, dass Ihre Veröffentlichungs-Pipeline zu einem Angriffsweg wird?

Durch drei Regeln. Externe Aktionen werden auf den vollständigen Fingerprint des Commits fixiert, nicht auf den Tag — im März 2026 wurde eine weit verbreitete Aktion von ihren Tags auf schädlichen Code umgeleitet und erreichte in 24 Stunden über 23.000 Repositorys. Die Arbeitskopie speichert keine Zugangsdaten. Die Veröffentlichung erfolgt nicht mit einem in der Codeplattform gespeicherten Zugriffsschlüssel, sondern über einen eigenen Runner, der auf der Zielmaschine läuft, mit punktuell gewährten Rechten. Wir erkennen an, dass noch nicht alle unsere älteren Projekte alle drei einhalten; ihre Migration ist eine eigene Arbeit.

Übernehmen Sie eine von jemand anderem aufgebaute Infrastruktur?

Ja, und der erste Schritt ist immer ein Inventar, nicht eine Änderung. Was tatsächlich läuft, unter welchem Supervisor, mit welchen Versionen, welche Ports offen sind, welche Sicherungen es gibt, ob jemals eine davon wiederhergestellt wurde, welche Geheimnisse in Repositories gelandet sind und inwieweit die Konfiguration im Repository noch der Datei auf dem Server ähnelt. Die letzte Prüfung ergibt fast immer etwas: Wir haben in einem eigenen Projekt dokumentiert, dass eine Konfigurationsdatei direkt in Produktion bearbeitet wurde und daneben eine Sicherungskopie mit Zeitstempel hinterließ.

Was passiert, wenn wir mit jemand anderem arbeiten wollen?

Sie gehen komplett weg. Die Infrastruktur liegt von Anfang an auf Ihren Konten beim Anbieter, und die Übergabe umfasst das Repository mit allen Serverkonfigurationen, die Veröffentlichungs- und Rollback-Prozedur, die getestete Wiederherstellungsprozedur und die Liste der geplanten Aufgaben mit ihrer jeweiligen Funktion. Der Schutz gegen das versehentliche Löschen der Ressourcengruppe für die Produktion wird ab der Installation eingerichtet. Wenn ein Anbieter Ihren Weggang von einer Neuschreibung der Infrastruktur abhängig macht, war das das Problem, nicht die Technologie.

Worauf die obigen Aussagen beruhen (30 Quellen)

https://www.megapromoting.com antwortet mit 200 auf nginx + Next.jshttps://www.megapromoting.com/servicii · 2026-09-06

29 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.

Wie wir arbeiten Alle Dienstleistungen

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen