Backstage to otwartoźródłowy portal deweloperski stworzony w Spotify, który zbiera w jednym miejscu informacje o usługach, właścicielach, dokumentacji i narzędziach firmy. Pokazujemy, co daje programistom, liderom, zespołowi platformowemu i zarządowi, ile pracy wymaga i kiedy jest przesadą.
CEO
26 lip 2026
Nowy programista dostaje dostęp do repozytoriów i pierwsze zadanie: poprawić błąd w usłudze płatności. Zanim napisze linijkę kodu, musi ustalić, gdzie ta usługa działa, kto za nią odpowiada, gdzie jest dokumentacja i dlaczego są dwie wersje z podobną nazwą. Backstage, czyli otwartoźródłowy portal deweloperski stworzony w Spotify, odpowiada na takie pytania w jednym miejscu. Czym jest i dlaczego zespoły developerskie go wdrażają? Bo w firmach z dziesiątkami usług ta wiedza zwykle żyje w głowach kilku osób.
Backstage nie jest kolejnym narzędziem do pisania kodu. To raczej mapa całego oprogramowania firmy, na której każdy element ma właściciela, opis, dokumentację i link do miejsc, gdzie działa.
Spotify zbudowało Backstage na własne potrzeby, gdy liczba usług i zespołów urosła tak, że nikt nie ogarniał całości. W marcu 2020 roku firma udostępniła projekt jako open source, a później przekazała go fundacji CNCF (Cloud Native Computing Foundation), która opiekuje się m.in. Kubernetesem. Dziś Backstage ma tam status projektu w fazie inkubacji. Skala jest duża. Według danych podanych przy okazji piątych urodzin projektu, które cytuje The New Stack, z Backstage korzysta ponad 3400 organizacji i ponad 2 mln programistów spoza Spotify, a w samym Spotify portal używa 96% działu badań i rozwoju.
Technicznie Backstage to aplikacja webowa napisana w TypeScripcie, z interfejsem w React.js, backendem w Node.js i bazą PostgreSQL. Ma to znaczenie praktyczne: firma, która chce go dopasować do siebie, potrzebuje ludzi znających te technologie.
Rdzeń Backstage to kilka modułów, na które nakłada się dowolne wtyczki.
Katalog to spis wszystkiego, co firma utrzymuje: usług, aplikacji, bibliotek, baz danych, potoków danych, stron internetowych. Każdy element ma właściciela, opis, zależności i linki. Dane nie są wpisywane ręcznie w portalu. Zespół dodaje do repozytorium krótki plik opisujący komponent, a Backstage sam go odczytuje i aktualizuje.
Szablony pozwalają założyć nową usługę kilkoma kliknięciami. Programista wybiera na przykład „nowa usługa w Node.js”, podaje nazwę i zespół, a Backstage tworzy repozytorium z gotową strukturą, konfiguracją CI/CD, czyli automatycznego budowania, testowania i wdrażania, monitoringiem i wpisem w katalogu. To podobny pomysł jak w generatorach projektów typu Yeoman, ale zintegrowany z infrastrukturą firmy.
TechDocs to dokumentacja pisana obok kodu, w zwykłych plikach tekstowych w repozytorium, i wyświetlana w portalu przy właściwym komponencie. Programiści aktualizują ją przy zmianie kodu, a nie w osobnej wiki, do której nikt nie zagląda. To rozwiązuje stary problem: dokumentacja techniczna jest potrzebna, ale rzadko bywa aktualna.
Wyszukiwarka przeszukuje katalog, dokumentację i źródła podłączone przez wtyczki. A wtyczek jest ponad 200: do Kubernetesa, Argo CD, Jenkinsa, Sentry, Swaggera, chmur AWS, Azure i Google Cloud oraz wielu innych narzędzi. Dzięki nim karta usługi pokazuje w jednym miejscu, czy ostatnie wdrożenie się powiodło, jakie są błędy na produkcji i ile instancji działa.
Dla nowej osoby w zespole Backstage jest przede wszystkim przewodnikiem. Zamiast pytać na czacie, kto zna usługę płatności, otwiera jej kartę. Widzi właściciela, dokumentację, adres API, zależności od innych usług i ostatnie wdrożenia. Zmienia to tempo onboardingu, czyli wdrażania nowego pracownika w pracę zespołu. Pierwsze tygodnie mniej przypominają archeologię, a doświadczeni programiści rzadziej odrywają się od pracy, żeby tłumaczyć to samo kolejnym osobom.
Szablony pomagają też w pierwszym samodzielnym zadaniu. Nowa usługa od razu spełnia standardy firmy, bo powstała z szablonu, a nie przez skopiowanie losowego starego projektu.
Lider odpowiada za usługi swojego zespołu, także te, które napisał ktoś, kto dawno odszedł. W katalogu widzi wszystko, co do zespołu należy, i od razu zauważa elementy bez właściciela. To częstszy problem, niż się wydaje. W firmach z kilkudziesięcioma usługami zwykle znajdzie się kilka, za które formalnie nikt nie odpowiada, dopóki nie przestaną działać. Backstage pozwala też sprawdzać, czy usługi spełniają ustalone standardy: czy mają testy, aktualne zależności, monitoring, opis API. Część firm robi z tego karty oceny, na których widać, które usługi wymagają uwagi. Wymaga to dodatkowych wtyczek, ale daje liderowi konkretna listę zamiast ogólnego poczucia, że „coś trzeba posprzatać”.
Przy decyzjach architektonicznych katalog porządkuje kontekst. Jeśli zespół prowadzi rejestr decyzji architektonicznych (ADR), może go trzymać w TechDocs obok usługi, której dotyczy.
Zespół platformowy buduje wewnętrzną infrastrukturę, z której korzystają pozostałe zespoły. Ta specjalizacja nazywa się platform engineering, a Backstage stał się dla niej najpopularniejszą warstwą widoczną dla użytkowników. Dla takiego zespołu najważniejsze są szablony, bo pozwalają wyznaczyć tak zwaną „złotą ścieżkę”: zalecany, sprawdzony sposób robienia typowych rzeczy. Nowa usługa z szablonu dostaje od razu konfigurację Dockera, definicję infrastruktury w Terraformie, potok wdrożeniowy w modelu GitOps i podpięty monitoring. Zespoły nadal mogą zrobić coś po swojemu, ale droga domyślna jest najprostsza.
Szablony porządkują też bezpieczeństwo. Jeśli reguły skanowania kodu i zarządzania sekretami są wpisane w szablon, każda nowa usługa je ma. To praktyczna forma podejścia security as code, w którym zasady bezpieczeństwa są zapisane w kodzie, a nie w dokumencie.
Nowsze wersje Backstage pozwalają też udostępniać akcje z katalogu i szablonów agentom AI przez MCP, czyli standardu łączenia modeli AI z narzędziami. Asystent programisty, na przykład Claude Code, może wtedy sprawdzić w katalogu właściciela usługi albo założyć nową usługę z szablonu. To obszar, który wciąż się zmienia, więc aktualny stan trzeba sprawdzić przed planowaniem.
Dla właściciela firmy czy dyrektora technicznego Backstage odpowiada na pytania, które zwykle wymagają kilku spotkań. Ile usług utrzymujemy? Które zespoły mają ich najwięcej? Które systemy nie mają właściciela albo opierają się na przestarzałych technologiach? Pomaga to przy planowaniu. Gdy w katalogu widać trzy różne usługi do wysyłki e-maili zbudowane przez trzy zespoły, decyzja o ujednoliceniu jest prosta. Gdy widać, że połowa usług zależy od starej biblioteki, łatwiej oszacować koszt jej wymiany.
Jest też wymiar ryzyka. Wiedza zapisana w katalogu i dokumentacji nie odchodzi z firmy razem z pracownikiem. To ma znaczenie zwłaszcza tam, gdzie część pracy wykonują zewnętrzni wykonawcy, a decyzja o tym, czy budować własny zespół, czy korzystać z outsourcingu IT, zmienia się w czasie.
Tu zaczyna się część, o której mniej się mówi. Backstage to framework do zbudowania portalu, a nie gotowy produkt. Po instalacji dostaje się szkielet, który trzeba skonfigurować, podłączyć do systemów firmy, wypełnić danymi i utrzymywać. Projekt wydaje nową wersję co miesiąc. Aktualizacje bywają pracochłonne, zwłaszcza przy wielu wtyczkach i własnych modyfikacjach. Według ankiet wśród użytkowników cytowanych przez Bex aktualizacje to największy problem dla 56% firm korzystających z Backstage. Ten sam tekst zwraca uwagę na drugi kłopot: poza Spotify z portalu korzysta na co dzień zwykle tylko niewielka część programistów, dla których został wdrożony.
Ta druga liczba jest ważniejsza od pierwszej. Portal, którego nikt nie otwiera, nie daje nic. Dzieje się tak, gdy katalog jest niekompletny, dane nieaktualne, a ludzie szybciej znajdą odpowiedź na czacie.
Dla firm, które nie chcą utrzymywać Backstage samodzielnie, są wersje hostowane. Spotify oferuje płatny Spotify Portal, a firma Roadie prowadzi Backstage jako usługę. Obok rozwijają się konkurencyjne portale, takie jak Port czy Cortex, które są gotowymi produktami, ale dają mniej swobody w dopasowaniu.
Backstage rozwiązuje problem skali. W firmie z jednym zespołem i kilkoma aplikacjami ten problem nie istnieje, a dobrze prowadzone README i jedna strona wiki wystarczy. Sygnały, że portal może się opłacić, wyglądają zwykle tak:
Jeśli firma ma jedną dużą aplikację, rozsądniejsze bywa uporządkowanie jej struktury niż budowanie portalu. Wybór między mikroserwisami a monolitem ma tu znaczenie: w monolicie lista usług jest krótka z definicji. Podobnie przy jednym repozytorium dla wszystkich projektów, gdzie część korzyści katalogu daje sama struktura, co dobrze widać przy porównaniu monorepo i wielu repozytoriów.
FAQ
Blog
Architektura mikroserwisowa staje się nowym standardem w budowie i zarządzaniu aplikacjami. Pozwalając na podzielenie całego systemu na mniejsze, niezależne serwisy, ułatwia naszą pracę, podnosi wydajność i skalowalność. Czy to oznacza, że mikroserwisy są przyszłością IT? Przyjrzyjmy się bliżej tej koncepcji.
Mikroserwisy versus Monolit to dwie konkurencyjne podejścia do budowy systemów informatycznych. Obie architektury mają swoje atuty i słabości, a wybór pomiędzy nimi może być kluczowy dla sukcesu projektu. Celem tego artykułu jest dogłębne zrozumienie i porównanie tych dwóch podejść.
Wybór między Monorepo a Multi-Repo to kluczowe decyzje architektoniczne w zarządzaniu projektami IT. Odpowiedni dobór może istotnie wpłynąć na efektywność pracy, jak i łatwość utrzymania projektu. Warto zatem rozeznać argumenty przemawiające za obiema opcjami, zanim podejmie się decyzję.
Architecture Decision Record (ADR) to narzędzie gwarantujące przejrzystość i zrozumienie kierunków projektu IT. Formuje ono dokumentację, która pomaga zrozumieć, dlaczego pewne koncepcje zostały przyjęte lub odrzucone. ADR to klucz, który odkrywa istotę strategicznych decyzji w projektach IT.
CI/CD to skrót od Continuous Integration i Continuous Delivery, czyli procesów ciągłej integracji i ciągłego dostarczania. Jest to metoda zarządzania projektem oprogramowania, która polega na ciągłym i automatycznym sprawdzaniu, testowaniu i wdrażaniu kodu do produkcji.
W świecie IT bezpieczeństwo jest kluczowym aspektem każdego procesu deweloperskiego. W dobie przyspieszającej cyfryzacji, zapewnienie bezpieczeństwa należy do kluczowych obowiązków każdego dewelopera. Bezpieczeństwo, jak każda inna funkcjonalność, również może być kodowane. Poruszając temat 'Bezpieczeństwa jako Kod: Podstawy Bezpiecznego DevOps' wnioskujemy, że istotne jest łączenie praktyk DevOps z najlepszymi praktykami z zakresu bezpieczeństwa.
