12-Factor App: Vorteile für dein Unternehmen und warum wir danach bauen

Der Dienstleister wechselt. Ein Server fällt aus. Der Einkauf eines Großkunden schickt einen Sicherheitsfragebogen. Ob deine Software diese drei Momente gut übersteht, entscheidet sich nicht im Moment selbst, sondern Monate vorher in der Architektur.

Auf unseren Leistungsseiten, etwa zur Individualsoftware, heißt es: Wir bauen nach den Prinzipien der Twelve-Factor App. Dieser Artikel erklärt, was hinter der 12-Factor App steckt und welche Vorteile du als Auftraggeber davon hast. Drei Leitfragen ziehen sich durch den Text:

Vorab: Das ist keine Anleitung für Entwickler. Zuerst kommen die Definition und die zwölf Faktoren in einer Tabelle, dann der Nutzen entlang der drei Momente. Zum Schluss zeige ich, wie wir das in Projekten umsetzen und wo die Methodik endet.

Die 12-Factor App, im Original «The Twelve-Factor App», ist eine Methodik mit zwölf Regeln für Web-Anwendungen und Online-Dienste. Ihr Ziel: Solche Anwendungen sollen sich automatisiert ausrollen, auf modernen Cloud-Plattformen betreiben und ohne größeren Umbau skalieren lassen.

Formuliert hat die Methodik 2011 Adam Wiggins, Mitgründer der Cloud-Plattform Heroku. Laut ihrer Einleitung hatten die Mitwirkenden selbst Hunderte Anwendungen entwickelt und ausgerollt. Über ihre Arbeit an Heroku hatten sie zudem mittelbar verfolgt, wie Hunderttausende weitere entwickelt, betrieben und skaliert wurden.

Der Originaltext wurde zuletzt 2017 aktualisiert. Am 12. November 2024 hat Heroku die 12-Factor App in ein Open-Source-Projekt überführt, das die Community gemeinsam weiterentwickelt. Die Überarbeitung liegt auf GitHub, steht unter der Lizenz CC BY 4.0 und soll die Fassung von 2017 später ersetzen.

Die Kernidee ist eine klare Arbeitsteilung zwischen der Anwendung und der Plattform, die sie betreibt. Die Anwendung bekommt ihre Einstellungen beim Start von der Plattform, legt alles Dauerhafte in Datenbanken oder Speicherdiensten ab und gibt ihre Protokolle als fortlaufenden Strom aus. Die Plattform startet sie, skaliert sie und sammelt die Protokolle ein.

Wichtig zur Einordnung: Die 12-Factor App ist kein Framework, kein Produkt und kein Zertifikat. Laut Original lässt sie sich in jeder Programmiersprache und mit jeder Kombination angebundener Dienste anwenden. Kaufen kannst du sie also nicht, nur beim Bau deiner Software einfordern.

Ein Hinweis zu den Begriffen: Ich nutze die englischen Faktornamen und erkläre sie. Die deutsche Übersetzung von 2015 nennt die Methodik «Zwölf-Faktoren-App» und übersetzt sehr wörtlich: Faktor IX heißt dort etwa «Einweggebrauch».

Kurz gesagt: Die 12-Factor App legt nicht fest, wo deine Software läuft. Sie legt fest, wie sich die Software verhalten muss, damit der Ort austauschbar bleibt.

Die Tabelle folgt der Reihenfolge des Originals. Sechs Begriffe kommen darin und im weiteren Text immer wieder vor:

Zur Orientierung: Links steht der Faktor mit seinem Originalnamen, in der Mitte die Regel in einem Satz, rechts der Vorteil für dich als Auftraggeber.

Zusammengenommen bringen die zwölf Regeln deinem Unternehmen drei Vorteile: Austauschbarkeit von Entwicklungsteam und Anbietern (Faktoren I, II, III, IV und VII), Betriebssicherheit bei Ausfällen, Lastspitzen und Releases (V, VI, VIII, IX, X und XII) und Nachvollziehbarkeit für Prüfer und Einkauf (I, II, III, V und XI). In dieser Reihenfolge gehe ich sie durch.

Kein Faktor ist für sich spektakulär. Die Wirkung entsteht im Zusammenspiel: Je mehr Faktoren eine Anwendung erfüllt, desto leichter fallen Wechsel, Wiederanlauf und Audit.

