Ugrás a fő tartalomra

Környezeti változók

Ez az oldal a jelenlegi Libre WebUI backendje, frontendje és karbantartási szkriptjei által olvasott, üzemeltetőknek szánt környezeti változókat sorolja fel. A kizárólag tesztekben használt belső canary értékek szándékosan kimaradnak.

Backend szerver

VáltozóAlapértékCél
NODE_ENVdevelopmentRuntime mód
PORT3001 fejlesztésben, 8080 élesbenA backend HTTP-portja
TRUST_PROXYnincs beállítva (0 a Helmben)A megbízható reverse proxy hopok pontos száma az ügyfélcím meghatározásához
CORS_ORIGINhelyi fejlesztési eredetekVesszővel elválasztott engedélyezett böngészőeredetek
SERVE_FRONTENDnincs beállítvaA lefordított frontend kiszolgálása a backendből true esetén
DOCKER_ENVnincs beállítvaDocker-orientált viselkedés engedélyezése true esetén
DATA_DIRbackend/data; ~/.libre-webui a csomagolt CLI-banTartós adatkönyvtár
PLATFORM_PREFLIGHT_TMP_DIRbackend/temp/preflight; felhasználói cache a csomagolt CLI-banIdeiglenes hely a privát DB/WAL indítási ellenőrzőmásolathoz; méretezze az adatbázis és WAL számára
PLUGIN_UPLOAD_TEMP_DIRlibre-webui-plugin-uploads az OS ideiglenes könyvtárábanIdeiglenes hely a folyamatban lévő bővítményfeltöltésekhez
PLUGINS_DIR$DATA_DIR/pluginsÍrható könyvtár a telepített/testreszabott bővítményekhez
BASE_URLhttp://localhost:3001Az OAuth callback alapértékeihez használt alap-URL
LOG_LEVELinfo (warn tesztekben)Backend naplózási szint
LOG_FORMATtextA json strukturált, egysoros naplókra vált időbélyeggel, korrelációs ID-val és kitakarással
OTEL_EXPORTER_OTLP_ENDPOINTnincs beállítvaOpcionális OTLP/HTTP JSON telemetriaexport; érték nélkül nem hagyja el telemetria a folyamatot
OTEL_EXPORTER_OTLP_HEADERSnincs beállítvaVesszővel elválasztott key=value fejlécek az OTLP-gyűjtőnek (például hitelesítés)
OTEL_SERVICE_NAMElibre-webuiAz exportált telemetria service.name erőforrás-attribútuma
WEBUI_HOSTloopback; 0.0.0.0 DockerbenHTTP-figyelési cím
OPEN_BROWSERtrue a frontend kiszolgálásakorÁllítsa false értékre az automatikus böngészőindítás letiltásához
FULL_DOCUMENT_CONTEXT_MAX_TOKENS32000Tokenkorlát a csevegésenkénti teljes dokumentum módhoz (1000-2000000)
GALLERY_RETENTION_DAYSnincs beállítva (örökre megőrzi)Ennél régebbi galériamédia törlése az ütemező ellenőrzésével
RECOVERY_DRILL_INTERVAL_HOURSnincs beállítva (gyakorlatok kikapcsolva)Ellenőrzött helyreállítási gyakorlat automatikus futtatása N óránként (solo profil)
RECOVERY_DRILL_HISTORY60Megőrzött helyreállítási gyakorlati előzménybejegyzések

A forrásból indítás a relatív DATA_DIR, PLUGINS_DIR és PLATFORM_PREFLIGHT_TMP_DIR értékeket a backend könyvtárához rögzíti, a shell munkakönyvtárától függetlenül. Beállítatlan DATA_DIR esetén — vagy az új forráspélda DATA_DIR=./data értékével — a gyökér- és backend-munkaterületi parancsok ezért a backend/data könyvtárat használják. Kompatibilitás miatt a DATA_DIR=./backend/data értéket tartalmazó meglévő forráskonfiguráció továbbra is a backend/backend/data könyvtárat választja; csak szándékos, leállított biztonsági mentés és migráció részeként módosítsa. A beállítatlan forrásprofil is tovább használja a backend/backend/data helyet, ha az az egyetlen meglévő tartós tároló. Ha mindkét hely állapotot tartalmaz, és nincs útvonal kiválasztva, az indítás biztonságosan meghiúsul találgatás, másolás vagy egyesítés helyett.

Az npx, a globális npm és az interaktív Homebrew indító ehelyett a ~/.libre-webui alatt őrzi az adatokat. Az indítónak átadott kifejezett relatív DATA_DIR a hívó munkakönyvtárából oldódik fel, majd a backend indítása előtt abszolút útvonallá alakul. A kifejezetten beállított relatív PLUGINS_DIR ugyanazt a hívóhoz viszonyított szabályt követi; ha nincs beállítva, az írható bővítmények a $DATA_DIR/plugins alatt maradnak. Az ellenőrzési ideiglenes hely alapértelmezés szerint az adatkönyvtáron kívüli, felhasználó által írható cache: macOS-en ~/Library/Caches/libre-webui, Windowson %LOCALAPPDATA%\libre-webui, más rendszereken ${XDG_CACHE_HOME:-~/.cache}/libre-webui. A Homebrew-szolgáltatás ugyanazt a saját adatkönyvtárat rögzíti, és a Homebrew var/libre-webui/preflight helyét használja ideiglenes tárként. Állítsa be kifejezetten a PLATFORM_PREFLIGHT_TMP_DIR értékét, ha a cache nem képes tárolni az adatbázist és a WAL-t. A mellékelt Docker- és Helm-telepítések a külön csatolásokkal támogatott abszolút /app/backend/data és /app/backend/temp/preflight útvonalakat használják.

Platformalapok

Az alapértelmezett solo profil SQLite-ot, helyi titkosított blobokat, titkosított beágyazott vektorokat, helyi koordinációt és beágyazott tartós workert használ. A team profil PostgreSQL-t, privát S3-kompatibilis blobokat, PGVectort, Redist és külső workert használ. A team konfiguráció biztonságosan meghiúsul: minden megosztott függőséget együtt kell kiválasztani.

