# Instalace na vlastní server (https://docs.vitrinka.ai/cs/operator/install)



## Podporovaný tvar [#topology]

Compose na jednom stroji, váš reverzní proxy na TLS, disk nebo vaše S3 na blob soubory, váš identity provider na SSO. Za hranicí jednoho stroje je odpovědí spravovaná instance, ne škálovat tohle vlastními silami — ta hranice je záměrná, ne opomenutí.

## Instalace [#install]

Dvě povinné hodnoty a spustit. Binárník si při startu migruje schéma sám.

```bash
cp .env.example .env
# uprav .env: BASE_URL a VITRINKA_MASTER_KEY
openssl rand -hex 32      # vygeneruje master key

docker compose up -d
```

## Postavte před to proxy [#proxy]

Váš reverzní proxy terminuje TLS a přeposílá na publikovaný port (výchozí 8080). `BASE_URL` musí být veřejná adresa, na kterou uživatelé opravdu chodí. Aplikace TLS neterminuje nikdy sama.

Ať proxy přepíše `X-Real-Ip` adresou klienta, a ohlaste ho: `VITRINKA_TRUSTED_PROXIES=<proxy address>/32` (CIDR rozsahy oddělené čárkou, co nejužší rozsah, který pokryje proxy a nic jiného). Rate limiter a každý řádek auditu berou adresu klienta z této hlavičky, jen když požadavek přijde z loopbacku nebo z ohlášeného rozsahu; od jakéhokoli jiného protějšku se hlavička ignoruje a použije se adresa samotného spojení, takže volající nemůže do logu zapsat libovolnou adresu. Bez ohlášení sdílí každý požadavek přes proxy rozpočet rate limitu samotné proxy a audit log zapisuje místo adresy klienta adresu proxy. Proxy na hostiteli Dockeru, která míří na publikovaný port, přichází přes bridge gateway Dockeru, ne z loopbacku, takže ohlaste tuto gateway. Každá adresa uvnitř ohlášeného rozsahu může mluvit za libovolného klienta, proto nikdy neuvádějte nadřazenou síť.

<Callout type="warn">
  `BASE_URL` musí být v produkci **https**, jinak session cookies ztratí příznak `Secure`. Server na to při startu hlasitě upozorní.
</Callout>

## První administrátor [#admin]

Být první nic zvláštního neznamená: nový účet, který nemá žádný workspace, do kterého by vstoupil, dostane při prvním přihlášení vlastní organizaci a první workspace. Instalaci řídí platformní konzole na `/admin` — tarify, pozastavení, schvalování čekací listiny, kontrola AI plateb ([administrátorská konzole](/cs/operator/operations#admin-console)) — a otevře se jen platform adminům. Jednou se přihlaste a pak si účet povyšte přes serverovou binárku:

```bash
docker compose exec vitrinka /vitrinka platform-admin grant you@example.com
```

Povýšení platí od vašeho dalšího načtení stránky, bez restartu, a v auditu se zapíše jako `platform.admin.grant`. Vypíše, jak se účet přihlašuje a kdy vznikl: adresa patří tomu, kdo ji zaregistroval první, tak si ověřte, že je to účet, který myslíte. `platform-admin revoke <email>` a `platform-admin list` příkaz doplňují. Pokud zapínáte vynucené SSO, založte si účet přes svůj identity provider.

Pak v `.env` rozhodněte tři věci a restartujte:

* **Kdo se smí registrovat.** Dokud nezasáhnete, účet si založí kdokoli, kdo se dostane na `BASE_URL`. `VITRINKA_WAITLIST=1` podrží každou novou adresu, na každé cestě přihlášení včetně SSO, dokud ji neschválíte v `/admin`; adresa s čekající pozvánkou projde a existující účty se přihlásí vždy. Nastavte to až po vlastním povýšení: přihlášení na čekací listině, i to vaše, čeká na schválení, které může dát jen platform admin.
* **Limity tarifů.** Když `VITRINKA_METERED` není nastavené, běží každá organizace na limitech Enterprise — 500 GiB sdíleného úložiště, neomezená místa, 250 000 aktivních nástěnek na workspace — a při otevřené registraci dostane stejný příděl i vlastní organizace každého nového účtu. `VITRINKA_METERED=1` místo toho vymáhá uložený tarif každé organizace, nastavený v `/admin`; nová organizace začíná na Free.
* **Kdo drží nastavení pro celé nasazení.** Mailer instalace, nároky na e-mailové domény pro SSO, zapnutí vynuceného SSO při zapnutých nárocích, SSO připojení spravovaná nasazením (jediný druh, který dosáhne na poskytovatele identity ve vaší interní síti) a povolení, aby do této sítě dosáhl tracker, AI backend nebo AI endpoint ([Odchozí cíle](/cs/operator/connectors#outbound)), patří platform adminům. `VITRINKA_OPS_ORG=<slug>` je svěří i adminům té organizace a nedává žádný přístup k datům. Uveďte organizaci, která už existuje — třeba svou, jejíž slug bývá část e-mailu před zavináčem (`jane@example.com` → `jane`); registrace ten slug nikdy nedostane. Bez nastavení se běžný admin organizace nikdy nekvalifikuje, protože organizaci může vlastnit každý účet, který se zaregistruje.

<Callout type="warn">
  Upgradujete instalaci, kde tato nastavení spravovali admini organizací? Přijdou o mailer, přidávání nároků na domény a zapínání vynuceného SSO při zapnutých nárocích. Aby je měli dál, udělte platform admina nebo nastavte `VITRINKA_OPS_ORG`. Prostředí `SMTP_*` / `RESEND_API_KEY` dál funguje jako záloha a nároky i vynucená připojení uložená před upgradem zůstávají, jak byla. Tracker, AI backend nebo AI endpoint ve vaší interní síti na ni přestane dosahovat, dokud ho pravomoc nad instalací jednou neuloží — [po upgradu](/cs/operator/connectors#outbound).
</Callout>

## Žádný migrační krok [#migrations]

Schéma se migruje samo při startu. První spuštění vytvoří všechno, upgrade dohraje, co chybí. Každé vydání migruje z libovolného předchozího — nejsou žádné tvrdé zarážky.

## Dimenzování [#sizing]

Hostitel kontejnerů, který zvládne jeden image a jeden volume, volume pro `/data` a něco, co terminuje TLS. Volitelně S3 kompatibilní bucket, pokud nechcete blob soubory na disku.

<Callout type="warn">
  Konkrétní CPU, RAM a disk tu schválně nejsou: podporovaná topologie publikovaná je, dimenzování ne, a vymyslet si číslo by bylo horší než ho neuvést. Ozvěte se a nadimenzujeme to podle objemu vašich session.
</Callout>
