Od marca 2026 r. darmowy Postman obsługuje tylko jednego użytkownika, a kolekcje zapytań do API wciąż są głównie w chmurze dostawcy. Wyjaśniamy, czym jest Bruno, ile kosztuje przejście i w jakich zespołach nie ma ono sensu.
CEO
05 sie 2026
Programistka odchodzi z firmy po kilku latach pracy. Kod aplikacji jest w repozytorium, dokumentacja w wiki, ale kilkaset zapytań do API, z danymi testowymi, kolejnością wywołań i skryptami sprawdzającymi odpowiedzi, zostało na jej koncie w Postmanie. Następca odtwarza je tygodniami. Bruno, open source’owa alternatywa dla Postmana, powstał między innymi po to, żeby taka sytuacja nie mogła się zdarzyć: kolekcje zapytań trzyma jako zwykłe pliki, w tym samym miejscu co kod.
W 2026 r. temat wrócił z powodów czysto finansowych
Od 1 marca darmowy plan Postmana obejmuje jednego użytkownika i nie pozwala utworzyć zespołu, a wcześniej mogły z niego korzystać trzy osoby. Małe zespoły, które latami pracowały za darmo, dostały rachunek. Część z nich zaczęła rozglądać się za czymś innym.
API, czyli interfejs programistyczny, to umówiony sposób, w jaki dwa systemy wymieniają dane, na przykład sklep internetowy z ERP albo aplikacja mobilna z serwerem. Klient API to program, w którym programista lub tester ręcznie wysyła zapytania do takiego interfejsu i ogląda odpowiedzi. Bez niego każde sprawdzenie, czy integracja działa, wymagałoby pisania kodu. Z czasem zapytania układają się w kolekcje. Kolekcja to uporządkowany zestaw wywołań: logowanie, pobranie listy zamówień, wystawienie faktury, zmiana statusu dostawy, z osobnymi danymi dla środowiska testowego i produkcyjnego. Do tego dochodzą skrypty, które same sprawdzają, czy odpowiedź ma właściwy kształt. Dobrze prowadzona kolekcja jest żywą dokumentacją integracji. Często bardziej aktualną niż opis w wiki.
Dlatego ma znaczenie, gdzie ta wiedza leży i kto ma do niej dostęp. W firmach pracujących w podejściu API-first kolekcje powstają wcześniej niż kod aplikacji i służą kilku zespołom naraz. Ich utrata albo rozproszenie po prywatnych kontach kosztuje realne godziny pracy.
Narzędzie Postman przez lata było domyślnym wyborem i w wielu firmach nadal nim jest. Z prostego klienta rozrosło się w platformę z dokumentacją, monitoringiem, serwerami udającymi prawdziwe API (tzw. mockami), katalogiem interfejsów, a ostatnio także funkcjami AI. Dla części zespołów to zaleta. Dla innych nadmiar, za który trzeba płacić. Pierwszy zgrzyt pojawił się w maju 2023 r., kiedy Postman wygasił tryb Scratch Pad, czyli pracę lokalną bez konta. Od tego czasu kolekcje i środowiska wymagają zalogowania, a dane synchronizują się z chmurą dostawcy. W firmach z branż regulowanych, takich jak finanse czy medycyna, oznaczało to kolejną rozmowę z działem bezpieczeństwa. Drugi temat to sekrety, czyli klucze API, tokeny i hasła trafiające do zmiennych w kolekcjach. W grudniu 2024 r. firma CloudSEK opisała ponad 30 tys. publicznie dostępnych przestrzeni roboczych Postmana, z których wyciekały takie dane. Nie był to atak na samego Postmana. Zawiniły ludzkie pomyłki: przestrzeń ustawiona jako publiczna, token wpisany na stałe, kolekcja udostępniona zbyt szeroko. Narzędzie, które domyślnie wysyła wszystko do chmury, zostawia jednak na takie błędy więcej miejsca.
Trzecim powodem są pieniądze. Funkcje zespołowe zaczynają się od planu Team, a plan Team kosztuje 19 USD za użytkownika miesięcznie przy płatności rocznej. Przy kilkunastu osobach to już pozycja w budżecie, którą ktoś w końcu zauważa.
Bruno to klient API na Windows, macOS i Linuxa, którego kod źródłowy udostępniono na licencji MIT. Obsługuje REST, GraphQL, gRPC i WebSocket, a więc style komunikacji, z których korzysta większość współczesnych aplikacji. Najważniejsza różnica wobec Postmana nie leży jednak w liście funkcji. Chodzi o to, gdzie trafiają dane.
Każde zapytanie Bruno zapisuje jako osobny plik tekstowy we wskazanym folderze: we własnym formacie .bru albo, od wersji 3.0, w otwartym formacie OpenCollection opartym na YAML. Folder można umieścić w repozytorium Git razem z kodem aplikacji. Git to system kontroli wersji, który zapisuje historię każdej zmiany, pokazuje, kto co zmienił, i pozwala cofnąć pomyłkę. Konsekwencje są bardziej organizacyjne niż techniczne. Zmiana w kolekcji przechodzi ten sam przegląd co zmiana w kodzie. Nowa osoba dostaje kolekcje razem z repozytorium, bez zapraszania do kolejnego narzędzia. A gdy firma kończy współpracę z wykonawcą, kolekcje zostają u niej, bo nigdy nie leżały nigdzie indziej.
Twórcy deklarują w repozytorium projektu, że Bruno działa wyłącznie lokalnie i że synchronizacji z chmurą nie planują. Konto nie jest potrzebne. Program po prostu otwiera folder.
Hasła i tokeny Bruno trzyma poza plikami kolekcji: jako zmienne oznaczone jako sekretne albo w pliku .env, a w planach firmowych także w zewnętrznych menedżerach sekretów, takich jak HashiCorp Vault czy AWS Secrets Manager. Według dokumentacji zarządzania sekretami w Bruno wartości są szyfrowane lokalnie i usuwane z kolekcji przed jej udostępnieniem.
Nie zwalnia to z dyscypliny. Plik .env trzeba wykluczyć z repozytorium, a wyciek z publicznego repozytorium jest tak samo groźny jak z publicznego workspace’u. Jeśli nie wiesz, jak wygląda to w twoich projektach, rozsądnym krokiem jest audyt bezpieczeństwa aplikacji obejmujący także sposób przechowywania kluczy.
Programista zauważa różnicę w pierwszej godzinie. Bruno uruchamia się szybko, nie prosi o logowanie i otwiera kolekcje jak folder w edytorze. Skrypty pisze się w JavaScripcie, podobnie jak w Postmanie, więc testy odpowiedzi wyglądają znajomo. Trzeba uczciwie dodać, że Postman w 2026 r. odrobił część zaległości. Od marca oferuje Native Git, czyli pracę na kolekcjach zapisanych w lokalnym repozytorium. Zmiany trafiają jednak docelowo do chmury Postmana, która pozostaje miejscem dzielenia się wiedzą między zespołami. W Bruno chmury nie ma w ogóle. To nie brak, tylko założenie projektu.
Postman wygrywa tam, gdzie firma potrzebuje platformy, a nie narzędzia. Ma monitoring uruchamiany w chmurze według harmonogramu, publikowanie dokumentacji API dla partnerów, publiczną sieć API i wygodną pracę dla osób, które nie dotykają repozytorium. W Bruno część tych rzeczy składa się z innych elementów. Zaplanowane testy uruchamia potok CI/CD, czyli automat, który po każdej zmianie buduje i sprawdza aplikację.
Dokumentację dla partnerów utrzymuje się osobno, na przykład w specyfikacji OpenAPI prezentowanej przez Swaggera. Wymaga to trochę więcej pracy przy konfiguracji, za to każdy element da się wymienić bez zmiany całego zestawu narzędzi.
Do uruchamiania kolekcji w potokach CI/CD Bruno ma bezpłatne narzędzie wiersza poleceń. Uruchamia ono całe kolekcje w wybranym środowisku i zapisuje raporty w formatach JSON, JUnit lub HTML, które rozumie większość systemów budowania. Te same zapytania, które programista klika lokalnie, stają się automatycznym testem integracji. To dobre uzupełnienie testów oprogramowania prowadzonych przez QA, choć ich nie zastępuje.
Ceny z września 2026 r., netto, w dolarach amerykańskich, przy płatności rocznej:
Dla dziesięcioosobowego zespołu daje to 2280 USD rocznie w Postman Team wobec 720 USD w Bruno Pro albo 1320 USD w Ultimate. Wersja open source nie kosztuje nic.
Jest jeden haczyk. W bezpłatnej edycji Bruno nie ma obsługi Gita wbudowanej w interfejs programu. Pliki i tak leżą w folderze, więc programiści zapisują zmiany z terminala albo edytora kodu, jak każdy inny plik. Kłopot mają osoby, które z Gitem na co dzień nie pracują, na przykład testerzy manualni czy analitycy. Dla nich wygodniejszy będzie plan Pro. Licencja to zresztą zwykle mniejsza część rachunku. Więcej kosztuje czas zespołu na przeniesienie kolekcji i przepisanie nietypowych skryptów, a do tego kilka tygodni, zanim wszyscy przestawią nawyki. Przy kilku kolekcjach to godziny, przy kilkuset z rozbudowanymi testami - tygodnie. Oszczędność szybciej się zwraca w zespole, który dopiero układa sposób pracy z API, niż w takim, który od lat trzyma w Postmanie całą automatyzację.
Są sytuacje, w których zmiana narzędzia przyniesie więcej kłopotu niż pożytku:
Osobny przypadek to organizacja z Postmanem w planie Enterprise, zintegrowanym logowaniem i ustalonymi zasadami dostępu. Tam rozmowa o Bruno rzadko dotyczy kosztów. Dotyczy tego, czy wiedza o integracjach ma leżeć w repozytorium firmy, czy na platformie zewnętrznego dostawcy. To decyzja architektoniczna, a nie zakupowa.
Najlepiej Bruno pasuje do zespołów, które i tak trzymają wszystko w Gicie albo mają wymagania co do przechowywania danych poza chmurą dostawców. Dobrze sprawdza się też tam, gdzie jeden zespół prowadzi projekty dla wielu klientów: każdy klient dostaje kolekcje w swoim repozytorium i nic się nie miesza.
Migrację najlepiej potraktować jak mały projekt, a nie jednorazowy import. Sprawdza się taka kolejność:
Najwięcej problemów sprawiają zwykle nie same zapytania, tylko drobiazgi. Bruno zapisuje wszystkie wartości zmiennych jako tekst, więc liczba 5000 staje się napisem „5000”. Nazwy środowisk ze znakami spoza dozwolonego zestawu trzeba zmienić. Testy zależne od kolejności wywołań potrafią zachowywać się inaczej. Dlatego godzina pilotażu na prawdziwej kolekcji mówi więcej niż porównania funkcji w tabelach.
Konfigurację potoków, sekretów w środowisku CI i uprawnień do repozytoriów zespoły często robią przy okazji szerszego przeglądu procesów DevOps i architektury. Zmiana klienta API bywa dobrym pretekstem, żeby uporządkować całość.
Jeśli zlecasz rozwój oprogramowania zewnętrznej firmie, zapytaj, gdzie są trzymane kolekcje zapytań do API i na czyim koncie. To pytanie rzadko pada przy podpisywaniu umowy, a wraca przy zmianie wykonawcy. Kolekcje w repozytorium należącym do klienta rozwiązują problem u źródła, niezależnie od tego, czy powstały w Bruno, czy w Postmanie z Native Git. Warto dopisać je do listy kontrolnej przekazania projektu, obok dostępów do serwerów i dokumentacji. Ta sama zasada obowiązuje, gdy firma rozbudowuje zespół o zewnętrznych programistów. Ludzie przychodzą i odchodzą w rytmie projektów, a wiedza o integracjach powinna zostać w firmie.
W zespołach wewnętrznych kolekcje rozproszone po prywatnych kontach to odmiana długu technologicznego w projekcie IT. Rośnie po cichu i wychodzi na jaw dopiero wtedy, gdy odchodzi jedna osoba.
Na początek wystarczy jedna prośba do zespołu: spis wszystkich miejsc, w których są dziś kolekcje API, z informacją, kto ma do nich dostęp. Jeśli odpowiedź brzmi „u każdego trochę”, przenieś do repozytorium jedną, najczęściej używaną kolekcję. Samo przeniesienie niewielkiej kolekcji to kwestia godzin, a dwa tygodnie pracy na niej powiedzą więcej niż jakiekolwiek zestawienie. Jeśli chcesz, żeby ktoś z zewnątrz ocenił, czy zmiana narzędzia ma sens w twoim przypadku, napisz do nas przez formularz kontaktowy Boring Owl.
FAQ
Blog
API-first to innowacyjna strategia w sferze IT, zdobywająca coraz większą popularność. Stawiając na nią, projektanci systemów IT potrafią skuteczniej reagować na dynamicznie zmieniające się potrzeby rynku. Czym więc jest API-first i dlaczego zdobywa coraz większą popularność w biznesie 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.
GitLab CI/CD to uniwersalne narzędzie, które służy do automatyzacji procesów w ramach dewelopmentu oprogramowania. Umożliwia przeprowadzanie badań, testów, a także implementacje za pomocą samego GitLab. Jego główne zalety to możliwość skracania czasu wdrożeń oraz większa łatwość zarządzania projektem.
W dobie szybko rozwijającej się informatyki, zwinnego podejścia w budowaniu oprogramowania, wydajne i efektywne testowanie aplikacji jest kluczowe. W tym kontekście, REST Assured wyróżnia się jako potężne narzędzie do automatyzacji testów API, dostarczane za pomocą Java. Odkryjmy, jak usprawnić proces testowania i gwarantować wysoką jakość oprogramowania.
Rozpoczęcie nowego projektu IT to zawsze ekscytujący moment, ale równie ważne jest jego właściwe zakończenie. Dokument zwany Project Handover Checklist jest bezcenny dla zarządzania projektem IT. To lista kontrolna przekazania projektu, która zawiera wszystkie kluczowe elementy niezbędne do prawidłowego i bezproblemowego przekazania projektu. W tym artykule omówimy, co powinno znaleźć się na takiej liście, od A do Z.
Efektywne zarządzanie długiem technologicznym jest kluczowe dla zdrowia każdego projektu IT. W artykule poruszamy praktyczne strategie, które pomogą zrozumieć i kontrolować ten często niedoceniany element procesu deweloperskiego. Odkryjemy, jak dług technologiczny wpływa na wydajność, koszty i plany rozwoju.
