Platformalap

A Libre WebUI egy helyi solo és egy megosztott team profilt támogat. A solo SQLite-ot, titkosított helyi blobokat, beágyazott vektorokat, helyi koordinációt és beágyazott tartós workert használ. A team PostgreSQL-t, privát S3-blobokat, PGVectort, Redist és külső workert használ. A vegyes profilokat induláskor elutasítja, ahelyett hogy csendben megosztaná az állapotot.

Jelenlegi mérföldkő

Terület	Megvalósított alap	Hátralévő munka
Megőrzés	SQLite/PostgreSQL repository-k, megváltoztathatatlan migrációk, poololt tranzakciók	Új tartományok repository-határok mögött
Blobok	Titkosított helyi/S3-streaming, tartományok, checksumok és tartós kvóták	Mellékletek, avatarok és inline bináris tartalom áthelyezése
Vektorok	Titkosított beágyazott vektorok, PGVector ACL, biztonságos újraépítés	Ugyanaz a jogosultság és életciklus az új hívóknál
Koordináció	Local/Redis események, gyorsítótár, lease-ek, rate limitek, érvénytelenítés, health	A Redis ne váljon irányadóvá
Feladatok/események	SQLite/PostgreSQL sorok, tranzakciós események, workerek, újrapróbálás, megszakítás, adminisztráció	Idempotency vagy outbox minden mellékhatáshoz
Üzemeltetés	Állapotkapuk, aláírt/titkosított archívumok, tiszta visszaállítás és ellenőrzés	Visszaállítási/cross-replica elfogadás telepítésenként

Runtime-profilok

A LIBRE_PLATFORM_MODE=solo az alapérték: SQLite, helyi blobok, beágyazott vektorok, helyi koordináció és beágyazott worker. Redis hozzáadása a solo profilhoz nem teszi biztonságossá a helyi fájlok megosztását.

A LIBRE_PLATFORM_MODE=team együtt követeli meg:

• DATABASE_BACKEND=postgres és DATABASE_URL;
• BLOB_STORE_BACKEND=s3;
• VECTOR_STORE_BACKEND=pgvector;
• COORDINATION_BACKEND=redis és REDIS_URL; valamint
• JOB_WORKER_MODE=external.

Hiányzó megosztott függőség vagy helyi backend leállítja az indulást.

Meglévő solo profil migrálása

Állítsa le az alkalmazásokat és workereket. Használja a libre-webui vagy npx --yes libre-webui@latest parancsot; forrásból a libre-webui migrate-postgres helyett futtassa az npm run migrate:postgres -- parancsot. Állítsa be a célokat, majd először ezt futtassa:

libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode dry-run

Csak üres célra alkalmazza. A megszakítás checksummal ellátott naplót hagy ugyanazon forrás és cél folytatásához:

libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode apply

# Only after an interrupted apply of this exact source and target:
libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode apply --resume

libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode validate

A befejezési jelölő a relációs sorok, bővítmények, titkosított blobok, vektorok és legacy persona-vektorok átvitele után íródik. Az ENCRYPTION_KEY értékének egyeznie kell a forrás .encryption_key fájljával, a STORAGE_ENCRYPTION_KEYS pedig az aktív és legacy kulcsot is tartalmazza.

A team profil futtatása

cp deploy/team/.env.example /absolute/path/to/libre-team.env
chmod 600 /absolute/path/to/libre-team.env

Cserélje ki a REPLACE_* értékeket. A PostgreSQL-jelszó legyen URL-biztos, például openssl rand -hex 32. Az ENCRYPTION_KEY és a STORAGE_ENCRYPTION_KEYS minden értéke 64 hexadecimális karakter. Új telepítésnél legacy = ENCRYPTION_KEY; migrációnál a forráskulcs. Az új blobokhoz használjon másik aktív kulcsot, a régieket pedig az ellenőrzött újraírásig őrizze meg.

A fájl beállíthatja a POSTGRES_MIGRATION_MODE, POSTGRES_POOL_MAX, PostgreSQL-timeoutok, REDIS_CONNECT_TIMEOUT_MS, OLLAMA_BASE_URL, OLLAMA_TIMEOUT, OLLAMA_LONG_OPERATION_TIMEOUT és OLLAMA_MAX_CONTEXT értékeket. A timeoutok 1 000–3 600 000 ms közöttiek, a kontextus 128–2 097 152 token, a hosszú timeout pedig nem lehet kisebb a normálnál. Az érvénytelen értékek leállítják az entrypointokat. A node-helyi Agent CLI és a Codex OAuth nem támogatott külső workeren.

docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml up --build --scale libre-webui=3 -d
docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml ps

