Przejdź do treści
Własny hostingSerwer udostępniamy na prośbę

Uruchom serwer tam, gdzie już pracujesz

Serwer Crunu z założenia nie może odczytać wartości. Na app.crunu.com czy na infrastrukturze, którą kontrolujesz, przechowuje zaszyfrowane dane, klucze publiczne i podpisane rekordy i nie ma żadnego klucza, który odszyfrowałby choć jedną wartość.

Przykład. Kiteline to fikcyjna firma.

Co przygotować

  • 1Node.js 24 i kod serweraDziałają na nim narzędzia operatora server-init, doctor i crunu-server. Serwera nie można pobrać publicznie: napisz na support@crunu.com, żeby go otrzymać.
  • 2Adres, który zachowaszPodpisy logowania, linki dostępu, klucze dostępu i agenci są powiązani z domeną serwera, więc nie da się jej później zmienić.
  • 3Bezpieczne miejsce na .envWystarczy menedżer haseł. Plik zawiera SERVER_KEY – główny sekret serwera.

Raz na serwer

Instalacja

Pięć kroków prowadzi od pustej maszyny lub konta w chmurze do działającego serwera z pierwszym właścicielem.

  1. 1Zdecyduj, kto prowadzi serwer

    Szyfrowanie odbywa się w przeglądarce i w agencie crunu, nigdy na serwerze. Wybór między app.crunu.com a własnym serwerem dotyczy więc tego, kto go obsługuje i kto widzi jego metadane. W żadnym z tych przypadków nikt po stronie serwera nie odczyta twoich wartości.

    • app.crunu.com: serwer prowadzi Crunu na Cloudflare Workers z bazą danych D1, bezpłatnie we wczesnym dostępie
    • Własny serwer: prowadzisz go ty, płacisz dostawcy platformy i tylko ty widzisz jego metadane
    • Metadane to nazwy organizacji, projektów, środowisk i maszyn, adresy e-mail, dziennik audytu oraz rozmiar i czas wersji
    Przykład. Kiteline to fikcyjna firma.
  2. 2Wygeneruj ustawienia serwera

    server-init zapisuje plik .env z nowym SERVER_KEY, jednorazowym BOOTSTRAP_TOKEN dla pierwszego właściciela i CRON_SECRET. Plik może odczytać tylko twój użytkownik.

    • Od razu zapisz kopię w menedżerze haseł
    • Utrata SERVER_KEY wylogowuje wszystkich i psuje linki dostępu. Dane środowisk pozostają nienaruszone
  3. 3Wybierz jedną z pięciu platform

    Każda platforma uruchamia ten sam serwer z tym samym schematem bazy danych, a aplikacja webowa jest w niego wbudowana. Każdy skrypt wdrożeniowy sprawdza .env tym samym kodem, którego serwer używa przy starcie, więc błędne ustawienie zatrzymuje wdrożenie z jasnym komunikatem.

    • Docker na własnym serwerze: Caddy wystawia certyfikaty TLS, a Cloudflare Tunnel sprawdza się, gdy nie chcesz otwartych portów
    • Cloudflare Workers: plan Free wystarczy na próbę, ale zespół potrzebuje Workers Paid, bo Free daje każdemu żądaniu 10 ms czasu procesora
    • Vercel: wersje podglądowe dostają własną bazę danych i klucz serwera, a w planie Hobby czyszczenie działa najwyżej raz dziennie
    • AWS App Runner tylko na kontach AWS, które już z niego korzystają: AWS zamknął go dla nowych klientów, a Crunu nie ma skryptu dla Amazon ECS Express Mode
    Przykład. Kiteline to fikcyjna firma.
  4. 4Wdróż skryptem dla platformy

    Jedno polecenie na platformę buduje i wdraża serwer. Sekrety trafiają na platformę przez stdin lub plik, który możesz odczytać tylko ty, nigdy przez argumenty polecenia ani jego wynik. Migracje bazy danych serwer stosuje sam przy starcie.

    • Ten sam skrypt instaluje pierwszą wersję i każdą aktualizację
    • Na Cloudflare kod i sekrety trafiają tam razem jako jedna wersja, więc nieudane wdrożenie niczego nie zmienia
  5. 5Utwórz pierwszego właściciela

    Otwórz adres serwera i wpisz klucz startowy z .env. Klucze twojego konta i organizacji powstają w przeglądarce, a klucz startowy przestaje działać po tym jednym użyciu. Następnie zapisz Emergency Kit, utwórz kod odzyskiwania i włącz drugi składnik.

    • Bez Emergency Kit i hasła nowe urządzenie nie może się zalogować
    • Wszyscy pozostali dołączają przez zaproszenie

