Umgebungsvariablen

Owlat nutzt Umgebungsvariablen, um Provider, Sicherheitsprüfungen, Authentifizierung und die Voraussetzungen von Feature-Flags zu konfigurieren. Variablen des Convex-Backends (alles, was über apps/api/convex/lib/env.ts gelesen wird) setzen Sie im Convex-Dashboard; Web-App, MTA, IMAP-Server und Mail-Sync-Worker lesen ihre eigene Prozessumgebung (im Self-Hosting stammt alles davon aus einer einzigen .env-Datei, die docker-compose.yml einliest).

Konfiguration beim Self-Hosting

Self-Hoster legen alles in einer einzigen .env-Datei im Wurzelverzeichnis des Repositorys ab. Beginnen Sie mit der Vorlage:

cp .env.selfhost.example .env

Die Vorlage und docker-compose.yml verweisen auf diese Variablen:

Erforderliche Geheimnisse

Öffentliche URLs

MTA (E-Mail-Versand)

Deployment-Modus (Web-App & Compose)

Dies sind keine Convex-Backend-Variablen — sie werden nicht über lib/env.ts gelesen. OWLAT_DEPLOYMENT_MODE wird von der Web-App verwendet (apps/web/nuxt.config.ts, veröffentlicht als runtimeConfig.public.deploymentMode) und von docker-compose.yml an den Web-Container übergeben. OWLAT_HOSTED_MODE ist ein .env-Flag, das das Setup-CLI anhand des gewählten Deployment-Modus schreibt; in diesem OSS-Repository ist es wirkungslos (kein Dienst liest es), Self-Hoster lassen es also auf false.

Port-Overrides (optional)

Alle Ports haben sinnvolle Standardwerte. Überschreiben Sie sie nur, wenn die Standardwerte kollidieren:

# CONVEX_PORT=3210
# CONVEX_SITE_PORT=3211
# DASHBOARD_PORT=6791
# WEB_PORT=3000
# MTA_HTTP_PORT=3100
# MTA_SMTP_PORT=25
# IMAP_PORT=993

Optional: PostHog-Analytics

# NUXT_PUBLIC_POSTHOG_API_KEY=
# NUXT_PUBLIC_POSTHOG_HOST=https://eu.i.posthog.com

Optional: LLM-Provider (Flag ai)

Nur nötig, wenn ein KI-Flag aktiv ist. Alle Details finden Sie unter Providers → LLM provider.

# LLM_PROVIDER=openai          # openai | openrouter | ollama  (Claude works via openai + an OpenAI-compatible LLM_BASE_URL)
# LLM_API_KEY=sk-...
# LLM_MODEL_FAST=gpt-4o-mini   # used for classify/extract/guard/summarize
# LLM_MODEL_CAPABLE=gpt-4o     # used for draft tasks
# LLM_MODEL=                   # single-model fallback for both tiers when *_FAST/*_CAPABLE are unset
# LLM_EMBEDDING_MODEL=text-embedding-3-small
# LLM_BASE_URL=                # override for ollama / vLLM / LM Studio
# --- Local-by-default embedding plane (optional) ---
# LOCAL_EMBEDDING_BASE_URL=http://ollama:11434/v1   # an OpenAI-compatible /embeddings sidecar
# LOCAL_EMBEDDING_MODEL=nomic-embed-text            # NOTE: its width must match the vector index

KI-Ausgabenbudget (Dollar-Obergrenze je Organisation)

Ein Gate vor dem Aufruf (convex/analytics/spendBudget.ts), das die LLM-Ausgaben in Dollar je Organisation deckelt — zusätzlich zu den Rate Limits nach Aufrufanzahl. Die Ausgaben werden aus analytics/llmUsage + lib/llm/pricing aggregiert. Ist eine Obergrenze erreicht, schaltet das Gate fail-closed: Der autonome Agent fällt auf reine Entwürfe zurück (E-Mail geht nie verloren — sie wird zur menschlichen Prüfung geleitet), und beratende, von Nutzenden ausgelöste KI wird pausiert, sobald der verbleibende Spielraum in die Reserve rutscht. Alle vier Variablen sind standardmäßig nicht gesetzt bzw. 0, wodurch das Gate wirkungslos ist.