Lock-in, also eine Bindung, die jeden Wechsel teuer macht, hat zwei Gesichter: die Bindung an ein Team und die an einen Hosting- oder Cloud-Anbieter. Beide lassen sich mit der Architektur entschärfen.

Ich habe mehrfach erlebt, dass ein Unternehmen nach dem Relaunch ein laufendes System hatte und keinen Zugriff auf das Repository. Faktor I sorgt dafür, dass es beim Code nur eine Sache zu übergeben gibt: Zu jeder Anwendung gehört genau ein Repository, und alles, was läuft, stammt daraus. Wer dieses Repository hat, hat die ganze Historie. Zur Übergabe gehören außerdem die Konfiguration je Umgebung und die Zugänge zu Datenbank und Diensten.

Damit das Repository wirklich bei dir liegt, läuft es bei uns von Anfang an auf deinen Namen. Zum Lieferumfang gehört ein dokumentierter Übergabepfad an deine IT oder ein anderes Team. Beides steht so auf unserer Seite zur Web-App-Entwicklung. Außerdem dokumentieren wir Architektur und Deployment, das Deployment selbst läuft ohne proprietäre Werkzeuge (Leitfaden zur Individualsoftware).

Faktor II ergänzt das: Alle Fremdbibliotheken, im Fachjargon Abhängigkeiten, sind mit exakter Version erfasst. Ein neues Team muss deshalb nicht rätseln, welche Bibliothek in welcher Version auf welchem Server lag. Das Original nennt als Ziel ausdrücklich, Zeit und Kosten für neue Entwickler im Projekt gering zu halten.

Unser Grundsatz dazu: Ein Dienstleisterwechsel darf nicht am Wissen einer Agentur scheitern.

Hier greift Faktor IV: Datenbank, Mailversand und Dateispeicher sind als Backing Services nur über Adresse und Zugangsdaten angebunden. Als Beispiel nennt das Original den Tausch einer selbst betriebenen MySQL-Datenbank gegen einen verwalteten Dienst wie Amazon RDS, ohne den Code zu ändern. Faktor III hält die Einstellungen aus dem Code heraus, Faktor VII lässt die Anwendung ihren Webserver selbst mitbringen. Deshalb läuft dieselbe Anwendung lokal, im Test und bei jedem Anbieter, der Container betreibt.

Dazu kommt rechtlicher Rückenwind: Die EU-Datenverordnung, kurz Data Act, gilt seit dem 12. September 2025. Sie verpflichtet Anbieter von Datenverarbeitungsdiensten wie Cloud-Plattformen, Wechselhindernisse zu beseitigen (Art. 23). Nach einer Kündigungsfrist von höchstens zwei Monaten gilt eine Übergangsfrist von höchstens 30 Kalendertagen (Art. 25 Abs. 2). Ist das technisch nicht machbar, kann der Anbieter mit Begründung eine Übergangsfrist von bis zu sieben Monaten festlegen (Art. 25 Abs. 4).

Ab dem 12. Januar 2027 sind Wechselentgelte verboten (Art. 29 Abs. 1). Praktisch nutzen kannst du diese Rechte aber nur, wenn deine Anwendung umziehen kann.

Der unbequeme Punkt: Wer anbieterspezifische Funktionen tief im Code nutzt, bindet sich trotzdem. Austauschbar ist, was über verbreitete Standards angebunden ist, etwa eine PostgreSQL-Datenbank. Im Vergleich von Supabase und Firebase habe ich das so zugespitzt: Der Exit ist die eigentliche Architektur.

Austauschbarkeit ist keine Vertragsklausel, sondern eine Eigenschaft der Architektur.

Der zweite Moment ist der Ausfall. Hier setzt die 12-Factor App auf Ersetzen statt Reparieren: Eine defekte Instanz wird nicht von Hand repariert, sondern ausgetauscht. Was das im Betrieb bedeutet, zeigen drei Fälle.

Faktor VI verlangt zustandslose Prozesse. Zustandslos heißt: Die laufende Anwendung hält keine dauerhaften Daten, alles Dauerhafte liegt in der Datenbank oder einem Speicherdienst. Fällt eine Instanz aus, startet die Plattform eine neue, und gespeicherte Daten bleiben erhalten. Im Beitrag zum Keycloak-Hosting heißt es dazu: «Keycloak-Container sind austauschbar, die PostgreSQL dahinter ist es nicht.»

