Blog · Infrastruktura

Infrastruktura produkcyjna: Docker, Nginx, SSL i rebuildy

Kod aplikacji to połowa sukcesu. Druga połowa to powtarzalne wdrożenie: izolacja procesów, HTTPS, logi i ścieżka od pusha na GitHub do działającego URL-a. Tak działa nasza platforma hostingowa.

Po co własna platforma?

Klasyczny VPS z ręcznym SSH sprawdza się przy jednym projekcie. Przy wielu aplikacjach klientów pojawia się chaos: różne wersje Node, zapomniane certyfikaty, „działa u mnie na serwerze”. Dlatego zbudowaliśmy panel, który standaryzuje import repozytorium, build, zmienne środowiskowe i publikację.

Ścieżka wdrożenia

  1. Import projektu z GitHub (branch produkcyjny: main).
  2. Konfiguracja zmiennych środowiskowych i tajnych kluczy w panelu.
  3. Build obrazu Docker i start kontenera na wydzielonym porcie.
  4. Nginx jako reverse proxy: HTTP→HTTPS, nagłówki, routing domeny.
  5. Certyfikat Let’s Encrypt dla subdomeny lub domeny własnej.
  6. Kolejne push’e na main uruchamiają rebuild bez ręcznego wgrywania plików.

Subdomena nazwa.devstudioit.app jest wygodna na start, dema i projekty wewnętrzne. Produkcję często podpinamy pod domenę klienta z przekierowaniem www i osobnym certyfikatem.

Izolacja i bezpieczeństwo praktyczne

Każdy projekt działa w osobnym kontenerze. Awaria jednej aplikacji nie powinna wyłączać pozostałych. Sekrety nie trafiają do repozytorium. Dostęp do panelu jest kontami użytkowników, a nie współdzielonym hasłem root na produkcji.

HTTPS jest domyślne. Mixed content i wygasłe certyfikaty to klasyka problemów, które sieć reklamowa i przeglądarki karzą natychmiast. Dlatego odnawianie certyfikatów jest częścią platformy.

Co widać w katalogu Projektów?

Publiczna strona Projekty listuje aktywne wdrożenia na subdomenach platformy. To świadomy wybór: pokazujemy living portfolio, nie makiety. Jeśli projekt jest live, ma szansę pojawić się w katalogu automatycznie.

Ograniczenia, o których mówimy wprost

  • Aplikacja musi dać się zbudować i uruchomić w kontenerze (jasny start command).
  • Migracje bazy nie mogą blokować startu procesu HTTP (inaczej pojawia się 502).
  • Ciężkie joby lepiej trzymać jako procesy tła z limitem zasobów.
  • Custom domena wymaga poprawnego DNS (rekordy A/CNAME wskazujące na nasz serwer).

Dla kogo to ma sens?

Dla founderów i zespołów, które chcą skupić się na produkcie, a nie na cotygodniowym gaszeniu pożarów na VPS. Dla software house’ów i freelancersów, którzy potrzebują powtarzalnego hostingu pod klientami. Dla nas samych: utrzymujemy tu własne SaaSy.

Panel: devstudioit.cloud. Jak budujemy produkt: przewodnik SaaS. Zapytania o hosting i rozwój: kontakt.

Wróć do bloga