Optional: Private E-Mail / IMAP (Flag postbox)

Der IMAP-Server (apps/imap) liest diese Werte beim Start. Nur relevant, wenn das Flag postbox aktiv ist.

# IMAP_PORT=993
# IMAP_LISTEN=0.0.0.0
# IMAP_GREETING_HOST=mail.example.com
# IMAP_TLS_CERT_FILE=/opt/owlat/certs/default.crt
# IMAP_TLS_KEY_FILE=/opt/owlat/certs/default.key
# TLS_CERT_DIR=/opt/owlat/certs        # fallback if IMAP_TLS_* not set
# REDIS_URL=                           # see note below

Der IMAP-Server authentifiziert sich gegenüber Convex mit CONVEX_ADMIN_KEY (er setzt die Admin-Authentifizierung an einem ConvexHttpClient und ruft die Funktion mail/appPasswords:verify direkt auf — apps/imap/src/convex.ts). Er liest MTA_WEBHOOK_SECRET nicht. Sein Log-Level stammt aus LOG_LEVEL (die VPS-Compose-Datei bildet IMAP_LOG_LEVEL darauf ab).

Optional: Mail-Sync — externe Postfächer (Flag mail.external)

Ist das Flag mail.external aktiv, können Nutzerinnen und Nutzer eigene IMAP-/SMTP-Konten verbinden. Convex übergibt diese an einen separaten Mail-Sync-Worker (infra/templates/docker-compose.vps.yml, Compose-Profil external-mail). Convex erreicht den Worker auf demselben Weg wie die MTA — über Deployment-Umgebungsvariablen, die im Convex-Dashboard gesetzt werden:

Optional: Eingehende Kanal-Webhooks (SMS / WhatsApp / generisch)

Diese Geheimnisse authentifizieren eingehende Webhook-Callbacks von Drittanbieter-Kanalprovidern. Sie werden von den Webhook-Adaptern in apps/api/convex/webhooks/adapters/ gelesen. (Nur eingehend — der ausgehende SMS-/WhatsApp-Versand ist nicht durchgängig verdrahtet; siehe Communication Channels.)

Optional: Weitere Convex-Backend-Variablen

Einige weitere Variablen werden über lib/env.ts gelesen und im Convex-Dashboard gesetzt. Keine davon ist für ein einfaches Self-Hosting erforderlich:

Wo Variablen gesetzt werden

Convex-Backend (alle process.env-Referenzen in apps/api/):

npx convex env set VAR_NAME value

Oder setzen Sie sie im Convex-Dashboard unter „Settings > Environment Variables“ Ihres Deployments.

Nuxt-Frontend (apps/web/.env):

NUXT_PUBLIC_CONVEX_URL=https://your-deployment.convex.cloud
NUXT_PUBLIC_CONVEX_SITE_URL=https://your-deployment.convex.site
NUXT_PUBLIC_SITE_URL=http://localhost:3000

E-Mail-Versand

Providerauswahl

Welche Sendetransporte existieren, was jeder von ihnen benötigt und was er kann, wird genau einmal deklariert, in packages/shared/src/sendProviderCatalog.ts (ADR-0055). Dieser Abschnitt gibt diese Deklaration wieder und nichts sonst: apps/docs/__tests__/providerCatalogDocs.test.ts liest beides und schlägt fehl, wenn ein Kind, eine erforderliche Variable — oder ein ganzer Provider — hier fehlt. Setzen Sie EMAIL_PROVIDER auf einen Wert aus der ersten Spalte, um jede Sendung über dieses Kind zu leiten; eine Provider-Route je Organisation überschreibt das pro Nachrichtentyp. Es gibt keinen impliziten Standard: Die Variable ungesetzt zu lassen bedeutet nicht „die MTA verwenden“ — die Auflösung ist fail-closed, sodass eine Instanz ohne Routenkonfiguration und ohne Wert hier ihre Sendungen verweigert, statt an eine Phantom-MTA zu übergeben.