Deshalb gilt die Sorgfalt den Backups, und zwar geprobten. Zustand versteckt sich auch in Details: Der Zwischenspeicher für fertig erzeugte Seiten liegt bei selbst betriebenem Next.js standardmäßig auf der lokalen Platte. Ab mehreren Instanzen braucht es dann einen gemeinsamen Zwischenspeicher, etwa auf Basis des Datenspeichers Redis.

Faktor IX regelt den Austausch selbst: Prozesse starten schnell und fahren auf ein Signal hin geordnet herunter. Kubernetes, die verbreitete Plattform für den Containerbetrieb, lässt einer Instanz dafür standardmäßig 30 Sekunden Zeit, Google Cloud Run 10 Sekunden bis zum harten Abbruch. Wer in dieser Frist laufende Anfragen abschließt, übersteht Deployments und Wartung in der Regel ohne Fehlermeldungen.

Zwei Bedingungen gehören dazu: Neue Instanzen dürfen erst Anfragen bekommen, wenn sie die Bereitschaftsprüfung der Plattform bestanden haben. Und Hintergrundjobs müssen sich gefahrlos wiederholen lassen, damit ein abgebrochener Lauf keine Bestellung doppelt anlegt.

Faktor VIII setzt beim Skalieren auf mehr Prozesse, getrennt nach Art der Arbeit. Ein Beispiel aus unserer Praxis ist das Shopsystem Medusa: Es läuft in Produktion als Server-Prozess für Anfragen und als Worker-Prozess für Hintergrundarbeit. So bremsen Hintergrundjobs die Webanfragen nicht aus. Beide Prozesse nutzen dieselben Zugangsdaten und dieselbe Datenbank; den Modus legt eine einzige Einstellung fest.

Auch die Kosten folgen diesem Muster: Das Hosting einer typischen Anwendung auf Hetzner kostet 20 bis 50 Euro im Monat, hochverfügbar mit redundanten Instanzen 150 bis 400 Euro. Dazu kommen 2 bis 5 Stunden Betreuung im Monat. Für den Code ist der Schritt dazwischen kein Umbau, für den Betrieb aber ein eigenes Vorhaben: mindestens zwei Instanzen, eine gespiegelte Datenbank und ein Lastverteiler (Load Balancer) davor.

Eine Grenze gehört nach meiner Einschätzung dazu: In die Breite wächst nur, was zustandslos ist. Die Datenbank skaliert anders und meist teurer.

Faktor V trennt drei Schritte: bauen, mit der Konfiguration verbinden, ausführen. Aus Build und Konfiguration entsteht ein Release mit eindeutiger Kennung, das danach nicht mehr verändert wird: Jede Änderung erzeugt ein neues Release. Wer denselben Build in allen Umgebungen einsetzt, testet genau das Paket, das live geht.

Bei Keycloak-Upgrades legen wir den Rollback, also den Rückweg zur Vorversion, vorher fest: eine Momentaufnahme der Datenbank unmittelbar vor der Migration plus das gebaute Paket der alten Version. Vorab proben wir das Upgrade auf einer Staging-Umgebung, einem produktionsnahen Testsystem mit anonymisierter Kopie der Produktionsdaten.

Nach dem Ausrollen folgt ein Beobachtungsfenster von 30 bis 60 Minuten: Fällt darin etwas auf, rollen wir zurück. Danach gilt: vorwärts korrigieren, denn eine zurückgespielte Momentaufnahme verwirft alle Datenänderungen seit der Migration.

Faktor X hält Entwicklung, Test und Produktion so ähnlich wie möglich. Das Original rechnet bei klassischen Anwendungen mit Wochen zwischen zwei Deployments, bei der 12-Factor App mit Stunden. DORA, das Forschungsprogramm von Google Cloud zur Softwareauslieferung, kommt zum Schluss, dass Tempo und Stabilität keine Gegensätze sind.

Faktor XII bindet Änderungen an der Datenbankstruktur ans selbe Release wie den Code, der sie braucht. Am Ende gilt: Ein Rollback, den niemand geprobt hat, ist keiner.