Az alapprofil nem csatlakoztat Docker socketet. Workhöz adja hozzá az overlayt:

docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml -f docker-compose.team.work.yml \
  up --build --scale libre-webui=3 -d
docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml -f docker-compose.team.work.yml ps

Az overlay szűrt belső proxyt használ az alkalmazás és a worker számára. Nem ad nyers socketet vagy hostmappákat. Engedélyezi az info, images, containers, exec, volumes, networks és szükséges írási műveleteket. Szűkíti az API-t, de a Docker nem bérlői határ, mert a konténerek hostútvonalakat csatlakoztathatnak. Használjon dedikált VM-et vagy rootless/külön daemont.

Ne tegye közzé a Compose PostgreSQL-, Redis- vagy MinIO-szolgáltatását. Felügyelt függőségekhez használja a Helm team profilt és TLS-t. A readiness külső worker nélkül sikertelen.

A megőrzési és migrációs határ

Az identitás és jogosultság aszinkron repository-kat használ. A tranzakció callbackje ugyanazon a kapcsolaton kap unit of work egységet; globális repository használata belül elutasított. Az SQLite-koordinátor csak sémaellenőrzés után fogadja el az adatbázist, rögzíti a migrációt/checksumot, és elutasítja az újabb, ismeretlen vagy módosított naplókat. A readiness és recovery ugyanazt a szerződést használja.

Az állapottartó szolgáltatások előtt az SQLite és a WAL/SHM privát ideiglenes helyre másolódik és ellenőrződik. A PLATFORM_PREFLIGHT_TMP_DIR helyének elég nagynak kell lennie az adatbázis és WAL számára; a Docker és Helm a /tmp helyett lemezt csatlakoztat. Hiányzó legacy kulcs vagy beágyazott adatkönyvtár leállítja az indulást.

A v4 séma keyed egyenlőségi tokent ad az e-mailhez. A helyreállítás egyezést követel. Az indulás átmenetileg engedélyez hiányzó tokent hitelesített e-mail mellett a backfillhez. Az üres értékek NULL értékké válnak; a sérült envelope vagy nem null eltérés hibát okoz.

A szolgáltatások aszinkron, dialektusfüggő repository-kat használnak. A natív SQLite adapterekre, migrációra/helyreállításra és injektált healthre korlátozott. A Persistence inicializálja a runtime-ot; a PostgreSQL nem esik vissza SQLite-ra vagy cwd-beli JSON-ra.

A tartós runtime driverfüggetlen. Az actor jogosultsága az identity repository-ból származik, a natív feladatépítés az adapter határán marad, a publisherek pedig átlátszatlan executort kapnak, soha nem better-sqlite3 objektumot. A tesztek elutasítják a natív handle-öket a közös szerződésekben.

Blob- és vektortárolási alap

A Gallery média és a dokumentumforrások BlobStore, a RAG és a persona memória VectorStore szolgáltatást használ. A legacy Gallery-sorok dual-read módban olvashatók, és blobhivatkozásként kerülnek átvételre. A relációs metaadat és a tartós hivatkozás az irányadó; a szolgáltatói URL-ek és S3-kulcsok nem tárolódnak. A mellékletek és avatarok még nem migráltak.

A helyreállítás korlátozottan, sorban tanúsít minden objektum-/vektor-envelope-ot, valamint az ENCRYPTION_KEY segítségével a legacy szövegeket és hangevelope-okat, kompatibilitási fallback nélkül. Nem inicializál és nem javít. Sérült ciphertext, hibás kulcs, nem kanonikus elrendezés vagy túllépett korlát blokkol.

A korlátok: 250 000 helyi objektum, 64 GiB titkosított/nyílt blobbájt, 250 000 vektorsor, 4 GiB szerializált ciphertext és 500 millió komponens. A tesztek felülírhatják a RecoveryInventoryOptions használatával; a CLI nem mintavételez. A legacy korlát egymillió mező és 16 GiB.

Titkosított helyi blobok

A BlobStore tulajdonoshoz kötött, streamelt put/read, metadata/stat, befoglaló ranges és idempotens törlés műveletekkel. A LocalEncryptedBlobStore UUID-objektumokat ír a ${DATA_DIR}/blobs alatt staging, fsync és atomi átnevezés segítségével, 0700 könyvtár- és 0600 fájljogosultságokkal.

Minden objektumnak véletlen 256 bites adatkulcsa van. Az AES-256-GCM titkosítja a metaadatot és a chunkokat; az AAD a blobazonosítót, tulajdonost, célt, chunkindexet és hosszt köti össze. Egy verziózott kulcsgyűrű csomagolja a kulcsot. A leíró tartalmazza a méretet, SHA-256-ot, tartalomtípust, időt, verziót és kulcsazonosítót. A teljes olvasás ellenőrzi az SHA-256-ot, a tartományolvasás minden chunkot.