npx convex env set EMAIL_PROVIDER mandrill   # or any other value from the table above

Erforderlich ist das Vorhandensein-Gate, das der Rest des Systems liest: Solange nicht jede Variable in dieser Zelle gesetzt ist, gilt das Kind als nicht konfiguriert — es kann nicht angesteuert werden und kommt auch nicht als Fallback-Relay für die Zustellbarkeit infrage. Optionale Variablen verfeinern einen bereits funktionierenden Transport (ein Signierschlüssel für Feedback, eine TLS-Untergrenze, ein dedizierter IP-Pool), sodass ein Convex-Deployment, das nie eine davon setzt, dennoch versendet.

Beide Spalten beschreiben die Convex-Seite, die einzige Seite, von der der Katalog weiß. Ein selbst betriebener Dienst kann darüber hinaus einen eigenen Vertrag haben: MTA_WEBHOOK_SECRET ist für das obige Gate optional und für apps/mta verpflichtend, dessen loadConfig() ohne den Wert den Start verweigert — setzen Sie ihn in einem selbst gehosteten Stack also dort, wo es die eigene Referenz der MTA weiter unten verlangt.

Die optionale Spalte darf mehr nennen als der Katalog, nie weniger, und bei SES stehen beide Fälle nebeneinander. SES_CONFIGURATION_SET wird vom Transport bei jeder Sendung gelesen: Der Adapter prägt es dem SendEmail-/SendRawEmail-Befehl auf, damit die Ereignisveröffentlichung von SES das entstehende Feedback zuordnen kann — deshalb deklariert der Katalog es als optional (eine Sendung ohne den Wert funktioniert; verloren geht nur die Zuordnung, und ein späteres Setzen wirkt nur auf spätere Sendungen, nie rückwirkend). SES_SNS_TOPIC_ARN wird ausschließlich vom Feedback-Verifizierer gelesen (webhooks/adapters/ses.ts) — der Sendepfad sieht es nie an, und ein Signierschlüssel ist es auch nicht, da SNS mit einem Zertifikat signiert —, weshalb kein Katalogfeld es beschreibt und diese Referenz der einzige Ort ist, an dem es festgehalten wird. Keine der beiden Variablen entscheidet darüber, ob SES senden kann, weshalb keine im Vorhandensein-Gate steht. Ein mitgelieferter Plugin-Transport deklariert seine eigenen Variablen stattdessen in seinem Contribution — sie tragen das Präfix PLUGIN_, erreichen lib/env.ts nie und werden daher in der README des Plugins dokumentiert, nicht hier.

AWS SES

Einrichtungsschritte

1. Legen Sie in AWS einen IAM-Benutzer mit programmatischem Zugriff und der Policy AmazonSESFullAccess an (oder mit einer eingeschränkten Policy, die ses:SendEmail und ses:SendRawEmail erlaubt).
2. Verifizieren Sie Ihre Sendedomain in der SES-Konsole. SES verlangt die Domain-Verifizierung, bevor Sie E-Mails senden können.
3. Beantragen Sie den Produktionszugang, falls sich Ihr SES-Konto im Sandbox-Modus befindet. Der Sandbox-Modus erlaubt den Versand ausschließlich an verifizierte Adressen.
4. Setzen Sie die Umgebungsvariablen:

   npx convex env set EMAIL_PROVIDER ses
   npx convex env set AWS_SES_REGION eu-west-1
   npx convex env set AWS_SES_ACCESS_KEY_ID AKIA...
   npx convex env set AWS_SES_SECRET_ACCESS_KEY ...
   