VáltozóAlapértékCél
LIBRE_PLATFORM_MODEsoloA koherens solo vagy team profil kiválasztása
DATABASE_BACKENDsqlitesqlite vagy postgres kiválasztása
DATABASE_URLnincs beállítvaPostgreSQL-kapcsolati URL, postgres esetén kötelező
DATABASE_SSL_MODEverify-fullPostgreSQL TLS-szabályzat: disable, require vagy gazdagépnevet ellenőrző verify-full
POSTGRES_MIGRATION_MODEapplyKompatibilis migrációk futtatása a vezetői zárral, vagy validate használata csak olvasható sémaellenőrzéshez
POSTGRES_POOL_MAX10Legnagyobb PostgreSQL-kapcsolatszám alkalmazás- vagy workerfolyamatonként (1-100)
POSTGRES_CONNECT_TIMEOUT_MS5000PostgreSQL-kapcsolati időkorlát (1-60000 ms)
POSTGRES_IDLE_TIMEOUT_MS30000Inaktív PostgreSQL-kapcsolat időkorlátja (1-600000 ms)
POSTGRES_STATEMENT_TIMEOUT_MS30000PostgreSQL-utasítás időkorlátja (1-600000 ms)
POSTGRES_MIGRATION_LOCK_TIMEOUT_MS60000Várakozás a migrációvezetői zárra (1-600000 ms)
BLOB_STORE_BACKENDlocalTitkosított local tárolás vagy privát s3 kiválasztása
VECTOR_STORE_BACKENDembedded SQLite-talTitkosított embedded vektorok vagy pgvector kiválasztása
COORDINATION_BACKENDlocal solo módban; redis team módbanFolyamathelyi vagy Redis-koordináció kiválasztása
REDIS_URLnincs beállítvaredis: vagy rediss: URL, Redis-koordinációnál kötelező
REDIS_KEY_PREFIXlibre1-64 karakteres névtér a Libre koordinációs kulcsaihoz
REDIS_CONNECT_TIMEOUT_MS5000Kezdeti Redis-kapcsolati időkorlát, legfeljebb 60 másodperc
JOB_WORKER_MODEembedded solo módban; external team módbanHandlerek futtatása az alkalmazásban vagy az önálló megosztott workerben
RESOURCE_LEASE_TTL_MS30000Koordinációs bérlet TTL-je tartós job-erőforrások tulajdonához (5000-300000; tartományon kívül az indítás meghiúsul)
JOB_WORKER_CONCURRENCY4Egy worker által egyidejűleg futtatható tartós jobok száma (1-32)
CHAT_STREAM_EVENT_RETENTION_HOURS24A csevegési streamtöredék-események megőrzési ideje az óránkénti tisztítás előtt
PLATFORM_EVENT_RETENTION_DAYS30Bármely tartós esemény megőrzési napjai az óránkénti tisztítás előtt
PLATFORM_JOB_RETENTION_DAYS30A befejezett, életcikluson kívüli jobok megőrzési napjai az óránkénti tisztítás előtt
LIBRE_SKIP_STARTUP_INTEGRITY_SCANnincs beállítvaAz 1 kihagyja a régi titkosított szöveg mély vizsgálatát a következő indításkor (vészkijárat; egyébként sémagenerációnként cache-elt)
STORAGE_ENCRYPTION_KEYSnincs beállítvaTitkos JSON-kulcstérkép; tartalmaznia kell az ENCRYPTION_KEY értékével egyező legacy kulcsot
STORAGE_ENCRYPTION_ACTIVE_KEY_IDnincs beállítvaAz új helyi blob- és beágyazottvektor-írásokhoz használt kulcs ID-je
BLOB_QUOTA_BYTES_PER_USER10737418240Tartós legnagyobb egyszerűszöveges blobbájt tulajdonosonként (pozitív biztonságos egész)
BLOB_QUOTA_RESERVATION_TTL_MS3600000Elhagyott streaming kvótafoglalás élettartama (legalább 60000 ms)
S3_BUCKETnincs beállítvaPrivát S3-kompatibilis bucket, s3 esetén kötelező
S3_REGIONnincs beállítvaS3-régió, s3 esetén kötelező
S3_ENDPOINTszolgáltatói alapértékOpcionális abszolút HTTP(S) endpoint MinIO vagy más kompatibilis szolgáltatáshoz
S3_ACCESS_KEY_IDSDK hitelesítőadat-láncOpcionális kifejezett S3-hozzáférési kulcs
S3_SECRET_ACCESS_KEYSDK hitelesítőadat-láncKifejezett hozzáférési kulcs beállításakor kötelező
S3_SESSION_TOKENnincs beállítvaKifejezett S3-hitelesítő adatokhoz tartozó opcionális token
S3_FORCE_PATH_STYLEfalseÁllítsa true értékre az útvonalstílusú címzést igénylő szolgáltatásoknál
S3_BLOB_PREFIXlibre/blobsA Libre tulajdonában lévő átlátszatlan bucketkulcs-előtag

Ha a verziózott tárolásikulcs-térkép hiányzik, a tárolóadapterek a meglévő ENCRYPTION_KEY értéket használják legacy kulcs-ID-ként; ha ez is hiányzik, a meglévő ${DATA_DIR}/.encryption_key fájlt olvassák létrehozás vagy módosítás nélkül. A kifejezett konfigurációnak és a tartós fájlnak egyeznie kell. Ha régi kulcs mellett verziózott térkép kerül bevezetésre, a kulcsot pontosan legacy ID alatt őrizze meg mindaddig, amíg minden objektum és vektor újra nincs írva vagy csomagolva, majd ellenőrizve. Az ütközések, nem biztonságos fájlengedélyek, szimbolikus hivatkozások és hiányzó beállított kulcsok biztonságosan meghiúsulnak.

