Backstage ist eine Developer-Portal-Plattform, die als zentraler Hub f\u00fcr alle entwicklerrelevanten Informationen, Tools und Workflows dient. Urspr\u00fcnglich bei Spotify entwickelt und 2020 als Open-Source-Projekt ver\u00f6ffentlicht, hat sich Backstage zu einem Standard f\u00fcr moderne Developer Experience entwickelt. Im Kern ist Backstage ein Framework zum Aufbau individueller Developer Portale. Es bietet eine einheitliche Oberfl\u00e4che, in der Teams ihre Microservices, Dokumentationen, Infrastrukturkomponenten, Deployments und internen Tools zusammenf\u00fchren k\u00f6nnen.<\/p>\n
Backstage fasst alle Infrastruktur- und Entwicklungstools an einem Ort zusammen und schafft dadurch ein nahtloses, durchg\u00e4ngiges Development.<\/p>\n
Motivation und Anwendungsfall<\/h2>\n
In vielen Entwicklungsorganisationen wachsen mit der Zeit nicht nur die Softwareprodukte, sondern auch die Anzahl der Tools, Services, Dokumentationen und Cloud-Ressourcen. Teams arbeiten mit verschiedenen CI\/CD-Pipelines, unterschiedlichen Dashboards sowie verstreuten Wikis. Das f\u00fchrt zu einem zentralen Problem: Softwareentwickler verlieren Zeit, weil sie wichtige Informationen, Quellen oder Einstiegspunkte erst suchen m\u00fcssen.<\/p>\n
Backstage, als Open-Source-Framework wurde entwickelt, um eine einheitliche, zentrale Anlaufstelle f\u00fcr alle Entwicklungsressourcen zu schaffen (\u201cDeveloper Portal). Anstatt Werkzeug- und Informationsinseln zu verwalten, lassen sich mit Backstage Services, Dokumentationen, Infrastruktur-Komponenten und interne Tools an einem Ort b\u00fcndeln.<\/p>\n
Man benutzt Backstage also typischerweise wenn:<\/p>\n
\n
Teams viele unterschiedliche Services oder Microservices betreiben und Transparenz sowie ein einheitlicher \u00dcberblick fehlen.<\/li>\n
Dokumentation verteilt und schwer auffindbar ist, sodass Onboarding unn\u00f6tig viel Zeit kostet.<\/li>\n
Tooling-Landschaften historisch gewachsen sind und Entwickler dadurch Reibungsverluste haben.<\/li>\n
Organisationen Self-Service-Prozesse f\u00fcr Infrastruktur, Deployments oder Standardisierung einf\u00fchren wollen.<\/li>\n
man eine konsistente Developer Experience innerhalb des Unternehmens sicherstellen m\u00f6chte, unabh\u00e4ngig davon in welchem Team man arbeitet.<\/li>\n<\/ul>\n
<\/h2>\n
Vorteile von Backstage und Herausforderungen bei der Nutzung<\/h2>\n
Vorteile<\/h3>\n
\n
Zentrale Anlaufstelle f\u00fcr Entwickler<\/li>\n
Verbesserte Developer Experience<\/li>\n
Standardisierung und Nutzung von Best Practices<\/li>\n
Erweiterbarkeit durch Plugin \u00d6kosystem<\/li>\n
Transparenz \u00fcber eigene Services (Landschaften, Dokumentation, Lifecycle, Verantwortlichkeiten)<\/li>\n
Open Source und Weiterentwicklung durch gro\u00dfe Community<\/li>\n<\/ul>\n
Herausforderungen bei der Nutzung<\/h3>\n
\n
Hoher Initialaufwand zur Implementierung des Frameworks mit all seinen Integrationen<\/li>\n
Wartungsaufwand, da die Plattform wie ein eigenes Produkt betrieben werden muss (Wartung, Updates, Sicherheit)<\/li>\n
Anpassung an die eigenen Anforderungen notwendig, da Out-of-the-Box-Funktionen selten f\u00fcr produktive Umgebungen ausreichend sind<\/li>\n
Abh\u00e4ngigkeit an eigene Systemlandschaft: Heterogene Landschaft \u2192 zunehmender Integrationsaufwand<\/li>\n
Integration in den Arbeitsalltag: Die Plattform muss tats\u00e4chlich genutzt werden (Change Management), um bei geringer Pflege nicht ihren Nutzen zu verlieren<\/li>\n<\/ul>\n
<\/h2>\n
Wichtigste Funktionen<\/h2>\n
Software Catalog<\/h3>\n
Der Software Catalog bildet das zentrale Herzst\u00fcck von Backstage. In ihm werden alle Software-Komponenten zentral erfasst<\/strong>, verwaltet<\/strong> und \u00fcbersichtlich dargestellt<\/strong>. <\/p>\n
Im Catalog werden unter anderem folgende Komponenten gesammelt dargestellt:<\/p>\n
\n
Services<\/li>\n
Websites<\/li>\n
APIs<\/li>\n
Libraries<\/li>\n
Datenbanken<\/li>\n
Pipelines<\/li>\n
Infrastruktur-Komponenten<\/li>\n<\/ul>\n
Zu jeder Komponente sind die wichtigsten Informationen direkt einsehbar, beispielsweise Zust\u00e4ndigkeiten, Beschreibungen oder Metadaten. Nach entsprechender Integration lassen sich zudem technische Kennzahlen wie Build-Status oder Deployment-Informationen anzeigen.<\/p>\n
Scaffolder (Templates)<\/h3>\n
Mit dem Scaffolder erm\u00f6glicht Backstage das einfache und automatisierte Erstellen<\/strong> neuer Komponenten anhand vordefinierter Templates. Der Ablauf gliedert sich in folgende Schritte:<\/p>\n\n
Definition von Templates<\/li>\n
Ausf\u00fcllen der Templates durch Nutzer<\/li>\n
Automatisierte Generierung von Code, Erstellung von Repositories, Einrichtung von Pipelines usw.<\/li>\n<\/ol>\n
Dadurch werden einheitliche Standards sichergestellt, Fehler reduziert und Entwicklungszeit eingespart.<\/p>\n
Authentifizierungs- und Berechtigungssystem<\/h3>\n
F\u00fcr Anmeldung, Identifikation und Zugriffskontrolle nutzt Backstage externe Identity Provider zur Authentifizierung. Registrierte Nutzer<\/strong> werden als sogenannte User Entities im Software Catalog<\/strong> gef\u00fchrt und k\u00f6nnen Gruppen oder Komponenten zugeordnet werden. Zus\u00e4tzlich stellt Backstage ein umfangreiches Rollen- und Rechtesystem bereit, mit dem der Zugriff<\/strong> auf Plugins, Entities, Templates und weitere Funktionen gezielt gesteuert werden kann.<\/p>\n
TechDocs<\/h3>\n
Mit TechDocs wird die Dokumentation direkt im jeweiligen Repository<\/strong> abgelegt und an die entsprechenden Komponenten angebunden<\/strong>. Dadurch ist sie leicht auffindbar und immer kontextbezogen verf\u00fcgbar. Die Dokumentation wird in Markdown verfasst und besitzt dadurch ein einheitliches Layout. Ein wesentlicher Vorteil ist, dass keine veralteten Wikis<\/strong> entstehen und die Dokumentation stets synchron zum Code bleibt.<\/p>\n
<\/h2>\n
Konkrete Usecases<\/h2>\n
1 Service Setup<\/strong><\/p>\nAblauf des „Service Setup“ Usecases<\/figcaption><\/figure>\n
<\/div>\n
Ein Standardusecase bei der Nutzung von Backstage ist die Erstellung neuer Services \u00fcber die Scaffolding-Funktionalit\u00e4t. Nach der Entscheidung einen neuen Service zu erstellen, \u00f6ffnet der Entwickler dazu die Backstage-Instanz seiner Firma und navigiert zum Service Catalog. Im oberen rechten Bereich befindet sich ein Button „CREATE“ \u00fcber dessen Bet\u00e4tigung sich ein Fenster zur Auswahl von eines Service-Templates \u00f6ffnet. Nach der Wahl eines Templates kann der Entwickler im Template hinterlegte Variablen \u00fcber ein Formular-Element ausf\u00fcllen, um den zu erstellenden Service zu individualisieren. \u00dcber einen Button „CREATE“ am Ende des Formulars best\u00e4tigt der Entwickler die Eingaben und ein Projekt wird mit den zuvor get\u00e4tigten Konfigurationen und den hinterlegten Inhalten des Templates erstellt.<\/div>\n
2 Service Information Gathering<\/strong><\/p>\nAblauf des „Service Information Gathering“ Usecases<\/figcaption><\/figure>\n
Eine Kernfunktionalit\u00e4t von Backstage ist die Aggregation aller Daten zu Services um als Single-Source-Of-Truth aufzutreten. Um sich \u00fcber einen Service zu Informieren, \u00f6ffnet ein Entwickler dazu die Backstage Instanz seines Unternehmens und navigiert zur Service\u00fcbersicht und dem Service \u00fcber den er sich informieren m\u00f6chte. Auf der Hauptansicht des Services in Backstage hat er die M\u00f6glichkeiten \u00fcber mehrere Aspekte des Services zu informieren. Dazu geh\u00f6ren CI\/CD-Pipelines, die bereitgestellten Schnittstellen und Beziehungen zu anderen Services. Weitere Informationen k\u00f6nnen \u00fcber Plugins und weitere Integrationen auf der \u00dcbersicht des Services hinterlegt werden. Gen\u00fcgen die hinterlegten Informationen nicht aus, kann der Entwickler \u00fcber Verlinkungen zu den Besitzern des Services Kontakt aufnehmen.<\/div>\n
3 Service Discovery<\/strong><\/p>\nAblauf des Service Discovery Workflow<\/figcaption><\/figure>\n
Backstage bietet Entwicklern die M\u00f6glichkeit sich zentral \u00fcber alle Services ihres Unternehmens zu informieren und so \u00fcber die Notwendigkeit der Entwicklung neuer Services zu entscheiden. Dazu \u00f6ffnen sie die Backstage Instanz ihres Unternehmens und navigieren zu der \u00dcbersichtsseite f\u00fcr Services. Dort k\u00f6nnen sie sich \u00fcber verschiedene Wege Services entdecken. Zu diesen z\u00e4hlen ein Pr\u00fcfen der angezeigten Liste an Services auf unbekannte Eintr\u00e4ge, der Suche nach Service anhand dessen Beschreibung oder ein Navigieren \u00fcber die je Service hinterlegten Beziehungen zu anderen Services. So kann beispielsweise ein neuer Service, welcher von APIs eines bekannten Services abh\u00e4ngt entdeckt werden. Entwickler k\u00f6nnen sich dann \u00fcber den entdeckten Service \u00fcber dessen Service\u00fcbersicht informieren. Fehlen f\u00fcr eine Entscheidung weitere Informationen k\u00f6nnen die Besitzer des Service kontaktiert werden. Sofern kein entsprechender Service gefunden wird oder ein existierender Serivce die Funktionalit\u00e4t nicht wie ben\u00f6tigt bereitstellt, kann ein neuer Service gebaut werden. Ist dies nicht der Fall, kann die Neuentwicklung eines Services abgelehnt und somit redundante Serivce vermieden werden.<\/div>\n
4 Plugin Integration<\/strong><\/p>\nAblauf des Plugin Integration Workflows<\/figcaption><\/figure>\n
Backstage versteht sich als Framework zur Erstellung eines Internal Developer Portals. Als solches bietet es neben Kernfunktionalit\u00e4t die M\u00f6glichkeit \u00fcber Plugins Erweiterungen einzubinden. Es existieren dabei \u00fcber 250 \u00f6ffentliche Plugins, welche in eigene Backstage Instanzen integriert werden k\u00f6nnen. Alternativ ist die Entwicklung eigener Plugins m\u00f6glich, wobei der Aufbau einem von mehreren von Backtage bereitgestellten Templates folgen sollte, um langfristige Kompatabilit\u00e4t sicherzustellen. Die Inhalte des eigenentickelten Plugins k\u00f6nnen frei angepasst werden. Um das neuintegrierte Plugin in der firmeninternen Instanz bereitstellen k\u00f6nnen, muss die Backstage App neu kompiliert und anschlie\u00dfend die aktuelle laufende Instanz neugestartet werden<\/div>\n
<\/h2>\n
Alternativen zu Backstage<\/h2>\n
Backstage ist nicht die einzige L\u00f6sung f\u00fcr interne Developer Portals. Die Wahl h\u00e4ngt von Teamgr\u00f6\u00dfe, Anpassungsbedarf und vorhandenen Ressourcen ab. Die L\u00f6sungen lassen sich in drei Kategorien einteilen:<\/div>\n
1. Kommerzielle SaaS-Plattformen<\/strong> Produkte wie Cortex, Port, OpsLevel und Atlassian Compass bieten Service-Kataloge, Ownership Modelle und Scorecards als Managed Service. Sie punkten mit schnellem Setup, geringem Betriebsaufwand und professionellem Support. Der Nachteil: Tiefe Anpassungen, eigene Plugins oder enge Integrationen sind nur begrenzt m\u00f6glich und die Vendor-Lock-in ist hoch. Wie im Vergleich oben sichtbar wird, sind diese Tools ideal f\u00fcr Teams, die schnell starten und wenig Customizing ben\u00f6tigen.<\/div>\n
2. Managed Backstage<\/strong>\u00a0Roadie<\/strong> ist ein spezialisierter Service, der Backstage hostet, wartet und skaliert. Unternehmen profitieren vom vollen Backstage \u00d6kosystem (Plugins, Community), ohne ein dediziertes Platform Team aufbauen zu m\u00fcssen. Die Kosten liegen deutlich unter dem Eigenbetrieb (ca. 150.000 \u20ac j\u00e4hrlich f\u00fcr 20 Entwickler), w\u00e4hrend Roadie SLA gesch\u00fctztes Hosting, Updates und Enterprise-Sicherheit liefert. Die Customization Optionen bleiben weitestgehend erhalten, im Gegensatz zu rein propriet\u00e4ren Tools.<\/div>\n
3. Tool-basierte Ans\u00e4tze<\/strong> Kleinere Teams nutzen oft GitHub\/GitLab, Confluence und Monitoring Dashboards als dezentrale Alternative. Dies ist kosteng\u00fcnstig und schnell umsetzbar, skaliert aber schlecht. Es fehlt die einheitliche Sicht auf Services, Ownership und Standards.<\/div>\n
<\/h2>\n
Fazit<\/h2>\n
Backstage ist eine Open-Source Plattform mit maximaler Flexibilit\u00e4t und starker Community, aber das kommt mit Kosten. Hoher Personaleinsatz, eine lernkurve und ein dediziertes Platform Team\u00a0 sind f\u00fcr den erfolgreichen Betrieb essentiell. F\u00fcr kleinere Teams oder Organisationen ohne klare Plattform Strategie ist Backstage oft aufw\u00e4ndiger als das es einem Mehrwert bringt. Hier sind kommerzielle Alternativen oder Roadie die bessere Wahl. F\u00fcr gro\u00dfe wachsende Techlandschaften mit Bedarf an ma\u00dfgeschneiderten Workflows bleibt Backstage die f\u00fchrende Option.<\/div>\n
<\/h2>\n
Zukunftsausblick<\/h2>\n
Backstage entwickelt sich 2026 weiter zielgerichtet. Die Betreiber konzentrieren sich auf Stabilit\u00e4t, Skalierbarkeit und Community Governance:<\/div>\n
\n
\n
Neues Frontend-System<\/strong>: Die Backstage Roadmap priorisiert die finale Adoptionsreife eines modernisierten Frontend-Stacks. Das soll Wartbarkeit und Performance f\u00fcr gro\u00dfe Installationen deutlich verbessern.<\/div>\n<\/li>\n
\n
Offenere Community-Prozesse<\/strong>: Pull Requests und Issues werden transparenter und integrativer abgewickelt, um mehr Contributors in Reviews und Entscheidungen einzubinden. Das reduziert Abh\u00e4ngigkeiten von einzelnen Maintainern und beschleunigt die Entwicklung.<\/div>\n<\/li>\n
\n
Marktreife<\/strong>: Laut DX-Report bleibt Backstage das etablierte Open-Source Tool des Developer Portal Marktes mit 89% Marktanteil.<\/div>\n<\/li>\n<\/ul>\n
Backstage Was ist Backstage? Backstage ist eine Developer-Portal-Plattform, die als zentraler Hub f\u00fcr alle entwicklerrelevanten Informationen, Tools und Workflows dient.<\/p>\n","protected":false},"author":229,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-4428","post","type-post","status-publish","format-standard","hentry","category-betriebliche-informationssysteme"],"_links":{"self":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/4428","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/users\/229"}],"replies":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/comments?post=4428"}],"version-history":[{"count":18,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/4428\/revisions"}],"predecessor-version":[{"id":4711,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/4428\/revisions\/4711"}],"wp:attachment":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media?parent=4428"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/categories?post=4428"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/tags?post=4428"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Catalog](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2026\/01\/Screenshot-2026-01-12-150353-e1768226888130.png\")
<\/p>\n![\"Ablauf](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2026\/01\/service_setup-300x57.png\")
![\"Ablauf](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2026\/01\/service_information_gathering.png)
![\"Ablauf](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2026\/01\/service_discovery-300x145.png\")
![\"Ablauf](\"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-content\/uploads\/2026\/01\/plugin_integration.png-300x111.png\")