Zum Thema Compliance vorab: Die DSGVO verlangt nicht nur Schutz, sondern auch den Nachweis. Der Verantwortliche (in der Regel dein Unternehmen) muss die Einhaltung der Grundsätze «nachweisen können», so die Rechenschaftspflicht in Art. 5 Abs. 2. Fällt dein Unternehmen unter NIS2, die EU-Richtlinie zur Cybersicherheit, verlangt das deutsche BSI-Gesetz, die Einhaltung der Risikomanagementmaßnahmen zu dokumentieren (§ 30 Abs. 1 Satz 3 BSIG).

Die Geschäftsleitung muss diese Maßnahmen umsetzen und überwachen, außerdem regelmäßig an Schulungen teilnehmen (§ 38 BSIG, in Kraft seit dem 6. Dezember 2025). In Österreich gilt seit dem 1. Oktober 2026 das NISG 2026, die österreichische Umsetzung von NIS2. Auch wenn dein Unternehmen nicht unter NIS2 fällt, stellen dir regulierte Kunden ähnliche Fragen: Sie müssen die Sicherheit ihrer Dienstleister berücksichtigen (§ 30 Abs. 2 Nr. 4 BSIG).

Ob Datenschutzbeauftragter, IT-Sicherheit oder der Einkauf eines Großkunden: Die Fragen ähneln sich, und ein Teil davon lässt sich aus der Architektur beantworten. Welche Nachweise der Einkauf sehen will, habe ich am Beispiel einer Sicherheitsseite für SaaS-Anbieter beschrieben. Die Tabelle ordnet typische Prüffragen den Faktoren zu und nennt den passenden Bezug im Regelwerk.

Zwei Lesehinweise zur Tabelle: Alle Zuordnungen sind fachliche Einschätzungen. Sie zeigen, worauf eine Frage zielt, nicht, dass eine Anforderung erfüllt ist. Und ISO 27001 meint die Fassung von 2022 mit ihrem Anhang A.

Zu den beiden US-Regelwerken: SOC 2 ist ein Prüfbericht nach US-Standard, den vor allem international einkaufende Konzerne verlangen. HIPAA, das US-Gesetz zum Schutz von Gesundheitsdaten, gilt für US-Krankenversicherer, Abrechnungsstellen und Leistungserbringer sowie für alle, die in deren Auftrag Gesundheitsdaten verarbeiten, auch als Unterauftragnehmer. Ob das auf dich zutrifft, klärt deine Rechtsberatung.

Erste Lücke: Zugangsdaten im Code. Der Sicherheitsanbieter GitGuardian fand 2025 in öffentlich einsehbaren Änderungen auf GitHub 28,65 Millionen neue, fest im Code hinterlegte Zugangsdaten, 34 Prozent mehr als im Vorjahr. Ausweislich seines Jahresberichts steckten in 32,2 Prozent der internen Repositorys fest hinterlegte Zugangsdaten, in öffentlichen nur in 5,6 Prozent. Einschränkend: Das ist eine Herstellerstudie, GitGuardian verkauft Werkzeuge gegen genau dieses Problem.

Faktor III zieht hier eine klare Linie. Der Lackmustest aus dem Original: Der Code müsste sich jederzeit veröffentlichen lassen, ohne ein einziges Passwort preiszugeben.

Zweite Lücke: nicht erfasste Fremdbibliotheken. Am 11. Dezember 2021 rief das BSI wegen Log4Shell, einer Lücke in einer verbreiteten Java-Bibliothek, die Warnstufe Rot aus. Welche Produkte verwundbar seien, sei «derzeit nicht vollständig überschaubar», hieß es damals. Meine Lehre daraus: Mit einer vollständigen, versionsgenauen Liste aller Abhängigkeiten wird «Sind wir betroffen?» für die eigene Anwendung zur Abfrage statt zur Suche.

Klartext: Die 12-Factor App ist weder Zertifikat noch Prüfsiegel. Nach ISO 27001 wird das Managementsystem einer Organisation zertifiziert, nicht eine Anwendung. Anhang A der Norm umfasst 93 Maßnahmen: 37 organisatorische, 8 personenbezogene, 14 physische und 34 technologische. Die zwölf Faktoren berühren davon nur einen kleinen Teil, überwiegend technologische Maßnahmen.