5. (Empfohlen) Aktivieren Sie den Feedback Loop für Bounces und Beschwerden. Ohne ihn nimmt SES Ihre E-Mails an, teilt Owlat aber nie mit, wenn eine Nachricht hart bounct oder als Spam markiert wird; diese Adressen werden dann nicht unterdrückt und Ihre Absenderreputation verfällt still und leise. Owlat empfängt SES-Feedback über ein Amazon-SNS-Topic:
   • Legen Sie ein SNS-Topic an (z. B. owlat-ses-feedback) und fügen Sie ein HTTPS- Abonnement hinzu, das auf https://<your-convex-site-url>/webhooks/ses zeigt. Owlat bestätigt das Abonnement automatisch (es prüft die Signatur der SNS-Nachricht und ruft anschließend die SubscribeURL auf).
   • Setzen Sie SES_SNS_TOPIC_ARN auf den ARN dieses Topics, damit Owlat Feedback nur aus Ihrem Topic akzeptiert (bis der Wert gesetzt ist, bleibt der Endpunkt geschlossen):

     npx convex env set SES_SNS_TOPIC_ARN arn:aws:sns:eu-west-1:123456789012:owlat-ses-feedback
     

   • Legen Sie in der SES-Konsole ein Configuration Set an, fügen Sie ein Event Destination hinzu, das die Ereignisse Bounce, Complaint und Delivery an dieses SNS-Topic veröffentlicht, und setzen Sie SES_CONFIGURATION_SET auf dessen Namen, damit jede Sendung zugeordnet wird:

     npx convex env set SES_CONFIGURATION_SET owlat-ses
     

   • Die Zustellungsseite (Einstellungen → Zustellung) zeigt eine Live-Zeile „zuletzt empfangenes Ereignis“, an der Sie erkennen, dass Feedback eintrifft.
   
   Jede SNS-Anfrage wird fail-closed signaturgeprüft: Ihre SigningCertURL ist auf einen Host sns.*.amazonaws.com festgelegt, ihr Timestamp muss aktuell sein und ihr TopicArn muss SES_SNS_TOPIC_ARN entsprechen, sodass gefälschtes oder erneut eingespieltes Feedback abgewiesen wird.

Resend

Einrichtungsschritte

1. Legen Sie ein Resend-Konto auf resend.com an und fügen Sie Ihre Sendedomain hinzu.
2. Erzeugen Sie einen API-Schlüssel im Resend-Dashboard.
3. (Optional) Richten Sie Webhooks für die Zustellverfolgung ein:
   • Legen Sie in Resend einen Webhook an, der auf den Webhook-Endpunkt Ihrer Convex-Site-URL zeigt
   • Kopieren Sie das Signiergeheimnis des Webhooks
4. Setzen Sie die Umgebungsvariablen:

   npx convex env set EMAIL_PROVIDER resend
   npx convex env set RESEND_API_KEY re_...
   npx convex env set RESEND_WEBHOOK_SECRET whsec_...
   

Emailit

Setzen Sie EMAIL_PROVIDER=emailit und EMAILIT_API_KEY und legen Sie dann einen Emailit-Webhook an, der auf <CONVEX_SITE_URL>/webhooks/emailit zeigt. Aktivieren Sie die E-Mail-Ereignisse accepted, attempted, delivered, bounced, complained, failed, rejected und suppressed. Owlat prüft X-Emailit-Signature als HMAC-SHA256 über <X-Emailit-Timestamp>.<raw body> mit einer Frischegrenze von fünf Minuten. Das Öffnungs- und Klick-Tracking des Providers bleibt bei Sendungen deaktiviert, weil Owlats First-Party-Tracking maßgeblich bleibt.

npx convex env set EMAIL_PROVIDER emailit
npx convex env set EMAILIT_API_KEY em_...
npx convex env set EMAILIT_WEBHOOK_SECRET whsec_...

Generisches SMTP-Relay

Wenn Sie bereits einen SMTP-Submission-Host haben — Mailgun, Postmark, SendGrid, Brevo oder ein selbst betriebenes Relay —, setzen Sie EMAIL_PROVIDER=smtp und richten Owlat darauf aus. Es gibt keinen API-Adapter je Provider: Jedes Relay, das SMTP spricht, funktioniert.