Codziennie

Utrzymanie

Gdy serwer już działa, trzy nawyki utrzymują go w dobrej kondycji: sprawdzenie po każdym wdrożeniu, monitorowanie i codzienna kopia zapasowa.

  1. 6Sprawdź wdrożenie narzędziem doctor

    doctor sprawdza działający serwer z zewnątrz: stan, TLS i termin ważności certyfikatu, nagłówki bezpieczeństwa, kompresję odpowiedzi API, zegar serwera, wydanie agenta, migracje, czyszczenie i adres klienta za serwerami proxy.

    • Ogólny wynik i kod wyjścia, więc pasuje do crona i CI
    • --json daje wynik czytelny dla maszyn
  2. 7Obserwuj stan, metryki i alerty

    GET /v2/health współpracuje z narzędziami do monitorowania dostępności, takimi jak UptimeRobot czy Better Stack. GET /v2/status z tokenem operatora zwraca metryki w JSON lub w formacie Prometheus, bez wartości i bez adresów e-mail. Alerty docierają do zespołu przez podpisany webhook lub e-mailem.

    • Slack, Microsoft Teams i PagerDuty łączą się przez swoje przychodzące webhooki
    • Na Cloud Run i App Runner czyszczenie działa tylko przy ruchu, więc alerty oparte na stanie mogą przychodzić z opóźnieniem
  3. 8Rób kopie zapasowe w dowolnym magazynie

    crunu-server export zapisuje całą bazę danych do jednego archiwum. Nie zawiera ono jawnych wartości, więc możesz je przechowywać u dowolnego dostawcy. Plik .env trzymaj osobno, w menedżerze haseł.

    • Eksportuj codziennie i przechowuj kopie przez 30 dni. Serwer nie ma wbudowanego harmonogramu, a przewodnik po kopiach zapasowych podaje gotową linię crona dla Dockera
    • Co miesiąc sprawdzaj kopię, a najlepiej przywracaj ją do tymczasowej bazy danych
    • Przywrócenie cofa wszystko, co nastąpiło po kopii, a urządzenia, które widziały nowsze dane, odrzucają starszy stan, dopóki ich nie zresetujesz

W razie potrzeby

Zmiany

Przeniesienie, rotacja klucza serwera i aktualizacje korzystają ze skryptów wdrożeniowych i crunu-server, które już masz.

  1. 9Przenieś serwer na inną platformę jednym archiwum

    Wyeksportuj bazę danych, sprawdź archiwum, zaimportuj je do pustej bazy na nowej platformie i wdróż tam serwer z tym samym .env, a potem przełącz DNS. Każdą z sześciu konfiguracji można przenieść na każdą inną, w obu kierunkach.

    • Zachowaj ten sam SERVER_KEY i ten sam adres. Zmienia się tylko rekord DNS
    • Maszyny działają dalej na zmiennych, które już mają, przez czas dzierżawy, do 24 godzin
    • Utrzymaj starą platformę przez tydzień. Powrót to zmiana DNS
    Przykład. Kiteline to fikcyjna firma.
  2. 10Wymień klucz serwera bez wylogowywania kogokolwiek

    Podczas rotacji poprzedni klucz nadal działa, tokeny są ponownie haszowane nowym kluczem w miarę ich użycia, a rotate-key ponownie szyfruje sekrety TOTP i kanały alertów. Wszyscy pozostają zalogowani, a linki dostępu nadal się otwierają. Dane środowisk nigdy nie są szyfrowane tym kluczem.

    • Cztery kroki: new-server-key, wdrożenie, rotate-key, drop-previous-key
    • Wymień klucz, gdy ktoś mógł zobaczyć .env, po przeniesieniu albo raz w roku
  3. 11Aktualizuj bez osobnego kroku migracji

    Aktualizacja to ten sam skrypt wdrożeniowy co pierwsza instalacja, a migracje serwer stosuje przy starcie. Migracje tylko dodają, a wydane migracje chronią sumy kontrolne, więc możesz cofnąć kod bez cofania bazy danych.

    • Wydania aplikacji webowej są podpisane, a serwer udostępnia podpis, żeby wdrożoną stronę można było z nim porównać
    • Cofnięcie poniżej wersji 6.0 nie jest możliwe