A Redis koordinációt, nem kanonikus tartós tárolást szolgál. Önmagában a kiválasztása nem teszi biztonságossá az SQLite-ot, a helyi fájlokat vagy más, folyamat által birtokolt állapotot a replikák között. Team módban a HTTP-sebességkorlátok, csevegési/WebSocket-kapcsolatok, STT/TTS/hangszolgáltatói munkák, archívumimportok és Work-terminálmunkamenetek Redis-alapú megosztott befogadást használnak. A kapacitások minden replikára együtt érvényesek, nem folyamatonként. A befogadási és megújítható engedélyhibák 503 választ adnak vagy megszakítják a folyamatban lévő műveletet; a Libre soha nem áll vissza független helyi számlálóra. Lásd: Platformalapok.

A mellékelt team Compose-profil és Helm chart minden fenti team platformválasztót és finomhangolási értéket továbbít az alkalmazásnak és a külső workernek. A Helm chartban a nem titkos választók az env alatt találhatók; kapcsolati vagy kulcsanyaghoz állítsa be a secrets.redisUrl, secrets.databaseUrl és secrets.storageEncryptionKeys értékeket. A PostgreSQL poolkorlátok folyamatonkéntiek: az adatbázisban legalább (replicaCount + worker.replicaCount) * POSTGRES_POOL_MAX kapcsolatot, valamint üzemeltetői és migrációs tartalékot tervezzen. Felügyelt vagy távoli PostgreSQL-nél tartsa meg a DATABASE_SSL_MODE=verify-full értéket. Csak a mellékelt team Compose-profil választ disable értéket, mert adatbázis-listenere a projekt privát hálózatán elkülönített. A Team Helm stabil secrets.jwtSecret értéket is igényel, és ugyanazt a Secret kulcsot csatolja minden alkalmazás- és worker-Podba; kihagyott JWT-titok egyébként folyamathelyi aláírási anyagot hozna létre. Az S3 átlátszatlan kulcsokat és titkosított szöveget kap; a bucket- és szolgáltatói URL-ek nem tárolódnak az alkalmazás metaadataiban.

Az integrált solo és team archívumok aláírt és titkosított védett konfigurációjukban megőrzik a PostgreSQL pool- és időkorlát-beállításokat, a Redis kapcsolati időkorlátját, mindkét blobkvóta-beállítást, a platformválasztókat és az S3-címzési beállításokat. Így egy tiszta visszaállítás egyszerű szöveges archívummetaadatok nélkül teheti közzé a megfelelő telepítés újraalkotásához szükséges működési értékeket.

A mellékelt team Compose és Helm alkalmazás/külső-worker párok ugyanazokat a feloldott OLLAMA_BASE_URL, OLLAMA_TIMEOUT, OLLAMA_LONG_OPERATION_TIMEOUT és OLLAMA_MAX_CONTEXT értékeket kapják. A dokumentumembeddingek, tartós csevegések és Work-futások szolgáltatói hívásai a workerben futnak, ezért ezek az értékek nem térhetnek el a folyamatok között. Mindkét szerver belépési pontja teljes, pozitív, tízes alapú egész számként elemzi a három numerikus értéket, mielőtt helyi állapotot hozna létre vagy megosztott állapothoz csatlakozna. A részleges értékek, például 300000ms, exponenciális/hexadecimális jelölés, tartományon kívüli érték és a normál időkorlátnál rövidebb hosszú műveleti időkorlát meghiúsítja az indítást.

A Helm a TRUST_PROXY értékét pontos, 0 és 16 közötti egész hop számra korlátozza, és csak a HTTP alkalmazás-Podoknak továbbítja. Közvetlen forgalomnál tartsa meg az alapértelmezett 0 értéket. Ingress/load balancer láncnál állítsa be a pontos, rögzített számot; soha ne használja a runtime korlátlan true formáját. A hibás szám vagy egy proxycím alá csoportosítja az ügyfeleket a megosztott sebességkorlátokhoz, vagy megbízik egy ügyfél által megadható címben.

A PostgreSQL-séma kompatibilitása pontos verziót igényel. A Helm alkalmazás és worker Recreate stratégiát használ; team frissítés előtt ürítsen ki és állítson le minden régi Podot, majd egy új folyamat végezze a migrációt a tanácsadó vezetői zárral. Ne futtasson kevert bináris verziókat, és ne állítsa, hogy a séma leállás nélkül telepíthető. A visszaállítás azt jelenti, hogy az ellenőrzött, frissítés előtti team archívumot tiszta PostgreSQL/S3 célokra állítja vissza a megfelelő régebbi bináris indítása előtt.

Az aktív team alkalmazás worker.replicaCount >= 1 értéket igényel; a Helm elutasítja a tartós worker nélküli élő alkalmazást ahelyett, hogy a készenléti hiba bekövetkezésére várna. Teljes felfüggesztéshez állítsa nullára az alkalmazás és a worker számát. Nulla alkalmazás pozitív workerszámmal szándékos, csak workeres kiürítési vagy helyreállítási mód, amely webforgalom kiszolgálása nélkül tovább dolgozza fel a sorban álló jobokat.

Privát biztonságimentés-segéd

Ezek a változók a deploy/private/libre-webui-backup eszközt állítják be, és a karbantartási szkript olvassa őket, nem az alkalmazásfolyamat:

VáltozóAlapértékCél
LIBRE_WEBUI_STACK_DIR/opt/libre-webuiA privát Compose-fájlt tartalmazó könyvtár
LIBRE_WEBUI_BACKUP_DIR/var/backups/libre-webuiVédett könyvtár a mentéskészletekhez és a zárfájlhoz
LIBRE_WEBUI_BACKUP_RETENTION_DAYS14A befejezett mentéskészletek eltávolítási kora
LIBRE_WEBUI_CONTAINER_NAMElibre-webuiAz ellenőrizendő telepített alkalmazáskonténer
LIBRE_WEBUI_BACKUP_KEY_DIR/etc/libre-webui/backup-keysA privát archívumtitkosítási és aláírókulcsok könyvtára
LIBRE_WEBUI_RESTORE_IMAGEvisszaállításhoz kötelezőEllenőrzött, megváltoztathatatlan Libre lemezkép-ID vagy digest
LIBRE_WEBUI_RESTORE_CONFIG_DIRkötetenkénti útvonal az /etc/libre-webui/restored alattÚj könyvtár a helyreállított konfigurációhoz