Auch für PCI DSS, den Sicherheitsstandard der Kartenzahlungsbranche, und den EU AI Act reicht die Methodik nicht. Wie viel PCI DSS deine Anwendung betrifft, hängt vor allem davon ab, ob Kartendaten über deine Systeme laufen oder nur beim Zahlungsdienstleister. Beim EU AI Act geht es um Fragen, die die Methodik gar nicht stellt, etwa Risikoklassen, Transparenz und menschliche Aufsicht. Was er von Auftraggebern verlangt, steht in Der EU AI Act für Software-Auftraggeber.

Risikoanalyse, Richtlinien, Schulungen und Notfallplanung bleiben Aufgabe deines Unternehmens, ebenso Datenschutz-Folgenabschätzungen und der Überblick über alle Auftragsverarbeiter. Übernehmen wir den Betrieb, gehört der Auftragsverarbeitungsvertrag mit uns zum Projekt. Betreibst du die Anwendung selbst, liegen auch die technischen Nachweise bei dir, etwa Protokollierung, Zugriffskonzept und Backup-Tests. Welchen Aufwand das bedeutet, rechne ich in meinem Beitrag zu den Kosten von Keycloak vor.

Unsere Rolle: Auf Wunsch arbeiten wir mit deinem Datenschutzbeauftragten zusammen und liefern die technische Dokumentation, etwa fürs Verarbeitungsverzeichnis. Den Nachweis gegenüber Prüfern führt dein Unternehmen, wir schaffen die technische Grundlage dafür. Rechtsberatung ersetzen wir nicht, und bei erhöhten Anforderungen empfehlen wir externe Sicherheitsaudits.

Die Methodik macht keine Software konform. Sie sorgt dafür, dass du auf die technischen Fragen belegbare Antworten hast.

Was davon halten wir selbst ein? Hier steht nur, was wir auch an anderer Stelle öffentlich beschreiben, jeweils mit dem passenden Faktor in Klammern.

Zum Pflicht-Review eine Einordnung: Das Original will, dass Entwickler eng am Ausrollen ihres Codes beteiligt sind (Faktor X). ISO 27001 sieht in Anhang A dagegen Aufgabentrennung vor (A.5.3). Ein Review durch eine zweite Person ist ein gängiger Weg, beides zu verbinden. Ob das als Nachweis genügt, hängt vom Managementsystem deines Unternehmens ab.

Die Plattform wählen wir je Projekt, wie auf unserer Seite zum Tech-Stack beschrieben: Bei Datenschutzanforderungen bevorzugen wir Hetzner, ein deutsches Unternehmen mit Rechenzentren in Deutschland und Finnland. Für Projekte ohne strenge Datenschutzanforderungen kommen auch die US-Plattformen Vercel oder Netlify infrage. Diese Website läuft selbst auf Vercel. Dass beides geht, liegt vor allem an den Faktoren III, IV und VI.

Welche Umgebungen ein Projekt braucht, klären wir in der Planung. Ob dabei genau das getestete Image unverändert in die Produktion wandert, hängt vom Projekt ab: Next.js etwa schreibt Einstellungen, die der Browser braucht, schon beim Build fest. Eines sage ich offen: Self-Hosting verschiebt Verantwortung, es eliminiert sie nicht.

Vorab: Fünfzehn Jahre nach ihrer Entstehung wirken manche Beispiele der Methodik alt, etwa die Werkzeuge Capistrano oder Foreman. Yehuda Katz, einer der Verantwortlichen des Projekts, schrieb zur Öffnung im November 2024, in meiner Übersetzung: «Die Konzepte bleiben relevant, aber viele Details kommen allmählich in die Jahre.» So lesen wir die Methodik auch, und zwar in vier Punkten.

Faktor III empfiehlt Umgebungsvariablen auch für Zugangsdaten. Das sind Werte, die das Betriebssystem einem Programm beim Start mitgibt. Die Sicherheitsinitiative OWASP rät davon ab, wo andere Wege möglich sind: Umgebungsvariablen sind grundsätzlich für alle Prozesse zugänglich und können in Logs oder Speicherabbildern landen. Kubernetes speichert Zugangsdaten zudem standardmäßig unverschlüsselt in seiner internen Datenbank etcd.

