Installing on your own host

#The supported shape

Compose on one box, your reverse proxy for TLS, filesystem or your own S3 for blobs, your identity provider for SSO. Beyond a single host, the answer is a managed instance rather than scaling this yourself — that boundary is intentional, not an omission.

#Install

Two required values, then bring it up. The binary migrates its own schema on boot.

cp .env.example .env
# edit .env: BASE_URL and VITRINKA_MASTER_KEY
openssl rand -hex 32      # generates a master key

docker compose up -d

#Put a proxy in front

Your reverse proxy terminates TLS and forwards to the published port (default 8080). BASE_URL must be the public URL your users actually reach. The app never terminates TLS itself.

BASE_URL must be https in production, or session cookies lose their Secure flag. The server warns loudly on boot when it isn't.

#The first admin

The first account to sign up becomes the owner. If you are turning on forced SSO, create that account through your identity provider instead.

#There is no migrate step

The schema migrates itself at startup. First boot creates everything; an upgrade applies whatever is pending. Every release migrates from every prior release — there are no upgrade hard stops.

#Sizing

A container host that can run one image and mount one volume, plus a volume for /data and something to terminate TLS. Optionally an S3-compatible bucket if you would rather not keep blobs on disk.

CPU, RAM and disk figures are deliberately not stated: the supported topology is published, the sizing is not, and inventing a number would be worse than leaving it out. Ask, and it can be sized against your session volume and retention.