A systemd egység a root tulajdonában lévő opcionális /etc/libre-webui/backup.env fájlból tölti be a mentési felülírásokat. Állítsa 0600 módra. A stack könyvtára, a megőrzés, a konténer neve és a mentésikulcs-könyvtár közvetlenül beállítható benne. Az egység fájlrendszer-sandboxa csak az alapértelmezett mentési könyvtár alatt enged írást. Az egyéni LIBRE_WEBUI_BACKUP_DIR ezen felül pontosan ezt az előre létrehozott könyvtárat igényli egy ReadWritePaths= szolgáltatás-drop-inban; lásd: Privát távoli telepítés.

Hitelesítés és biztonság

VáltozóAlapértékCél
ENABLE_SIGNUPfalseRegisztráció engedélyezése az első helyi rendszergazda után
JWT_SECRETlétrehozott/tartalék fejlesztésbenJWT-aláírási titok; élesben állítsa be kifejezetten
JWT_EXPIRES_IN7dA munkamenettoken élettartama
ENCRYPTION_KEYautomatikusan létrehozott64 karakteres hexadecimális kulcs a titkosított értékekhez
DEBUG_ENCRYPTIONnincs beállítvaBeállításakor titkosítási hibakeresési kimenetet naplóz
TURNSTILE_SITE_KEYnincs beállítvaCloudflare Turnstile webhelykulcs bejelentkezéshez és regisztrációhoz
TURNSTILE_SECRET_KEYnincs beállítvaCloudflare Turnstile titkos kulcs a backend ellenőrzéséhez
TURNSTILE_EXPECTED_HOSTNAMEgazdagépnév a BASE_URL alapjánKötelező gazdagépnév a Cloudflare ellenőrzési válaszában
MFA_REQUIRED_MODEnincs beállítva (admin kapcsoló, optional)A kétfaktoros szabályzat rögzítése optional vagy required értékre
WEBAUTHN_RP_IDa kérés gazdagépneveRögzített relying-party ID több gazdagépnév mögötti passkeyekhez
VAPID_PUBLIC_KEYlétrehozott és titkosítva tároltA Web Push VAPID nyilvános kulcs rögzítése (base64url P-256 pont)
VAPID_PRIVATE_KEYlétrehozott és titkosítva tároltA Web Push VAPID privát kulcs rögzítése (base64url skalár)
VAPID_SUBJECTmailto:admin@localhostKapcsolati claim az aláírt Web Push-engedélyezésekben

A Turnstile csak akkor engedélyezett, ha mindkét Turnstile-kulcs rendelkezésre áll.

Az ENABLE_SIGNUP=false továbbra is engedélyezi az első helyi rendszergazdát üres adatbázisban, majd blokkolja a további helyi és OAuth-fiókokat. Az első indítás előtt védje a távolról elérhető kezdeti útvonalat külső identitáshatárral.

Minden kiadott JWT szerveroldali munkamenethez kötődik (sid claim), így a Beállítások → Munkamenetek alatt történő kijelentkezés vagy visszavonás azonnal érvényteleníti a tokent minden replikán, és bezárja az aktív WebSocket-kapcsolatokat. A biztonsági auditmegőrzés beállítható:

VáltozóAlapértékCél
AUDIT_RETENTION_DAYS180A biztonsági auditesemény-napló sorainak megőrzési napjai

Általános OIDC egyszeri bejelentkezés

Bármely felderítési dokumentummal rendelkező OpenID Connect szolgáltató használható bejelentkezéshez. A folyamat PKCE-t (S256), CSRF-állapotot és az aláírás-ellenőrzött ID-tokenben hitelesített nonce értéket használ. Az identitások a stabil sub claim alapján kapcsolódnak.

VáltozóAlapértékCél
OIDC_ISSUER_URLnincs beállítvaKibocsátói alap-URL; a felderítés innen töltődik: <issuer>/.well-known/openid-configuration
OIDC_CLIENT_IDnincs beállítvaA szolgáltatónál regisztrált OAuth-kliens ID-je
OIDC_CLIENT_SECRETnincs beállítvaOAuth-kliens titka
OIDC_DISPLAY_NAMESingle Sign-OnA bejelentkezési gombon megjelenő címke
OIDC_SCOPESopenid profile emailKért hatókörök
OIDC_CALLBACK_URLBASE_URL + OIDC callback útvonalA szolgáltatónál regisztrált átirányítási URI
OIDC_ALLOWED_EMAIL_DOMAINSnincs beállítvaVesszővel elválasztott lista; beállításakor ellenőrzött e-mail szükséges az egyik domainben
OIDC_GROUP_CLAIMgroupsCsoportneveket tartalmazó ID-token claim
OIDC_ADMIN_GROUPSnincs beállítvaVesszőlista; beállításakor az admin szerepkör minden bejelentkezéskor követi a claim-tagságot
OIDC_SYNC_GROUPSfalseA true minden bejelentkezéskor összehangolja a Libre-csoporttagságokat a csoportclaimmel

Az OIDC csak akkor engedélyezett, ha a kibocsátói URL, a kliens ID és a kliens titka is rendelkezésre áll. Egy nem kapcsolt helyi fiók által már használt e-mail-cím elutasításra kerül az észrevétlen egyesítés helyett, a fióklétrehozás pedig továbbra is tiszteletben tartja az ENABLE_SIGNUP értékét.

A Chat WebSocket-befogadás a hitelesítés gyengítése nélkül hangolható:

VáltozóAlapértékCél
CHAT_WS_MAX_PAYLOAD_BYTES10 MiBLegnagyobb elfogadott WebSocket-üzenetméret
CHAT_WS_MAX_MESSAGES_PER_MINUTE120WebSocket-üzenetek felső határa kapcsolatonként
CHAT_WS_MAX_ACTIVE_GENERATIONS_PER_USER4Engedélyezett szolgáltatói generálások fiókonként
CHAT_WS_MAX_CONNECTIONS_PER_USER5Egyidejű hitelesített socketek fiókonként
WEBSOCKET_TICKET_TTL_MS30000Egyszer használatos Chat/Work-jegy élettartama; legfeljebb 60 másodperc