Unsere Empfehlung: Die Trennung von Code und Konfiguration bleibt. Wo der Schutzbedarf es verlangt und die Plattform es erlaubt, gehören Zugangsdaten in einen Secret-Manager, einen eigens dafür abgesicherten Speicher, oder werden als Datei eingebunden. Viele Container-Plattformen übergeben sie allerdings weiterhin als Umgebungsvariable. Dann gilt umso mehr: Rechte je Dienst eng begrenzen und Zugangsdaten regelmäßig austauschen.

Die Community rund um das Projekt diskutiert genau das. Ein offener Entwurf schlägt einen neuen Faktor «Identity» vor: Die Anwendung soll sich gegenüber jedem angebundenen Dienst mit eigenen, kurzlebigen Zugangsdaten ausweisen. Die Umgebungsvariable enthält dann nicht mehr den geheimen Wert selbst, sondern nur den Ort, an dem die gerade gültigen Zugangsdaten liegen. Stand 10. Oktober 2026 ist der Entwurf nicht beschlossen.

Faktor XI behandelt Logs als Ereignisstrom. Spätestens bei Systemen aus mehreren Diensten reicht das nicht: Es braucht zusätzlich Metriken (Kennzahlen wie Antwortzeiten oder Fehlerquoten) und Traces, die den Weg einer Anfrage durch mehrere Dienste nachzeichnen. Zusammen ergibt das Observability: die Fähigkeit zu verstehen, was in deinem System passiert.

Herstellerneutraler Standard dafür ist OpenTelemetry, und ein offener Vorschlag der Community will den Faktor in diese Richtung erweitern. Zwei Lücken bleiben im Original. Erstens brauchen Protokolle für Prüfzwecke Schutz vor nachträglicher Änderung und Regeln zur Aufbewahrung. Zweitens enthalten Logs oft personenbezogene Daten wie IP-Adressen, für die nach DSGVO Speicherbegrenzung und Zugriffsschutz gelten.

Die Methodik ist für Web-Anwendungen und Dienste auf Servern geschrieben. Für eine mobile App, wie wir sie mit React Native bauen, gilt sie nur für das Backend dahinter, die Serverseite. Bei Serverless-Funktionen entfällt Faktor VII: Die Plattform ruft solche Programmteile bei Bedarf direkt auf. Datenbanken und Suchindizes brauchen eigene Muster für ihren Zustand.

Anmeldung, Rechte und Zugriffskontrolle haben im Original keinen eigenen Faktor. Diese Lücke schließen wir mit Keycloak, einer Open-Source-Software für Anmeldung und Rechte: Mehrfaktor-Authentifizierung, Single Sign-on und Rollen sind bei uns Standard. Single Sign-on heißt: eine Anmeldung für mehrere Anwendungen.

Bestehende Software umzustellen kostet Aufwand, und bei einer kleinen internen Anwendung lohnt nicht jeder Faktor. Bei der Software-Modernisierung steht am Anfang eine Bestandsaufnahme, danach erneuern wir Modul für Modul, während das System weiterläuft. Ehrlicherweise: Nicht jedes Altsystem gehört modernisiert. Manchmal lautet unsere Empfehlung, es weiterzubetreiben und abzusichern.

Kurz: Wir halten uns an die Prinzipien von 2011, nicht an ihre Beispiele.

Zum Abschluss drei Fragen, mit denen du deine bestehende Software oder ein neues Angebot prüfen kannst:

Lautet eine Antwort «weiß ich nicht», hast du deinen Startpunkt. Bei einem Angebot gilt zusätzlich: Was dort nicht steht, wird in der Regel auch nicht geliefert. Weitere Prüffragen findest du in den elf Fragen an dein Angebot, die ich für die Vergabe von Softwareprojekten zusammengestellt habe. Was ein Projekt bei uns kostet, von der ersten Version bis zum laufenden Betrieb, steht auf unserer Seite Software entwickeln lassen.

Wenn du deine Anwendung oder dein Vorhaben mit uns durchgehen willst, schauen wir in einem unverbindlichen Gespräch gemeinsam darauf. Wir gehen die zwölf Faktoren anhand deiner Antworten durch und schätzen ein, wo das größte Risiko liegt. Daraus ergibt sich der erste Schritt, ob mit uns oder ohne uns. Den Termin buchst du direkt in meinem Kalender: Erstgespräch vereinbaren.