A kvóta streamelés előtt foglal, a tényleges bájtokat fogyasztja, és csak az atomi láthatóság után véglegesít. SQLite-nál BEGIN IMMEDIATE, PostgreSQL-nél serializable tranzakciók és lockok működnek. A BLOB_QUOTA_BYTES_PER_USER adja a korlátot, a BLOB_QUOTA_RESERVATION_TTL_MS a lejáratot.

A BLOB_STORE_BACKEND=s3 privát bucketet, átlátszatlan kulcsokat, titkosított streameket/leírókat, tartományokat, SHA-256-ot és egyeztetéssel végzett idempotens törlést használ. A MinIO-tesztek a replikák közötti működést, bérlői elszigetelést, kvóta-versenyhelyzetet és injektált hibákat fedik le.

Titkosított beágyazott vektorok

A VectorStore minden lekérdezéshez és módosításhoz actort követel. A sorok namespace-t, tenant ID-t, tulajdonost, resource ID-t, modellt, dimenziókat, verziót, revíziót, attribútumokat és grantokat tartalmaznak.

Az SQLite a metadata-/ACL-predikátumokat alkalmazza, mielőtt a ciphertext elhagyná a tárolót; csak az engedélyezett jelöltek kerülnek visszafejtésre és koszinuszos pontozásra. Az upsert atomikusan cseréli az embeddinget, ACL-t és attribútumokat. Az AES-256-GCM az identitáshoz és modellhez köti őket. A lekérdezhető metaadat nyílt, ezért nem tartalmazhat titkot.

A VECTOR_STORE_BACKEND=pgvector ugyanabban az SQL-ben alkalmazza a predikátumokat, mint a távolságot és a LIMIT értéket. A globális szomszédok utólagos szűrése tilos. A csoporttagság minden lekérdezésnél megbízható forrásból oldódik fel, a megadott groupIds figyelmen kívül marad.

Az ingestion/regeneration megváltoztathatatlan specifikációt rögzít: engedélyezés, modell, vektor-/chunkerverzió, chunkméret, átfedés és küszöb. Ugyanez irányítja a chunkokat, közzétételt, upsertet és lekérdezést. A metaadat rögzíti a revíziót és a specifikációt.

Az újragenerálás megújítható lease-t tart fenn, és a módosítás előtt és után ellenőrzi a tulajdonosi sort/tombstone-t. Az egyidejű törlés eltávolítja az újralétrehozott vektorokat. A team olvasásai nem módosítják a PGVectort. Az SQLite csak pontos manifesttel tesz közzé újra.

Az indexek 1 000-es batch-ekben cserélődnek, és a teljes manifest ellenőrződik. Egy dokumentum legfeljebb 100 000 chunkot tartalmazhat; a 100 001. embedding előtt elutasított, a feladat pedig újrapróbálás nélkül dead-lettered lesz.

A manifest előtti, modellbizonyíték nélküli vektorok az irányadó szövegből, az aktuális specifikáció és lease alatt készülnek újra. A team migráció teljes aktuális manifest és pontos titkosított index nélkül sikertelen. Futtassa solo módban ugyanazzal a DATA_DIR és ENCRYPTION_KEY értékkel, válassza ki a modellt, használja a Settings -> Documents -> Regenerate embeddings műveletet, majd futtassa újra a dry-runt.

Az SQLite az ACL után titkosítja az embeddingeket; a PGVector numerikus oszlopot igényel, amelyet az alkalmazás nem titkosít. Használjon TLS-t, titkosított köteteket/mentéseket, minimális jogosultságot és vektor-/forrástartalom nélküli naplókat. Az attribútumok nyíltak és nem tartalmazhatnak titkot.

Tárolási titkosítási kulcsok

Verziózott kulcsgyűrűvel stabil, 64 karakteres ENCRYPTION_KEY szükséges, amely megegyezik a STORAGE_ENCRYPTION_KEYS legacy kulcsával, továbbá szükséges a STORAGE_ENCRYPTION_ACTIVE_KEY_ID. Az írások az aktív, az olvasások minden kulcsot használnak. A régi kulcsokat az ellenőrzött újraírásig tartsa meg.

Térkép nélkül az ENCRYPTION_KEY lesz a legacy, vagy egy privát, szabályos ${DATA_DIR}/.encryption_key fájl olvasódik be. A factory nem hozza létre és nem cseréli le. Ütköző, hiányzó, hibás vagy ismeretlen kulcs biztonságosan lezárja a hozzáférést. A beágyazott lekérdezés visszafejtés előtt kiszámítja a jelölt-, bájt- és dimenziókeretet.