A böngésző a szokásos Authorization fejlécét átlátszatlan jegyre cseréli, és csak ezt a rövid élettartamú értéket helyezi a WebSocket frissítési URL-jébe. A jegyek egyszer használatosak, protokollhoz és munkamenethez kötöttek, és csak hashként tárolódnak. Így a tartós munkamenettokenek nem kerülnek a reverse proxy kéréstarget-naplóiba. Ha a CORS_ORIGIN vagy a BASE_URL be van állítva, az Origin fejléccel rendelkező böngészőfrissítésnek egyeznie kell valamelyik beállított eredettel. Távolról elérhető telepítésnél legalább egyet állítson be; ha egyik sincs, az Origin-szűrő a helyi fejlesztéssel való kompatibilitásért megengedő. Az eredet nélküli frissítések szándékosan támogatottak az Electron és nem böngészős kliensek számára, ahol a böngésző Origin-vezérlése nem érhető el; továbbra is érvényes egyszer használatos jegyet igényelnek, és ugyanazon aktuálisfiók-, Work-hozzáférési és feladatellenőrzéseket kapják. A jegyet hitelesítési határként kezelje, a nem böngészős hozzáférést pedig a telepítés szokásos TLS-, tűzfal- és reverse proxy vezérlőivel korlátozza.

OAuth

VáltozóCél
GITHUB_CLIENT_IDGitHub OAuth-kliens ID-je
GITHUB_CLIENT_SECRETGitHub OAuth-kliens titka
GITHUB_CALLBACK_URLGitHub callback URL felülírása
HUGGINGFACE_CLIENT_IDHugging Face OAuth-kliens ID-je
HUGGINGFACE_CLIENT_SECRETHugging Face OAuth-kliens titka
HUGGINGFACE_CALLBACK_URLHugging Face callback URL felülírása

Ha a callback URL-ek nincsenek beállítva, a Libre WebUI a BASE_URL alapján hoz létre alapértékeket.

Ollama

VáltozóAlapértékCél
OLLAMA_BASE_URLhttp://localhost:11434Az Ollama API alap-URL-je
OLLAMA_TIMEOUT300000Normál Ollama-kérés időkorlátja (1,000-3,600,000 ms)
OLLAMA_LONG_OPERATION_TIMEOUT900000Hosszú művelet időkorlátja (1,000-3,600,000 ms, és nem rövidebb az OLLAMA_TIMEOUT értéknél)
OLLAMA_MAX_CONTEXT32768Automatikusan elfogadott legnagyobb modellkontextus (128-2,097,152 token)

Webes keresés

VáltozóAlapértékCél
SEARXNG_URLnincs beállítvaA webes keresés alapértelmezett SearXNG endpointja; a rendszergazda a Beállítások > Keresés alatt engedélyezi

Libre Claw

VáltozóAlapértékCél
LIBRE_CLAW_BASE_URLhttp://127.0.0.1:8766A Libre Claw démon opcionális URL-je
LIBRE_CLAW_TIMEOUT_MS30000Libre Claw HTTP-kérés időkorlátja

Work-runtime

Ezek a változók a Work végrehajtását állítják be azon a gépen vagy Kubernetes-klaszteren, amelyen a Libre WebUI backendje fut. Az alapértelmezett runtime a Docker; a Helm chart work.enabled=true esetén Kubernetest választ.

