xenarathon/wardrowbe
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Page: Setup
Pages
Calendar and Sharing Home Setup Style Profile and Buy Advisor
1 Setup
Xena Rathon edited this page 2026-07-05 10:41:01 -04:00
Table of Contents

Setup

This page covers only the fork-specific setup: pointing the app at your AI + SSO, the CI/CD pipeline, and running database migrations. For the general Docker Compose / prerequisites, see the upstream README's Quick Start.

AI env vars

The vision tagger and the style-profile drafter both talk to any OpenAI-compatible endpoint (Ollama recommended for a fully local/free setup).

Var Purpose
WARDROWBE_AI_BASE_URL Base URL of your OpenAI-compatible endpoint, e.g. http://your-ollama-host:11434/v1
WARDROWBE_AI_API_KEY API key/token (Ollama accepts any placeholder value)
WARDROWBE_AI_VISION_MODEL Model used for clothing-item image tagging and cut-attribute extraction (needs vision support)
WARDROWBE_AI_TEXT_MODEL Model used for text-only drafting (e.g. the colour-season / Kibbe-lean draft in the Style Profile wizard)

Both models point at the same endpoint by default — use different models if your vision and text workloads are sized differently (e.g. a smaller vision model, a bigger text model).

SSO env vars (Authentik / any OIDC provider)

Var Purpose
WARDROWBE_OIDC_ISSUER Your OIDC provider's issuer URL, e.g. https://auth.your-domain/application/o/wardrowbe/
WARDROWBE_OIDC_CLIENT_ID OAuth2 client ID registered on your provider
WARDROWBE_OIDC_CLIENT_SECRET OAuth2 client secret
WARDROWBE_OIDC_REDIRECT_URI Callback URL the provider redirects to after login
OIDC_DISCOVERY_BASE_URL Overrides the host used to fetch JWKS/discovery documents — set this to your provider's LAN address if the backend container can't resolve your public hostname (avoids routing JWKS fetches back out through your tunnel/reverse proxy)

Set these on the backend service in your compose file / DockHand stack env, not just in a local .env — DockHand stacks keep their own env store.

Build → registry → deploy pipeline

This fork is built by Forgejo Actions, not built by hand:

  1. Push to main → .forgejo/workflows/build.yml runs.
  2. It builds the backend and frontend images and pushes them to your Forgejo container registry (e.g. your-forgejo-host:3300/you/wardrobe-backend:latest).
  3. Your stack manager (e.g. DockHand) redeploys, pulling the new tags.

Requirements:

  • A repo Actions secret REGISTRY_TOKEN — a Forgejo token with write:package scope.
  • The registry host allowed in your Docker daemon's insecure-registries if it's plain HTTP on the LAN (or front it with TLS).
  • The CI runner needs access to the host's Docker socket to run docker build.

Database migrations — no auto-migrate

The backend does not run migrations automatically on startup. If a deploy includes a schema change, you must run the migration yourself as a one-off step after the new image is up:

docker run --rm --network <your-backend-network> \
  --env-file <your-backend-env-file> \
  your-forgejo-host:3300/you/wardrobe-backend:latest \
  alembic upgrade head

Adjust the network/env-file to match however your backend container is wired (same DB connection settings it normally uses). Run this once per deploy that touches models — skipping it leaves the app running against a stale schema and will surface as 500s on the endpoints touching the new columns/tables.