Skip to content

demo-instance.md

Latest commit

 

History

History
63 lines (44 loc) · 3.6 KB

demo-instance.md

File metadata and controls

63 lines (44 loc) · 3.6 KB

Instancja demo i Staging

Porównanie środowisk

Aspekt Staging Production
URL Web reads-staging.baluarte.pl reads.baluarte.pl
URL API api-reads-staging.baluarte.pl api-reads.baluarte.pl
Branch źródłowy develop tag SemVer na master
Deploy trigger push do develop (auto) git tag v*.*.* (manual)
Database reads_staging reads (production)
Dostęp sieciowy Cloudflare Access (autor + QA) Cloudflare Access (autor + zaproszeni)
Dane Test data, ephemeral Prawdziwe bookmarki autora
SLA Best-effort Stabilne
Rollback git revert + redeploy git checkout <tag> + redeploy

reads-staging.baluarte.pl — instancja testowa

  • Hosting: VPS autora, ta sama instancja co produkcja (osobne serwisy systemd).
  • Deploy: automatycznie na każdy push do develop.
  • Dostęp za Cloudflare Access — równoległy do produkcji.
  • Lista dostępu: autor + QA testers (wąskie uprawnienia do testowania).
  • Dane: ephemeral, resetowane w razie potrzeby. Brak danych produkcyjnych.
  • Przeznaczenie: weryfikacja integracyjna przed mergem do master, preview dla early reviewers.

Dla developerów: staging zawsze ma najnowszy kod z develop — możesz go użyć do ręcznego testowania bez lokalnego setup'u.

Dla reviewerów: link reads-staging.baluarte.pl w PR umożliwia live testing zmian.

reads.baluarte.pl — instancja produkcji autora

  • Hosting: VPS autora (vmi2941007), deployowana automatycznie przez deploy-production.yml na tag.
  • Dostęp za Cloudflare Access (Cloudflare Zero Trust) — nie otwarta rejestracja.
  • Lista dostępu: autor + osoby którym autor przyznał dostęp (rekruterzy, inwestorzy, zaufani kontrybutorzy).
  • Przyznawanie dostępu: ręcznie, per email, via Cloudflare Zero Trust dashboard.
  • Dane: prawdziwe bookmarki autora (dogfooding). Każdy gość ma osobne konto w aplikacji; konto autora nie jest dzielone.

Dlaczego Cloudflare Access, nie otwarta rejestracja

  • Brak ryzyka spamu, nadużyć, moderacji.
  • Brak problemu z GDPR / retencją danych obcych osób.
  • Jasna granica: to jest prywatna instancja demo, nie publiczny serwis.
  • Osoby proszące o dostęp dostają link + instrukcję, widzą prawdziwy use case.
  • Self-hosting pozostaje właściwą drogą dla każdego kto chce używać produkcyjnie.

W README wyraźnie: "Demo na żądanie (email do autora). Dla użytkowania produkcyjnego — self-host (instrukcja poniżej)."

Procedura przyznawania dostępu

Runbook: docs/runbooks/grant-demo-access.md — procedura dodawania osoby do Cloudflare Access.

Warstwy dostępu w produkcji autora

  1. Cloudflare Access — brama sieciowa (tylko zaproszeni emailem mogą w ogóle zobaczyć stronę).
  2. Lucia / API tokens — warstwa aplikacyjna (po wejściu trzeba się zalogować / wygenerować token).

To są niezależne warstwy. Self-hoster może nie używać Cloudflare Access (własny reverse proxy, otwarta strona) i nadal mieć pełny auth aplikacyjny.

Uwaga architektoniczna: kod aplikacji nie może zależeć od Cloudflare Access — to warstwa infry, nie aplikacji. Self-hoster może jej nie mieć.