VáltozóAlapértékCél
WORK_RUNTIME_IMAGEnode:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3A Work-sandboxokhoz használt rögzített lemezkép
WORK_DOCKER_COMMANDdockerA folyamat számára elérhető Docker-backend CLI-futtatható fájl
WORK_COMMAND_TIMEOUT_MS120000Alapértelmezett időkorlát; egy eszköz legfeljebb 600000 ms-ot kérhet
WORK_MAX_OUTPUT_CHARS50000Rögzített stdout/stderr korlát, streamenként alkalmazva
WORK_MAX_AGENT_ROUNDS48Szolgáltatófüggetlen modell-/eszközkör-keret egy futáshoz
WORK_STATUS_BLURB_MODEL1Állítsa 0 értékre a futás utáni ágensállapotsort író modellkérés kihagyásához
WORK_MEMORY_LIMIT2gMinden Work-konténernek átadott memóriakorlát
WORK_CPU_LIMIT2Minden Work-konténernek átadott CPU-korlát
WORK_PIDS_LIMIT256Minden Work-konténernek átadott folyamatkorlát
WORK_PREVIEW_PORT4173Az előnézeti szerver által a feladatkonténerben használandó port
WORK_PREVIEW_BIND127.0.0.1A gazdagép felülete, amelyen a feladatelőnézet portja közzétételre kerül; a natív Docker Engine-en futó Compose-telepítéseknek elérhető, nem nyilvános hídfelületet kell használniuk
WORK_DOCKER_PUBLISHED_HOSTalkalmazás alapértelmezés: ugyanaz, mint WORK_PREVIEW_BIND; Compose alapértelmezés: host.docker.internalA backend által látott gazdagép/IP a Docker által közzétett előnézeti, képernyő- és hangportokhoz
WORK_COMPUTER_SCREEN_PORT6080A Work Computer képernyőhídjának (websockify) konténerportja GUI-s sandboxokban
WORK_COMPUTER_AUDIO_PORT6081A Work Computer hanghídjának (websockify → PulseAudio monitor) konténerportja GUI-s sandboxokban
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL3Egyidejű, runtime által támogatott feladatok az egész példányban
WORK_MAX_ACTIVE_RUNTIMES_PER_USER2Egyidejű, runtime által támogatott feladatok egy felhasználónál
WORK_MAX_TASKS_GLOBAL500Tartós Work-feladatok legnagyobb száma az egész példányban
WORK_MAX_TASKS_PER_USER100Tartós Work-feladatok legnagyobb száma egy rendszergazdánál
WORK_NETWORK_NAMElibre-webui-workKezelt sandbox bridge hálózat hálózatos feladatokhoz
WORK_RUN_LEASE_WAIT_MS60000Ennyi ideig vár a futás a feladat megosztott runtime-bérletére replikakonfliktus jelzése előtt (team)
WORK_RUNTIME_DNSnincs beállítvaVesszővel elválasztott resolver IP-k a hálózatos feladatokra kényszerítve
WORK_DOCKER_SOCKETDOCKER_HOST, ha unix:// vagy tcp://, különben /var/run/docker.sockDocker Engine endpoint terminálokhoz és diagnosztikához
WORK_TERMINAL_MAX_SESSIONS_PER_TASK2Egy feladathoz kapcsolt egyidejű böngészőterminálok
WORK_TERMINAL_IDLE_TIMEOUT_MS900000Inaktivitási időkorlát a terminálmunkamenet bezárása előtt
WORK_RUNTIME_IDLE_TIMEOUT_MS0 (letiltva)Sandbox leállítása ennyi inaktivitás után (előnézetek is)
WORK_HOST_WORKSPACES_ENABLEDfalseFeladat számára gazdagépmappa használatának engedélyezése kötet helyett
WORK_HOST_WORKSPACE_ROOTSa szerverfelhasználó saját könyvtára: jellel elválasztott gyökerek, amelyekben a gazdagép munkaterületének lennie kell
WORK_RUNTIME_BACKENDdockerSandbox backend: docker vagy kubernetes
WORK_K8S_NAMESPACElibre-webui-workA Kubernetes sandbox-Podokat és PVC-ket tartalmazó névtér
WORK_K8S_STORAGE_CLASSklaszter alapértékeStorageClass a munkaterületi PVC-khez
WORK_K8S_WORKSPACE_SIZE5GiFeladatonkénti munkaterületi PVC-méret (valódi lemezkvóta)
WORK_K8S_POD_READY_TIMEOUT_MS900000Várakozás, amíg a sandbox-Pod Running állapotba kerül (letöltésekkel együtt)
WORK_K8S_POD_GONE_TIMEOUT_MS60000Várakozás a törölt sandbox-Pod eltűnésére
AGENT_CLI_MODELS_ENABLEDnincs beállítva (admin kapcsoló, kikapcsolva)Az Ágensek funkció be-/kikapcsolt állapotának rögzítése; érték nélkül a Felhasználókezelés kapcsolója vezérli
TOOLS_ACCESS_MODEnincs beállítva (admin kapcsoló, csak rendszergazdák)Csevegési eszközök rögzítése admins vagy all-users értékre és a kapcsoló zárolása
STT_ACCESS_MODEnincs beállítva (admin kapcsoló, minden felhasználó)Beszédből szöveg rögzítése admins vagy all-users értékre és a kapcsoló zárolása
TTS_ACCESS_MODEnincs beállítva (admin kapcsoló, minden felhasználó)Szövegből beszéd rögzítése admins vagy all-users értékre és a kapcsoló zárolása
VOICE_MODE_ACCESS_MODEnincs beállítva (admin kapcsoló, minden felhasználó)Kéz nélküli hangmód rögzítése admins vagy all-users értékre és a kapcsoló zárolása
VOICE_CLONING_ACCESS_MODEnincs beállítva (admin kapcsoló, minden felhasználó)Hangklónozás rögzítése admins vagy all-users értékre és a kapcsoló zárolása
TOOLS_PRIVATE_NETWORK_ALLOWLISTnincs beállítvaPontos gazdagépnevek, ahol eszközszerverek és webhookcélok privát címre oldhatók; rögzítve
AGENT_CLI_TIMEOUT_MS600000Az ágens CLI futási ideje a leállítás előtt
CODEX_OAUTH_MODELS_ENABLEDtrueA Codex (ChatGPT) szolgáltató felajánlása rendszergazdáknak
CODEX_HOME~/.codexA Codex CLI bejelentkezés (auth.json) olvasási helye

Az ágens CLI binárisai és a Codex OAuth hitelesítő adatai csomóponthelyiek. Csak solo folyamatban támogatottak, ahol a felderítés és végrehajtás ugyanazt a fájlrendszert és környezetet látja. Team módban a tartós csevegési jobok külső workerben futnak, ezért az AGENT_CLI_MODELS_ENABLED=false és CODEX_OAUTH_MODELS_ENABLED=false egyaránt szükséges; az indítás minden más értéket elutasít ahelyett, hogy olyan szolgáltatót hirdetne, amely csak egy alkalmazásreplikán létezhet. Használjon Ollamát vagy olyan szolgáltatói bővítményt, amelynek hitelesítő adatai és útválasztása megosztott PostgreSQL-ben tárolódik, vagy azonosan továbbítódik minden alkalmazásnak és workernek.

A Docker backenden a gazdagép-munkaterület egy valódi könyvtárat csatol a /workspace helyre, így a feladat közvetlenül olvashatja és írhatja ezeket a fájlokat a saját Docker-kötet használata helyett. A Kubernetes elutasítja a gazdagépmappás munkaterületeket. Ez a Docker-sandbox szándékos gyengítése: tartsa kikapcsolva a WORK_HOST_WORKSPACES_ENABLED értéket, ha nincs rá szükség, a WORK_HOST_WORKSPACE_ROOTS értékét pedig a lehető legszűkebbre. A kért útvonalak a gyökerekhez való ellenőrzés előtt szimbolikus hivatkozásokon keresztül feloldódnak, az olyan mappák pedig, mint a .ssh, .gnupg, .aws és .config, egyértelműen elutasításra kerülnek.

Az ágens CLI modellek a szerveren már telepített programozási ágenseket (claude, codex) választható csevegési modellként teszik elérhetővé, így az előfizetéses ágens API-kulcs nélkül válaszolhat. Csak a rendszergazdák látják őket, a CLI a Libre WebUI szerverfelhasználójaként fut, és örökli a felhasználó ágens-hitelesítő adatait — ezt tekintse egyenértékűnek az ágenseknek adott shell-hozzáféréssel.

