Alles wordt ingesteld via omgevingsvariabelen, allemaal met het voorvoegsel APPSWEET_.
Drie ervan zijn verplicht voordat het proces überhaupt start: APPSWEET_DATABASE_URL,
APPSWEET_OIDC_ISSUER en APPSWEET_OIDC_CLIENT_ID. De procesomgeving wint van een
.env-bestand naast de binary.
Server
| Variabele | Vereiste | Beschrijving |
|---|---|---|
APPSWEET_DATABASE_URL |
vereist om te starten | Postgres-connectiestring. Appsweet voert zijn migraties automatisch uit bij het opstarten, en de eerste daarvan heeft de vector-extensie nodig — zie Docker Compose. |
APPSWEET_DATABASE_MAX_CONNECTIONS |
standaard 5 | Grootte van de Postgres-connectiepool. |
APPSWEET_BIND_ADDR |
standaard 127.0.0.1:3000 |
Socketadres waarop de gateway luistert. Binnen een container moet dit 0.0.0.0:3000 zijn, anders bereikt niets van buiten hem. |
APPSWEET_PUBLIC_BASE_URL |
standaard http://localhost:3000 |
De URL waarop browsers Appsweet bereiken. De redirect-URI's voor inloggen worden hiervan afgeleid. |
APPSWEET_TRUST_X_FORWARDED |
standaard false |
Zet alleen op true achter een proxy die je zelf beheert en die de forwarding-headers zelf zet. |
APPSWEET_CORS_ALLOWED_ORIGINS |
optioneel | Komma-gescheiden browser-origins die de REST-API rechtstreeks mogen aanroepen. De standaardwaarden dekken de desktopclient. |
APPSWEET_BACKEND_PROCESS_MODE |
standaard serve+worker |
Of dit proces de HTTP-gateway draait, de achtergrondworker, of allebei. De standaard is wat één container een complete deployment maakt; serve en worker bestaan om ze over replica's te splitsen. |
Inloggen
Appsweet beheert zelf geen wachtwoorden — authenticatie gaat via OIDC, en de meegeleverde stack draait daarvoor Zitadel.
Beide variabelen hieronder worden gelezen terwijl het proces opstart, niet pas bij de eerste
inlogpoging. Een container die alleen een database-URL meekrijgt, stopt voordat hij een
poort opent, en /ready antwoordt dus helemaal nooit. Dit is een opstartvereiste, geen
functie die je kunt uitstellen.
| Variabele | Vereiste | Beschrijving |
|---|---|---|
APPSWEET_OIDC_ISSUER |
vereist om te starten | Absolute http(s)-URL van de Zitadel-instantie. Discovery wordt hiervan afgeleid. |
APPSWEET_OIDC_CLIENT_ID |
vereist om te starten | Client-ID die Appsweet aan de issuer presenteert. |
De issuer moet Zitadel zijn. Deze twee variabelen accepteren elke OIDC-issuer-URL, en de
backend rondt daar ook een aanmelding mee af, maar de werkplek die hij vervolgens opzoekt
komt uit claims van Zitadel zelf: het autorisatieverzoek vraagt om de scope
urn:zitadel:iam:user:resourceowner, en bij het aanmaken van de gebruiker leest de backend
urn:zitadel:iam:user:resourceowner:id, …:name en …:primary_domain uit het token.
Ontbreken die, dan geeft /v1/me 403 workspace_claims_required terug en krijgt de client
nooit een werkplek. Claims van een andere provider hierop afbeelden is niet gebouwd, dus
Keycloak, Authentik, Auth0 en Entra ID werken vandaag niet.
Bestandsopslag
Uploads staan in S3-compatibele objectopslag, niet op een lokale schijf — er is geen datadirectory om te mounten. Opslag is vereist voor elke echte deployment: de opslaglaag spreekt altijd het S3-protocol, met een ingestelde endpoint, credentials en bucketnamen.
De meegeleverde standaard is Garage, die de stack uit de repository voor je opstart, maar niets hangt daarvan af. Elk S3-compatibel endpoint werkt — Hetzner Object Storage, Cloudflare R2, Backblaze B2, AWS S3, Wasabi, of je eigen Garage of SeaweedFS.
APPSWEET_S3_ENDPOINT leeg laten belet de backend niet om te starten: hij komt op met
bestanden uitgeschakeld en al het andere werkend, en zegt daar in de logs niets over. Dat is
een ontwikkelgemak om Appsweet uit te proberen, geen ondersteunde modus zonder opslag. Alles
wat anderen gaan gebruiken heeft opslag nodig.
| Variabele | Vereiste | Beschrijving |
|---|---|---|
APPSWEET_S3_ENDPOINT |
vereist | Endpoint dat de backend voor zijn eigen S3-operaties gebruikt. Niet ingesteld schakelt bestanden uit — alleen voor ontwikkeling. |
APPSWEET_S3_PUBLIC_ENDPOINT |
optioneel | Endpoint waartegen presigned URL's worden aangemaakt, voor als clients het interne endpoint niet kunnen bereiken. |
APPSWEET_S3_ACCESS_KEY |
vereist | S3-accesskey. |
APPSWEET_S3_SECRET_KEY |
vereist | S3-secretkey. |
APPSWEET_S3_REGION |
standaard garage |
S3-regio. |
APPSWEET_S3_UPLOADS_BUCKET |
standaard uploads |
Bucket voor bestanden die gebruikers uploaden. |
APPSWEET_S3_BACKUPS_BUCKET |
standaard backups |
Bucket voor back-ups, apart gehouden zodat die zijn eigen bewaartermijn kan hebben. |
APPSWEET_S3_DERIVED_BUCKET |
standaard derived |
Bucket voor herbouwbare artefacten zoals thumbnails. |
APPSWEET_S3_PRESIGN_TTL_SECS |
standaard 900 | Levensduur van een presigned upload- of download-URL, in seconden. |
Maak de buckets zelf aan
Een bucket hier een naam geven maakt hem niet aan. De opslaglaag van Appsweet voert alleen
objectbewerkingen uit — put, get, head, delete, presign — en roept nooit CreateBucket aan.
Alle drie de buckets moeten dus bestaan vóór de eerste bestandsbewerking, en de sleutel in
APPSWEET_S3_ACCESS_KEY heeft op elk daarvan lees- en schrijfrechten nodig.
Bij het opstarten merk je er niets van. Met APPSWEET_S3_ENDPOINT ingesteld komt de backend
op met bestanden ingeschakeld en meldt hij zich gereed; een ontbrekende bucket komt pas naar
boven als iemand iets uploadt of downloadt, als een fout van de opslagprovider.
Precies dat werk neemt de meegeleverde stack je uit handen: die draait eenmalig een
garage-init-service die op Garage wacht en daarna $APPSWEET_S3_UPLOADS_BUCKET,
$APPSWEET_S3_BACKUPS_BUCKET en $APPSWEET_S3_DERIVED_BUCKET aanmaakt en
$APPSWEET_S3_ACCESS_KEY op elk daarvan lees-, schrijf- en eigenaarsrechten geeft. Op je
eigen S3-provider doe je hetzelfde met de hand of in je provisioning, voordat je Appsweet
erheen wijst.
Sweetheart
Hier valt niets in te stellen. Sweetheart is ontworpen om op het apparaat zelf te draaien, binnen de desktop-app, en de backend leest helemaal geen AI-gerelateerde omgevingsvariabelen. Sweetheart en modellen legt uit wat dat betekent en wat er later verandert.