Bei einem Relay gehören die sendenden IPs und die DKIM-Signierung dem Relay-Provider — konfigurieren Sie SPF und DKIM für Ihre From-Domain im Dashboard des Relays, nicht über das DNS-Bündel der eingebauten MTA.

Mailchimp Transactional (Mandrill)

Setzen Sie EMAIL_PROVIDER=mandrill, um über ein bestehendes Mailchimp-Transactional-Konto zu senden. Das ist der Migrationsarm: Ein Team, das von Mailchimp kommt, behält am ersten Tag seine bisherige Zustellbarkeit, und Owlats Ramp-Controller verschiebt den Traffic anschließend Zelle für Zelle auf die eingebaute MTA, so wie es die Messungen zulassen.

Owlat baut die gesamte MIME-Nachricht selbst zusammen und schickt sie an Mandrills messages/send-raw, wobei Mandrills Öffnungs- und Klick-Tracking, Link-Rewriting und automatische Textgenerierung ausdrücklich aus sind. Das Tracking bleibt First Party, sodass beide Sendearme mit identischer Instrumentierung gemessen werden — aktivieren Sie am Webhook send, deferral, hard_bounce, soft_bounce, spam, unsub und reject, aber nicht open/click.

Legen Sie den Webhook unter Mailchimp Transactional → Settings → Webhooks an und richten Sie ihn auf <CONVEX_SITE_URL>/webhooks/mandrill. Mandrill zeigt den Signierschlüssel einmalig an, direkt nach dem Speichern — dieser Wert ist MANDRILL_WEBHOOK_KEY. Bis er gesetzt ist, weist Owlat jeden übermittelten Batch ab, statt einem unsignierten zu vertrauen; der Versand wirkt dann gesund, während Bounces, Beschwerden und Treffer der Reject-Liste stillschweigend nie eintreffen. Unter Zustellung → Provider sehen Sie die exakte URL, die Ereignisliste und ob der Schlüssel vorhanden ist. Nur MANDRILL_API_KEY wird vom Transport-Editor in der App geschrieben; die anderen drei sind ausschließlich .env-seitig, sodass das Rotieren des Sendeschlüssels niemals einen funktionierenden Feedback Loop deaktivieren kann.

Zwei Transporte desselben Kinds

Jedes Transport-Kind oben erhält kostenlos eine Standardinstanz, deren Id das Kind selbst ist (mta, ses, resend, smtp, mandrill, emailit) und die die unsuffigierten Variablen liest. Deklarieren Sie benannte Instanzen, wenn Sie zwei Konfigurationen desselben Kinds nebeneinander betreiben wollen — etwa um ein warmes Fallback-Relay zu behalten, während Sie ein zweites erproben.

Eine benannte Instanz liest die Variablen ihres Kinds mit dem Suffix __<INSTANCEKEY>, sodass smtp#backup die Werte SMTP_RELAY_HOST__BACKUP, SMTP_RELAY_USERNAME__BACKUP und SMTP_RELAY_PASSWORD__BACKUP liest:

npx convex env set SEND_TRANSPORT_INSTANCES smtp#backup
npx convex env set SMTP_RELAY_HOST__BACKUP smtp.postmarkapp.com
npx convex env set SMTP_RELAY_USERNAME__BACKUP ...
npx convex env set SMTP_RELAY_PASSWORD__BACKUP ...