Dockerben a hálózatos Work-feladatok a kezelt WORK_NETWORK_NAME bridge-hez csatlakoznak, amely letiltott konténerközi kommunikációval jön létre, így egy sandbox nem érhet el másik sandboxot vagy a telepítés saját konténereit. A WORK_RUNTIME_DNS a támogatott Docker kimenőforgalmi szabályzati pont: irányítsa szűrő resolverhez névalapú engedélyezési/tiltási listák alkalmazásához. A nem IPv4/IPv6 címek elutasításra és naplózásra kerülnek. A DNS-szűrés nem korlátozza a közvetlen IP-kimenetet; szükség esetén adjon hozzá gazdagép-tűzfalszabályokat. A Kubernetes backend ehelyett a chart alapértelmezett tiltó NetworkPolicies beállításait és a work.networkPolicy.blockedEgressCidrs értékeket használja.

Dockerben az interaktív terminál és a rendszerdiagnosztika közvetlenül a Docker Engine API-val kommunikál. Beállításakor a WORK_DOCKER_SOCKET értéket követi, különben a DOCKER_HOST értéket — unix:// socketet vagy egyszerű HTTP-s tcp:// endpointot, például socketproxyt (lásd docker-compose.socket-proxy.yml) —, ezek hiányában pedig a /var/run/docker.sock helyet. Az olyan DOCKER_HOST, amellyel ez a kliens nem tud kommunikálni (ssh://, vagy tcp:// beállított DOCKER_TLS_VERIFY mellett), elérhetetlenként jelzi a terminált és Docker-diagnosztikát; a Work többi része tovább fut a Docker CLI-n keresztül, amely önállóan érti ezeket az endpointokat. Kubernetesben a terminál a Pod exec alerőforrást használja, Docker endpointot nem.

A Work a backend indításakor olvassa ezeket az értékeket. Az előnézeti port a feladatkonténeren belüli; a Libre WebUI dinamikusan kiosztott loopback porton teszi közzé, nem közvetlenül minden gazdagépfelületen.

A runtime-lemezképet ellenőrzött verzióhoz vagy digesthez rögzítse. A párhuzamosság vagy erőforráskorlátok növelése megemeli az egy vagy több önálló futás által felhasználható runtime-kapacitást. A WORK_MAX_AGENT_ROUNDS egyformán vonatkozik az Ollama- és bővítményalapú futásokra; nincs alacsonyabb, csak bővítményekre érvényes korlát. Az eszközhívási biztonsági keret max(128, WORK_MAX_AGENT_ROUNDS × 8). Ha a futás elhasználja a körkeretét, a Work végső, eszköz nélküli átadást kér a modelltől, és needs_input terminális állapotban fejeződik be nyers körkorláthiba vagy hamis sikerjelzés helyett. A következő futás ugyanabban a tartós munkaterületben folytatódik. A tartós eszközkimenet külön, körülbelül 20,000 forráskarakteres korláttal és csonkolási jelölővel rendelkezik.

Ezek a változók egy már elérhető Work-runtime-ot hangolnak. A tároló egyetlen példányos Compose-telepítései alapértelmezés szerint engedélyezik: a lemezkép tartalmazza a Docker CLI-t, a Compose-fájlok pedig csatolják a gazdagép Docker-socketjét. Ezt a kapcsolatot két Compose-szintű változó vezérli:

VáltozóAlapértékCél
DOCKER_GID0A gazdagép Docker-socketjének csoport-ID-je, a konténerfelhasználóhoz adva
DOCKER_SOCKET/var/run/docker.sockA csatolandó Docker-socket gazdagépútvonala

A DOCKER_GID értékének a socket konténeren belül látható csoportjának kell lennie; a macOS-gazdagép más értéket jelent. A team Compose-alap nem csatol socketet, és a Docker-alapú Work elérhetetlen marad a docker-compose.team.work.yml hozzáadásáig. Ez az éles overlay ugyanazt a belső szűrt proxy-endpointot adja az alkalmazásnak és a workernek, soha nem socketcsatolást vagy socketcsoportot. A proxy csak a runtime által használt Docker API-részeket engedélyezi, de a konténerlétrehozás továbbra is Docker-gazdagép-vezérlési hitelesítő adat; erősebb határhoz használjon dedikált vagy rootless Work démont. A Helm chart soha nem csatol csomóponti runtime-socketet. A natív Pod/PVC Work backend a work.enabled=true beállítással engedélyezhető.

A solo profilnak nulla vagy egy alkalmazásreplikán kell maradnia, mert SQLite-ot, helyi fájlokat és folyamathelyi koordinációt használ. A Helm chart szándékos felfüggesztéshez elfogadja a nullát, és elutasítja a nagyobb solo replikaszámot vagy automatikus skálázást. A teljes team profil több alkalmazásreplikát és külső workert használhat, mert a megosztott állapotot PostgreSQL, S3, PGVector és Redis birtokolja. A Work sandbox-Podok mindkét profilban függetlenül skálázódnak; team módban a külső worker ugyanazt a Kubernetes runtime-lemezképet, StorageClasst és work.env korlátokat kapja, mint az alkalmazás-Podok.

A tároló Compose-fájljai a WEBUI_BIND_ADDRESS (alapértelmezés: 127.0.0.1) és WEBUI_PORT (alapértelmezés: 8080) értékeket is elfogadják. Tartsa meg a loopback alapértéket, hacsak megbízható LAN-nak vagy gazdagép reverse proxynak nem kell elérnie a portot.

Szolgáltatói modellek felderítése

A szolgáltató modellkatalógusa automatikusan újra felderítődik, ha hiányzik vagy elavult, így a frissítés a szolgáltató által jelenleg kínált modelleket tükrözi. Ezt a ciklust a következő változók hangolják:

VáltozóAlapértékCél
PLUGIN_MODEL_DISCOVERY_TTL_MS21600000 (6 h)Az a kor, amikor a tárolt katalógus a következő bővítménylista-olvasáskor frissül
PLUGIN_MODEL_DISCOVERY_RETRY_MS600000 (10 min)Legrövidebb idő a próbálkozások között, hogy a hibázó szolgáltató ne legyen gyakran ellenőrizve
PLUGIN_MODEL_DISCOVERY_REFRESH_DEADLINE_MS3000Ennyi ideig vár a bővítménylista-válasz a frissítésekre válaszadás előtt

A határidőt túllépő frissítés továbbra is befejeződik, és a következő kérésnél szolgálódik ki. A kifejezett Modellek frissítése mindig kapcsolatba lép a szolgáltatóval, és figyelmen kívül hagyja az időközt.