Pytania o własny hosting

O co pytają operatorzy, zanim uruchomią własny serwer.

Masz inne pytanie? Napisz na support@crunu.com.

Czy app.crunu.com to to samo oprogramowanie, które mogę hostować samodzielnie?

Tak. app.crunu.com działa na tym samym serwerze Crunu, wdrożonym na Cloudflare Workers z bazą danych D1.

Czy osoby prowadzące app.crunu.com mogą odczytać moje sekrety?

Nie. Serwer przechowuje zaszyfrowane dane i nie ma klucza, żeby je odszyfrować. Jako operator Crunu widzi jednak metadane: nazwy organizacji, projektów, środowisk i maszyn, adresy e-mail, dziennik audytu oraz rozmiar i czas każdej wersji. Jedno ryzyko dotyczy każdego sejfu działającego w przeglądarce: przejęty serwer mógłby wysłać zmodyfikowaną aplikację webową, która zobaczy twoje hasło i Secret Key przy logowaniu. Podpisane wydania i ścisła polityka Content Security Policy zmniejszają to ryzyko, a resztę wyjaśnia strona ograniczeń.

Czy mogę później przejść z app.crunu.com na własny serwer?

Nie w jednym kroku. Archiwum, które przenosi serwer między platformami, powstaje z całej bazy danych serwera, a na app.crunu.com dostęp do niej ma tylko operator. W każdej chwili możesz wyeksportować każde środowisko, które możesz odczytać, jako plik .env albo pobrać kopię offline, a potem dodać te pliki na własnym serwerze. Historia, ustawienia dostępu i dziennik audytu nie przechodzą w ten sposób.

Czy AWS jest obsługiwany?

Częściowo. Skrypt Crunu wdraża na AWS App Runner, ale AWS zamknął App Runner dla nowych klientów, więc działa to tylko na kontach, które już z niego korzystają. Crunu nie ma skryptu dla Amazon ECS Express Mode – usługi, którą AWS poleca w zamian. Przy nowym koncie AWS wybierz Cloud Run, Vercel albo własny serwer.

Co dzieje się z maszynami i CI podczas przeniesienia?

Maszyny działają dalej na zmiennych, które już mają, przez czas dzierżawy, do 24 godzin. Poproś zespół, żeby przez 15–30 minut przełączania nie zmieniał środowisk i nikogo nie zapraszał: to, co trafi na stary serwer po eksporcie, nie dotrze do nowego.

Czy mogę uruchomić kilka instancji serwera dla wysokiej dostępności?

Na Postgresie kilka instancji może współdzielić jedną bazę danych: zapisy do dziennika audytu są szeregowane blokadą w bazie. Nie ma przewodnika po klastrze z przełączaniem awaryjnym, więc zaplanuj go jako własną konfigurację.

Czy narzędzia operatora mają interfejs po angielsku?

Tak. server-init, doctor i crunu-server wyświetlają komunikaty po angielsku albo po rosyjsku, gdy CRUNU_LANG lub ustawienia regionalne systemu wskazują rosyjski.

Jak otrzymać serwer do własnego hostingu?

Serwer nie jest publikowany do publicznego pobrania. Napisz na support@crunu.com i podaj, której platformy zamierzasz użyć.

Najpierw wypróbuj Crunu w naszej usłudze

Bezpłatnie we wczesnym dostępie. Twoje hasło i Secret Key powstają w przeglądarce i nigdy nie trafiają na serwer.