Entfernen Sie eine Instanz aus der Liste oder entfernen Sie deren Variablen, scheitern Sendungen an diese Transport-Id fail-closed — sie fallen nie stillschweigend auf die Zugangsdaten eines anderen Transports zurück. Fehlerhafte Einträge werden ignoriert, statt den Dispatch abstürzen zu lassen; dasselbe gilt für einen zweiten Eintrag, dessen Schlüssel dasselbe Variablensuffix ergibt wie ein früherer (a-b und a_b ergeben beide __A_B). Auch ein von einem Plugin beigesteuerter Transport kann benannte Instanzen haben, zu denselben Bedingungen, sofern sein Contribution eigene Konfigurationsvariablen deklariert — diese tragen das Präfix PLUGIN_ und lesen dasselbe Suffix __<INSTANCEKEY>. Ein Transport, der keine deklariert, liest die deployment-weiten Variablen des Plugins, die kein Suffix erreicht; eine Instanz davon zu deklarieren wird deshalb abgelehnt, statt stillschweigend mit den Zugangsdaten der Standardinstanz zu senden.

Einrichtungsschritte

1. Legen Sie im Dashboard Ihres Relay-Providers SMTP-Zugangsdaten an (einen domain- oder kontobezogenen SMTP-Benutzernamen samt Passwort).
2. Verifizieren Sie Ihre Sendedomain beim Relay (veröffentlichen Sie dessen SPF-/DKIM-Einträge), damit Ihre E-Mails authentifiziert werden.
3. Setzen Sie die Umgebungsvariablen:

   npx convex env set EMAIL_PROVIDER smtp
   npx convex env set SMTP_RELAY_HOST smtp.mailgun.org
   npx convex env set SMTP_RELAY_PORT 587
   npx convex env set SMTP_RELAY_USERNAME postmaster@mg.example.com
   npx convex env set SMTP_RELAY_PASSWORD ...
   

Eigene MTA

Bei Verwendung der eigenen MTA (EMAIL_PROVIDER=mta) verbindet sich das Convex-Backend über HTTP mit dem MTA-Dienst. Alle Architekturdetails finden Sie in der Dokumentation zum MTA System.

Einrichtungsschritte

1. Deployen Sie den MTA-Dienst aus apps/mta/ (Konfigurationsdetails in der MTA-System-Dokumentation).
2. Setzen Sie die Umgebungsvariablen im Convex-Dashboard:

   npx convex env set EMAIL_PROVIDER mta
   npx convex env set MTA_API_URL http://mta.internal:3100
   npx convex env set MTA_API_KEY your-shared-api-key
   npx convex env set MTA_WEBHOOK_SECRET your-webhook-secret
   

Allgemeine E-Mail-Konfiguration

Diese Variablen gelten unabhängig davon, welchen Provider Sie verwenden:

E-Mail-Sicherheit

Optionale Umgebungsvariablen für die Prüfung von E-Mail-Inhalten und Anhängen. Details zur Prüf-Pipeline finden Sie in der Dokumentation zur E-Mail-Sicherheit.

Variablen

Im Convex-Dashboard setzen:

In der MTA-Umgebung setzen:

Einrichtungsschritte

1. (Optional) Prüfung der URL-Reputation aktivieren — holen Sie sich einen Google-Safe-Browsing-API-Schlüssel aus der Google Cloud Console:

   npx convex env set GOOGLE_SAFE_BROWSING_API_KEY AIza...
   

2. (Optional) ClamAV-Malware-Prüfung aktivieren — deployen Sie ClamAV neben der MTA (siehe MTA System > ClamAV Sidecar) und setzen Sie die interne URL:

   npx convex env set MTA_INTERNAL_URL http://mta.internal:3100
   

Analytics (PostHog)

Owlat integriert PostHog für Produktanalytik und Fehlererfassung. Die Integration ist optional — alles funktioniert auch ohne sie.

Variablen

Convex-Dashboard:

Nuxt-Frontend (apps/web/.env):

Einrichtungsschritte

1. Legen Sie ein PostHog-Projekt auf posthog.com an und kopieren Sie den Projekt-API-Schlüssel.
2. Fügen Sie den Gruppentyp organization in PostHog hinzu: Gehen Sie zu Settings → Groups und legen Sie einen Gruppentyp namens organization an. Damit wird Analytik auf Organisationsebene möglich.
3. Setzen Sie die Umgebungsvariablen:

   # Convex (server-side events)
   npx convex env set POSTHOG_API_KEY phc_...
   npx convex env set POSTHOG_HOST https://eu.i.posthog.com
   
   # apps/web/.env (client-side events)
   NUXT_PUBLIC_POSTHOG_API_KEY=phc_...
   NUXT_PUBLIC_POSTHOG_HOST=https://eu.i.posthog.com
   