Koordináció

A szerződés eseményeket, lejáró gyorsítótárat, fenced lease-eket és rögzített ablakú rate limiteket biztosít. A helyi megvalósítás egy replikához való. A Redis külön klienseket, korlátozott payloadokat, namespace-t, atomi szkripteket, tulajdonosi tokeneket és fencinget használ, és hiba után nem esik vissza helyi működésre.

A Redis nem source of truth. A jogosultság, a tartós feladatok és a visszajátszható események az adatbázisban maradnak; a Redis ébresztésre, gyorsítótár-érvénytelenítésre, jelenlétre, kvótára és koordinációra szolgál. A kritikus mellékhatás újraellenőrzi a lease-t és fencinget.

Tartós feladatok és események

Az SQLite v3 job-, attempt-, stream- és event-táblákat biztosít idempotens enqueue, retry, megszakítás, előrehaladás, heartbeat/reclaim, dead letter és globális kurzoros replay támogatással. A titkosított JSON a kulcsgyűrűt és az identitást használja AAD-ként; a hivatkozások korlátozott, átlátszatlan ID-k.

Az SQLite v13/PostgreSQL v12 hozzáadja a (stream_id, subject_id, global_cursor) mezőket, így a szűrők a catch-up előtt futnak. A handlerek dokumentumokat, médiafolytatást és cleanupot fednek le. A létrehozás/törlés ugyanabban a tranzakcióban állít sorba feladatot, a cleanup pedig eltávolítja a vektorokat, blobokat, hivatkozásokat, gyorsítótárat és sorban álló munkát.

A helyreállítás megszámolja az állapotokat/próbálkozásokat és a folyamokat/kurzorokat, blokkolja az aktív elemeket, tanúsítja a payloadokat, és elutasítja a head-eltérést vagy szekvenciahiányt. A monoton lease-tokenek nem biztosítanak exactly-once működést; a handlereknek idempotency vagy outbox/inbox és újraellenőrzés szükséges.

Az SQLite v4 egyedi keyed HMAC-ot használ az e-mail kereséséhez a véletlen ciphertext mellett, hogy a duplikációk atomikusan kezelhetők legyenek. Induláskor tanúsítja és feltölti a legacy e-maileket.

Állapot és helyreállítás

• A /health és /health/live csak a folyamatot ellenőrzi.
• A /health/ready az adatbázist, sémát, írható tárolót és kötelező függőségeket ellenőrzi, az opcionális szolgáltatókat nem.
• A /health/deep rendszergazdai, korlátozott SQLite-integritás-/foreign-key ellenőrzést és opcionális szolgáltatói figyelmeztetéseket futtat.

Futtassa a libre-webui recovery-check --json vagy npm run recovery:check -- --json parancsot. A csak olvasható leltár jelenti a sémát/kulcsokat, blobokat, vektorokat, ciphertextet, feladatokat/eseményeket, méreteket, bővítményeket, médiát, Work-erőforrásokat/címkéket, checkpointokat, aktív futásokat, blokkolókat és kizárásokat. Ez a mentés előtti kapu. Lásd: Helyreállítási felkészültség.

Tanúsított több-replikás működés

A team legalább 3 alkalmazásreplikára és külső workerre tanúsított, ha a PostgreSQL, PGVector, Redis, S3, megosztott titkok és JOB_WORKER_MODE=external együtt vannak beállítva. A Helm teljes profil nélkül elutasít több replikát, a migráció pedig PostgreSQL advisory lockkal választ leadert.

A release valós image-dzsel futtatja az npm run test:team-platform parancsot, és teszteli a stream folytatását, a worker leállását, a replayt, a Redis-kiesést elérhető SQL mellett, a visszavonást, rate limiteket, S3-retryt és bérlői elszigetelést. A secrets.existingSecret és networkPolicy.enabled megerősíti a podokat. Alapértékek: non-root, csak olvasható gyökér, eldobott képességek, seccomp RuntimeDefault, privilege escalation nélkül.

Hátralévő átmenetek

A hanganyagok, Chat-mellékletek, avatarok és jövőbeli bináris erőforrások metadata-, dual-read/backfill-, retention- és törlési teszteket igényelnek a blobmigráció előtt. Minden embedding-hívónak a VectorStore rendszeren keresztül kell megadnia a modellt, dimenziókat, verziót, revíziót, tulajdonost, hatókört és megbízható grantokat.

Az új, hosszú mellékhatásoknak tartós célt kell regisztrálniuk, támogatniuk kell a megszakítást/retryt és a tranzakciós enqueue/outbox működést. Minden erőforrást adjon hozzá a cross-replica és backup/restore kapukhoz, mielőtt teamben engedélyezi.