Szolgáltatói bővítménykulcsok

A szolgáltatói bővítmények telepítésszintű alapértékként használhatnak környezeti kulcsokat:

VáltozóSzolgáltató
OPENAI_API_KEYOpenAI és OpenAI TTS
ANTHROPIC_API_KEYAnthropic
GROQ_API_KEYGroq
GEMINI_API_KEYGoogle Gemini
MISTRAL_API_KEYMistral
OPENROUTER_API_KEYOpenRouter
KIMI_API_KEYKimi Code, Moonshot AI
GITHUB_API_KEYGitHub Models
HUGGINGFACE_API_KEYHugging Face API-k, ahol be vannak állítva
ELEVENLABS_API_KEYElevenLabs TTS
COMFYUI_API_KEYAPI-kulcsot igénylő ComfyUI-telepítések

A felhasználók a felületen is tárolhatnak szolgáltatói hitelesítő adatokat, ha felhasználónkénti kulcsokat részesítenek előnyben. A környezeti kulcsok csak egy nem elfedett mellékelt definíció útválasztási és hitelesítési vetületével használhatók. Az importált definíciók, a mellékelt ID-t újrahasználó írható definíciók és a rendszergazda által mentett egyéni útvonalak az adott fiók által tárolt hitelesítő adatot igényelnek. A Libre WebUI nem csatol környezeti kulcsot ezekhez az útvonalakhoz, és felderítési vagy elérhetőségi ellenőrzéseken keresztül sem teszi elérhetővé. A bizalom az egyes mellékelt manifestek lefordított hashéből ered, így továbbra is támogatottak azok a konténerelrendezések, ahol a régi és mellékelt bővítménykönyvtárak közös útvonalat használnak, anélkül hogy a módosított manifestet mellékeltnek tekintenék.

A felhasználó által mentett kulcsok a tényleges szolgáltatói definícióhoz, forráshoz, hitelesítési szerződéshez és útválasztási értékekhez kötődnek. A rendszergazda célmódosítása után a felhasználónak újra mentenie kell a kulcsot. A frissítés előtti, nem kötött kulcsok elfogadásra kerülnek, de az első használatkor csak a saját mellékelt útvonalát használó pontos szállított definícióhoz kötődnek.

Forrásból indításkor a relatív PLUGINS_DIR értékek a backend könyvtárából oldódnak fel. A csomagolt indító ehelyett a kifejezetten beállított relatív értéket a hívóhoz viszonyított abszolút útvonallá alakítja a backend indítása előtt. Kompatibilitásért a Libre a determinisztikus backend/plugins könyvtárat és a korábbi konfigurációk által kiválasztott történeti helyeket is olvassa. Helyezze át a definíciókat a $DATA_DIR/plugins könyvtárba; a helyreállítás külső állapotként jelenti a régi útvonalakat, és blokkolja a csak kötetet tartalmazó pillanatképet, amíg egyéni definíciók maradnak ott. A bővítménykönyvtáraknak és JSON-definícióknak fizikai, szabályos bejegyzéseknek kell lenniük — a Libre nem követ bővítmény-szimbolikus hivatkozásokat.

Frontend

VáltozóAlapértékCél
VITE_API_BASE_URLazonos eredetű fejlesztői proxy vagy éles APIA frontend API alap-URL-je
VITE_WS_BASE_URLaz API URL-ből következtetveAbszolút ws:/wss: alap a Chat és Work socketjeihez
VITE_APP_VERSIONa Vite konfiguráció által beillesztett csomagverzióMegjelenített alkalmazásverzió
VITE_DEMO_MODEfalsetrue esetén engedélyezi a bemutató mód szimulációit
VITE_API_TIMEOUT300000Frontend API időkorlát ezredmásodpercben
VITE_BACKEND_URLhttp://localhost:3001Egyes hitelesítési segédkomponensek használják
VITE_DEBUG_VERBOSEnincs beállítvaRészletes frontend hibakeresési napló engedélyezése fejlesztésben
VITE_LOG_LEVELnincs beállítvaA frontend naplózási szintjének felülírása
ELECTRON_BUILDnincs beállítvatrue esetén Electron-specifikus Vite-viselkedés engedélyezése

A VITE_WS_BASE_URL minden WebSocket-tartalékértéket felülír a Chat és a Work-terminál számára. Tartalmazhat reverse proxy útvonalelőtagot, de abszolút ws: vagy wss: URL-nek kell lennie hitelesítő adatok, lekérdezés vagy fragmentum nélkül. Beállítatlanul az Electron file: kliensek a ws://localhost:3001 címet használják; a böngészőkliensek az alapot a VITE_API_BASE_URL értékből, majd a böngészőeredetből származtatják. A Vite a fejlesztési eredetet a 3001-es porton futó backendre proxyzza.

Karbantartási szkriptek

VáltozóCél
CHANGELOG_AI0 értékkel letiltja az AI-segített változásnapló-piszkozatokat
CHANGELOG_AI_MODELOllama-modell kiadás-/változásnapló-generáláshoz
CHANGELOG_AI_TIMEOUT_MSAI-változásnapló-generálás időkorlátja ezredmásodpercben

Példa:

CHANGELOG_AI_MODEL=glm-5.2:cloud npm run changelog
CHANGELOG_AI=0 npm run release:minor

Éles példa

NODE_ENV=production
PORT=3001
SERVE_FRONTEND=true
DATA_DIR=/data/libre-webui
CORS_ORIGIN=https://librewebui.example
BASE_URL=https://librewebui.example

JWT_SECRET=replace-with-a-long-random-secret
ENCRYPTION_KEY=replace-with-64-hex-characters
ENABLE_SIGNUP=false

OLLAMA_BASE_URL=http://ollama:11434
OLLAMA_TIMEOUT=300000
OLLAMA_LONG_OPERATION_TIMEOUT=900000
OLLAMA_MAX_CONTEXT=32768

TURNSTILE_SITE_KEY=...
TURNSTILE_SECRET_KEY=...
TURNSTILE_EXPECTED_HOSTNAME=librewebui.example

Kapcsolódó dokumentáció