Erfasste Ereignisse

Clientseitig (automatisch):

• $pageview — SPA-Seitennavigationen
• $pageleave — Ereignisse beim Verlassen einer Seite
• $exception — Vue-Fehler und unbehandelte Promise-Rejections
• Nutzeridentifikation und Zuordnung zur Organisationsgruppe

Serverseitig (Fire-and-forget aus Mutations):

• campaign_created, campaign_sent
• contact_created
• automation_created, automation_activated, automation_paused
• topic_created

Alle Serverereignisse enthalten organizationId als Eigenschaft und als PostHog-Gruppe.

LLM-Provider (KI-Funktionen)

Das Flag ai und jedes davon abhängige Flag benötigen einen LLM-Provider. Derselbe Provider treibt Übersetzungen von E-Mail-Templates, den KI-Agenten, die Embeddings des Wissensgraphen und die Dashboard-Generierung an. Den Interface-Vertrag und die Schritte zum Hinzufügen eines neuen Providers finden Sie unter Providers → LLM provider.

Variablen

Einrichtung

npx convex env set LLM_PROVIDER openai
npx convex env set LLM_API_KEY sk-...
# Override defaults if you want a specific model:
npx convex env set LLM_MODEL_FAST gpt-4o-mini
npx convex env set LLM_MODEL_CAPABLE gpt-4o

Für ein lokales Ollama:

npx convex env set LLM_PROVIDER ollama
npx convex env set LLM_BASE_URL http://host.docker.internal:11434/v1
npx convex env set LLM_MODEL_FAST llama3.1:8b
npx convex env set LLM_MODEL_CAPABLE llama3.1:70b

Benachrichtigungen

Benachrichtigungen werden clientseitig von der Desktop-App abgewickelt; eine serverseitige Umgebungsvariable für einen Benachrichtigungsprovider gibt es nicht. Das gesamte Wissens-Retrieval nutzt den eingebauten Vektorindex von Convex (ctx.vectorSearch), sodass es auch keine Umgebungsvariable für einen Vektorspeicher gibt.

Private E-Mail / IMAP (apps/imap)

Diese Werte liest der IMAP-Server, nicht das Convex-Backend. Nur relevant, wenn das Flag postbox aktiv ist.

Der IMAP-Server authentifiziert sich gegenüber Convex mit CONVEX_ADMIN_KEY (er setzt die Admin-Authentifizierung an einem ConvexHttpClient und ruft mail/appPasswords:verify direkt auf — apps/imap/src/convex.ts). Er liest MTA_WEBHOOK_SECRET nicht. Der HMAC-Endpunkt /webhooks/mta-verify-credential ist demgegenüber die Prüfung der SMTP-Submission-Zugangsdaten der MTA (siehe den Abschnitt Custom MTA oben sowie Postbox Architecture).

Authentifizierung

Setzen Sie BETTER_AUTH_SECRET im Convex-Dashboard. Verwenden Sie eine lange, zufällige Zeichenkette:

npx convex env set BETTER_AUTH_SECRET $(openssl rand -base64 32)

Nuxt-Frontend

Diese gehören in apps/web/.env:

Vollständige Referenz

Tenant-App (apps/api)

Frontend (apps/web)

MTA (apps/mta)

IMAP-Server (apps/imap)

Wird nur gestartet, wenn das Flag postbox aktiv ist (über das Docker-Compose-Profil personal-mail).

Der IMAP-Server liest MTA_WEBHOOK_SECRET nicht. Seine einzige erforderliche Convex-Zugangsberechtigung ist CONVEX_ADMIN_KEY.