Platformbasis

Libre WebUI ondersteunt een lokaal gericht profiel solo en een gedeeld profiel team. Solo gebruikt SQLite, versleutelde lokale blobs, versleutelde ingebedde vectoren, lokale coördinatie en een ingebedde duurzame worker. Team gebruikt PostgreSQL, S3-compatibele privéblobs, PGVector, Redis-coördinatie en een externe duurzame worker. Bij het starten worden gemengde profielen geweigerd, zodat status niet stilzwijgend over lokale en gedeelde backends wordt verdeeld.

Huidige mijlpaal

Gebied	Geïmplementeerde basis	Resterend werk voor aanroepers
Persistentie	SQLite- en PostgreSQL-repositories, onveranderlijke migraties, gepoolde transacties	Nieuwe domeinen moeten repositorygrenzen gebruiken
Blobs	Versleutelde lokale en S3-compatibele streamingopslag, bereiken, checksums, duurzame quota	Chatbijlagen, avatars en andere resterende inline binaire velden verplaatsen
Vectoren	Versleutelde ingebedde vectoren, PGVector-ACL's en verwijderingsveilige herbouw van documentindexen	Nieuwe embeddingaanroepers moeten hetzelfde autoriteits- en levenscycluscontract behouden
Coördinatie	Lokale en Redis-gebeurtenissen, cache, leases, snelheidslimieten, ongeldigverklaring en status	Houd Redis niet-gezaghebbend
Taken/gebeurtenissen	SQLite-/PostgreSQL-wachtrijen, transactionele gebeurtenissen, workers, nieuwe pogingen, annulering, beheer	Elk nieuw neveneffect vereist een ontwerp voor idempotentie of outbox
Bedrijfsvoering	Statuspoorten, ondertekende/versleutelde back-uparchieven, herstel naar schoon doel, verificatie	Oefen herstel en acceptatie tussen replica's voor elke implementatieomgeving

Runtimeprofielen

LIBRE_PLATFORM_MODE=solo is de standaard. Dit selecteert SQLite, lokale blobs, ingebedde vectoren, lokale coördinatie en de ingebedde duurzame worker. Redis kan in solomodus worden gekozen, maar dit maakt SQLite of lokale bestanden niet veilig om tussen replica's te delen.

LIBRE_PLATFORM_MODE=team vereist alle gedeelde afhankelijkheden tegelijk:

• DATABASE_BACKEND=postgres met DATABASE_URL;
• BLOB_STORE_BACKEND=s3;
• VECTOR_STORE_BACKEND=pgvector;
• COORDINATION_BACKEND=redis met REDIS_URL; en
• JOB_WORKER_MODE=external.

Deze kiezers vormen één samenhangend geheel. Het starten van team mislukt wanneer een gedeelde afhankelijkheid ontbreekt of een lokale backend in het profiel is gemengd.

Een bestaande solo-installatie migreren

Stop vóór de migratie elke Libre-applicatie en worker. De voorbeelden gebruiken de geïnstalleerde opdracht libre-webui uit algemene npm of Homebrew. Vervang deze zonder algemene installatie door npx --yes libre-webui@latest. Bouw vanuit een broncheckout eenmaal en vervang libre-webui migrate-postgres door npm run migrate:postgres --. Configureer de doelomgeving voor PostgreSQL, S3 en geversioneerde versleutelingssleutels precies als de teamimplementatie van het doel. Voer daarna eerst de alleen-lezen analyse uit:

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

Pas alleen toe op het lege doel dat dit rapport identificeert. Een mislukte uitvoering laat een importlogboek met checksums achter; hervat dezelfde bron en hetzelfde doel in plaats van een niet-gerelateerde import te starten:

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

De voltooiingsmarkering wordt pas aangebracht nadat relationele rijen, plug-indefinities, lokale versleutelde blobs, ingebedde vectoren en verouderde personavectoren allemaal zijn overgebracht en in PostgreSQL/S3/PGVector zijn geauthenticeerd. De opdracht verzint nooit een bronversleutelingssleutel: ENCRYPTION_KEY moet overeenkomen met de bron-.encryption_key en STORAGE_ENCRYPTION_KEYS moet de geconfigureerde actieve sleutel plus de overeenkomende vermelding legacy bevatten.

Het meegeleverde teamprofiel uitvoeren

Begin met het meegeleverde sjabloon dat gesloten faalt. Bewaar het ingevulde omgevingsbestand buiten de repository en beperk de toegang tot de beheerder:

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

Vervang vóór het starten elke waarde REPLACE_*. Genereer het PostgreSQL-wachtwoord met een URL-veilig alfabet (bijvoorbeeld openssl rand -hex 32), omdat dezelfde letterlijke waarde zowel het serverwachtwoord als onderdeel van DATABASE_URL is. ENCRYPTION_KEY en elke waarde in STORAGE_ENCRYPTION_KEYS moeten exact 64 hexadecimale tekens bevatten. Bij een nieuwe installatie moet de vermelding legacy gelijk zijn aan ENCRYPTION_KEY; bij SQLite-migratie moeten beide gelijk zijn aan de bronsleutel. Gebruik een andere actieve sleutel voor nieuwe blobschrijfacties en bewaar oude sleutels totdat de objectinventaris bewijst dat ze niet meer worden gebruikt.

Hetzelfde bestand kan POSTGRES_MIGRATION_MODE, POSTGRES_POOL_MAX, de ondersteunde PostgreSQL-time-outs, REDIS_CONNECT_TIMEOUT_MS, OLLAMA_BASE_URL, OLLAMA_TIMEOUT, OLLAMA_LONG_OPERATION_TIMEOUT en OLLAMA_MAX_CONTEXT instellen; de gedeelde Compose-omgeving verstuurt elke waarde identiek naar de applicatie en externe worker. De providertime-outs accepteren 1.000-3.600.000 milliseconden, maximale context accepteert 128-2.097.152 tokens en de lange time-out mag niet korter zijn dan de standaardtime-out; misvormde waarden laten beide serveringangen falen voordat status wordt gemaakt. Node-lokale Agent CLI-binaire bestanden en Codex OAuth-tokenbestanden worden niet door externe duurzame workers ondersteund. Het teamprofiel zet daarom beide providerpaden vast op uit en weigert bij het starten pogingen om ze in te schakelen. Start daarna de applicatiereplica's, externe duurzame worker, PostgreSQL/PGVector, Redis, geversioneerde MinIO-bucket en gateway:

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

Het basisteamprofiel koppelt bewust geen Docker-socket, waardoor Docker-gebaseerde Work niet beschikbaar is. Schakel deze alleen in door de meegeleverde productie-overlay in elke levenscyclusopdracht op te nemen:

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

Die overlay richt zowel applicatie- als workerprocessen op één gefilterde Docker-socketproxy op een uitsluitend intern netwerk. Geen van beide processen ontvangt de onbewerkte socket of lidmaatschap van de socketgroep en Work-werkruimten in hostmappen blijven uitgeschakeld. De proxy biedt alleen info, images, containers, exec, volumes, netwerken en de schrijfmethoden die deze levenscyclusoproepen vereisen. Dit verkleint het API-oppervlak, maar maakt Docker geen tenantgrens: het maken van containers kan nog steeds hostpaden bind-mounten. Gebruik een afzonderlijke virtuele machine of rootloze/afzonderlijke Work-daemon wanneer hostisolatie belangrijk is.

Stel de door Compose beheerde PostgreSQL-, Redis- of MinIO-diensten niet rechtstreeks bloot. Gebruik voor beheerde afhankelijkheden het Helm-teamprofiel en behoud geverifieerde TLS; het Compose-bestand schakelt PostgreSQL-TLS alleen op het particuliere projectnetwerk uit. Readiness blijft mislukt totdat een externe worker aanwezig is.

Persistentie- en migratiegrens

Identiteit en autorisatie gebruiken nu asynchrone repositories. De transactiecallback van de repository ontvangt een werkeenheid die aan dezelfde databaseverbinding is gebonden; het gebruik van de algemene repository vanuit die callback wordt geweigerd. Dit is de transactiegrens die de PostgreSQL-verbindingspool gebruikt, met behoud van het huidige SQLite-gedrag.

De SQLite-migratiecoördinator neemt bestaande installaties pas over nadat het vereiste schema is gevalideerd. Hij registreert een genummerde migratienaam en checksum, controleert deze bij elke start, weigert nieuwere/onbekende/afwijkende logboeken en laat het starten mislukken wanneer migratie- of schemavalidatie faalt. Readiness en de herstelinventaris gebruiken hetzelfde canonieke inspectiecontract.

Voordat applicatiediensten met status worden geïmporteerd, kopieert het opstartproces de bestaande SQLite-database en actieve WAL-/SHM-bestanden naar een particuliere tijdelijke map en valideert die kopie. PLATFORM_PREFLIGHT_TMP_DIR moet voldoende vrije ruimte hebben voor de database plus de WAL. De meegeleverde Docker- en Helm-implementaties koppelen daar speciaal schijfgebaseerde tijdelijke opslag; het starten vertrouwt niet op de begrensde tmpfs /tmp. Een ontbrekende verouderde versleutelingssleutel of historische geneste gegevensmap blokkeert het starten voordat een vervangende sleutel, database of plug-instatus kan worden gemaakt.

Schema v4 voegt een sleutelgebonden gelijkheidstoken toe voor versleutelde identiteits-e-mails. Herstel vereist dat elk token aanwezig is en met de geauthenticeerde e-mail overeenkomt. Tijdens het korte crashvenster nadat v4 commit, staat het starten een ontbrekend token bij een geauthenticeerde e-mail of een verouderde waarde zonder envelop toe, zodat repository-initialisatie het aanvullen van versleuteling/tokens kan voltooien. Oudere releases accepteerden willekeurige e-mailtekenreeksen en gebruikten lege waarden om het veld te wissen; overname behoudt niet-lege waarden en normaliseert lege naar NULL. Beschadigde waarden met de vorm van een envelop en elke niet-null-afwijking laten de voorafgaande controle nog steeds mislukken.

Applicatiediensten gebruiken asynchrone dialectrepositories. Native SQLite is beperkt tot SQLite-adapters, migratie-/herstelinspectie en expliciet geïnjecteerde statuscontroles. Runtimeopslag wordt vanuit de gekozen Persistence geïnitialiseerd; activering van PostgreSQL valt nooit terug op de SQLite-singleton of historische JSON-bestanden die van de huidige werkmap afhangen.

De algemene runtime voor duurzame taken blijft eveneens driverneutraal. Actorautorisatie wordt via de gekozen identiteitsrepository gelezen, terwijl het maken van een native taakrepository tot één adapter-samenstellingsgrens is beperkt. Transactionele domeinpubliceerders ontvangen in SQLite een ondoorzichtige synchrone executor en in PostgreSQL een transactiegebonden executor; ze ontvangen nooit een better-sqlite3-handle. De persistentiegrenstest weigert native driverhandles in algemene contracten voor taken, resources, identiteit, chat en Work.

Basis voor blob- en vectoropslag

Gegenereerde galerijmedia en documentbronbestanden gebruiken BlobStore; document-RAG en personageheugen gebruiken VectorStore. Verouderde SQLite-galerijrijen worden dubbel gelezen en bij eerste toegang in blobreferenties overgenomen. Relationele metadata en een duurzame referentie zijn gezaghebbend; provider-URL's en fysieke S3-sleutels worden nooit als applicatie-inhoud bewaard. Chatbijlagen, avatars en andere resterende inline binaire velden zijn nog geen aanroepers van de blobopslag en mogen niet als gemigreerd worden beschreven.

De herstelpoort authenticeert elk duurzaam object en elke ingebedde vectorenvelop achtereenvolgens onder expliciete totaallimieten. Ook herkenbare verouderde tekstenveloppen en elke binaire envelop voor opgeslagen stemmen worden strikt met de applicatie-ENCRYPTION_KEY geauthenticeerd; de compatibiliteitsfallback van de runtime die ontsleutelt en het origineel retourneert, wordt nooit gebruikt. De bronopslag wordt niet geïnitialiseerd, gerepareerd, herschreven of verwijderd; beschadigde ciphertekst, onbekende of onjuiste sleutels, niet-canonieke blobindelingen en overschreden controlelimieten blokkeren de momentopname.

De standaardherstelgrenzen zijn 250.000 lokale objecten, 64 GiB aan versleutelde en plattetekst-blobbytes, 250.000 vectorrijen, 4 GiB aan geserialiseerde vectorciphertekst en 500 miljoen vectorcomponenten. Tests en ingebedde aanroepers kunnen limieten per uitvoering via RecoveryInventoryOptions overschrijven; de CLI neemt nooit stilzwijgend monsters en slaat overtollige status nooit over.

Validatie van verouderde ciphertekst gebruikt standaard maximaal één miljoen ingevulde kandidaatvelden en telkens 16 GiB aan totale opgeslagen en geauthenticeerde plattetekstbytes. Plattetekstrijen uit oude schemageneraties blijven compatibel omdat verouderde tekstenveloppen geen duurzame markering hebben; het rapport telt alleen geauthenticeerde enveloppen. Enveloppen voor opgeslagen stemmen zijn ondubbelzinnig en authenticeren altijd met profiel-/eigenaar-/veldidentiteit als aanvullende gegevens.

Versleutelde lokale blobs

BlobStore is aan een eigenaar gebonden en biedt streaming put/read, metadata/stat, inclusieve bytebereiken en idempotent verwijderen. LocalEncryptedBlobStore schrijft ondoorzichtige objecten met UUID-sleutels onder een door de applicatie geleverde hoofdmap; het integratiedoel is ${DATA_DIR}/blobs. Het gebruikt exclusieve tijdelijke bestanden, fsync en een atomaire hernoeming binnen hetzelfde bestandssysteem, met 0700 voor mappen en 0600 voor bestanden.

Elk object heeft een willekeurige 256-bits gegevenssleutel. AES-256-GCM versleutelt particuliere metadata en authenticeert begrensde lichaamsdelen onafhankelijk. Aanvullende geauthenticeerde gegevens binden de blob-ID, eigenaar, het doel, de deelindex en plattetekstlengte. De geversioneerde opslagsleutelring verpakt elke gegevenssleutel. De descriptor registreert plattetekstgrootte, SHA-256, inhoudstype, aanmaaktijd, indelingsversie en versleutelingssleutel-ID. Volledige leesacties controleren SHA-256; bereikleesacties authenticeren elk geraakt deel.

Het quotumcontract reserveert capaciteit vóór het streamen, verbruikt werkelijke bytes, commit pas na atomaire zichtbaarheid en geeft mislukte reserveringen vrij. SQLite gebruikt BEGIN IMMEDIATE; PostgreSQL gebruikt serialiseerbare transacties en rijvergrendelingen. S3-objectmetadata en quotumgebruik worden in één databasetransactie gecommit of teruggedraaid. Bij het starten worden verlopen reserveringen en quotumobjecten waarvan de fysieke blob ontbreekt, in overeenstemming gebracht. BLOB_QUOTA_BYTES_PER_USER stelt de duurzame limiet per eigenaar in en BLOB_QUOTA_RESERVATION_TTL_MS begrenst verlaten reserveringen.

BLOB_STORE_BACKEND=s3 gebruikt een particuliere S3-compatibele bucket. Libre uploadt ondoorzichtige objectsleutels en door de applicatie versleutelde deelstromen, bewaart versleutelde descriptors in PostgreSQL, ondersteunt inclusieve HTTP-bereiken, controleert SHA-256-digests van platte tekst en ciphertekst en verwijdert idempotent. Een rij met verwijderstatus blijft duurzaam totdat fysieke verwijdering en atomaire verwijdering van metadata/quotum slagen; afstemming probeert onderbroken verwijderingen opnieuw en verwijdert verouderde fysieke weesobjecten. De door Docker afgedwongen MinIO-suite dekt lezen/verwijderen tussen replica's, tenantisolatie, quotumconflicten, niet-verbruikte stromen en geïnjecteerde databasefouten op commit- en verwijdergrenzen.

Versleutelde ingebedde vectoren

VectorStore vereist bij elke query en mutatie een actor. Records bevatten een naamruimte, ondoorzichtige tenantgebonden ID, eigenaar, resource-ID, embeddingmodel, dimensies, versie, bronrevisie, gelijkheidsattributen en optionele gebruikers-/groepstoekenningen.

SQLite past naamruimte/model/dimensie/versie, eigenaar of toekenning, resource en attribuutpredicaten toe voordat versleutelde embeddings de database verlaten. Alleen die begrensde, geautoriseerde kandidatenset wordt ontsleuteld en met cosinus gescoord. Dezelfde ondoorzichtige vector-ID is per eigenaar geïsoleerd zonder het bestaan van een andere tenant te onthullen. Upserts vervangen embeddings, ACL's en attributen atomair; verwijderingen zijn aan de eigenaar gebonden en verwijderen gerelateerde rijen trapsgewijs.

Embeddings gebruiken AES-256-GCM met identiteit en modelmetadata als aanvullende geauthenticeerde gegevens. Opvraagbare identiteit, toekenning, model, versie, revisie en filtermetadata blijven platte tekst; aanroepers mogen daarom geen geheimen in filterattributen zetten. Embeddings zelf zijn gevoelige afgeleide gegevens.

VECTOR_STORE_BACKEND=pgvector past naamruimte, model, dimensies, versie, resource, attribuut, eigenaar en toekenningspredicaten toe in hetzelfde SQL-statement als afstandsordening en LIMIT. Achteraf filteren van algemene dichtstbijzijnde buren is verboden. Groepsautorisatie wordt voor elke query herleid vanuit een vertrouwde actuele-lidmaatschapsresolver; door de aanroeper geleverde groupIds worden genegeerd. Intrekking is daardoor onmiddellijk en vervalste groepsclaims kunnen geen kandidaten ophalen.

Documentopname en het onderhoudseindpunt voor het opnieuw genereren van embeddings leggen vóór het begin van het werk één onveranderlijke uitvoeringsspecificatie vast: ingeschakelde status, model, vectorversie, chunkerversie, deelgrootte, overlap en gelijkenisdrempel. Dezelfde specificatie bestuurt deelgeneratie, relationele publicatie, vectorupsert en semantische query; een voorkeurswijziging tijdens een uitvoering kan geen delen met verschillende modellen produceren of een vector onder een andere drempel opvragen. De gepubliceerde documentmetadata registreert de gezamenlijke deelrevisie en deze specificatie, zodat SQL het gezaghebbende indexmanifest blijft.

Regeneratie houdt voor elk document een automatisch verlengende coördinatorlease vast en controleert de eigenaarsgebonden rij plus de permanente verwijderingstombstone opnieuw vóór relationele publicatie en vóór en na vectormutatie. Een verwijdering kan committen terwijl een upsert bezig is; de autoriteitscontrole na de upsert verwijdert dan de opnieuw gemaakte vectoren. Semantische leesacties van PostgreSQL/team muteren PGVector nooit. SQLite kan relationele embeddings alleen traag opnieuw publiceren wanneer het opgeslagen manifest exact het huidige model en de huidige deelconfiguratie bewijst; die optionele mutatie laadt de rij en delen opnieuw terwijl dezelfde documentlease wordt vastgehouden. Een drukke of vervangen revisie wordt overgeslagen en blijft geschikt voor trefwoordfallback of expliciete regeneratie.

Documentindexen worden vervangen in gecompenseerde batches van maximaal 1.000 vectoren. Exacte-indexcontroles bladeren door het volledige resourcemanifest in plaats van aan te nemen dat één mutatiebatch het hele document vormt. Een document mag maximaal 100.000 delen publiceren, zodat geen enkel document het totale documentdelenplafond van het draagbare archief overschrijdt. Opname weigert het 100.001e deel vóór embedding of relationele/vectorpublicatie en plaatst die duurzame taak zonder nieuwe poging in de dead-letterwachtrij; verhoog de embeddingdeelgrootte of verwijder overmatige alinea-einden voordat u opnieuw uploadt.

Solodatabases van vóór het manifest kunnen geauthenticeerde inline documentvectoren bevatten zonder registratie van het model of de chunker waarmee ze zijn gemaakt. Bij het eerste semantische gebruik geldt alleen hun aanwezigheid als upgradesignaal: gezaghebbende documenttekst wordt opnieuw opgedeeld en elke vector onder de huidige vastgelegde specificatie opnieuw gegenereerd terwijl de documentlease wordt vastgehouden. De verouderde payload wordt nooit gekopieerd of met de huidige voorkeur gelabeld. Een providerfout of drukke lease laat de verouderde rij ongewijzigd en doorzoekbaar op trefwoorden.

Migratie van SQLite naar team faalt gesloten wanneer zo'n verouderd document niet volledig wordt gedekt door geauthenticeerde actuele manifestmetadata en een exacte versleutelde platformvectorindex. Huidige voorkeuren bewijzen niet het model van een historische vector. Wanneer de droge proef deze blokkade meldt, start u de huidige release in solo-/SQLite-modus met dezelfde DATA_DIR en ENCRYPTION_KEY, schakelt u het gewenste embeddingmodel in en selecteert u het, gebruikt u Settings -> Documents -> Regenerate embeddings voor elke betrokken eigenaar en voert u de droge migratieproef opnieuw uit. Pas daarna mogen teamrepositoryleesacties de bewaarde inline ciphertekst negeren terwijl de bewezen vectoren naar PGVector gaan.

Vertrouwelijkheid verschilt per backend. Ingebedde SQLite versleutelt embeddings met applicatie-AES-256-GCM nadat metadata-ACL-predicaten zijn toegepast. PGVector moet op de numerieke embedding werken en versleutelt die kolom daarom niet op applicatieniveau. Behandel embeddings als gevoelige afgeleide gegevens: vereis TLS, versleutelde PostgreSQL-volumes en -back-ups, een applicatierol met minimale rechten, beperkt databasebeheer en SQL-logboeken die nooit vector- of broninhoud bevatten. Brontekst, inhoud van personageheugen, galerijmetadata en blobdescriptors blijven via enveloppen versleuteld. Vectorattributen zijn opvraagbare platte tekst en mogen nooit geheimen bevatten.

Versleutelingssleutels voor opslag

Tijdens de huidige migratieperiode voor aanroepers moeten implementaties die een geversioneerde sleutelring inschakelen een stabiele ENCRYPTION_KEY van 64 tekens instellen, dezelfde sleutel onder de exacte vermelding legacy in STORAGE_ENCRYPTION_KEYS opnemen en STORAGE_ENCRYPTION_ACTIVE_KEY_ID op één vermelding instellen. Schrijfacties gebruiken de actieve sleutel; leesacties accepteren alle geconfigureerde sleutel-ID's voor gefaseerde rotatie. Deze tijdelijke verouderde vereiste voorkomt dat de bestaande versleutelingsdienst zelfstandig een andere sleutel maakt. Bewaar oude sleutels totdat elk object en elke vector is herschreven of opnieuw verpakt en gecontroleerd.

Wanneer die toewijzing ontbreekt, accepteert de adapter de bestaande ENCRYPTION_KEY van 64 tekens als sleutel-ID legacy, of leest hij het bestaande bestand ${DATA_DIR}/.encryption_key wanneer de omgevingssleutel ontbreekt. De opslagfactory accepteert alleen een regulier, niet-symbolisch gekoppeld sleutelbestand met particuliere rechten; hij maakt, herschrijft of vervangt dat bestand nooit. Als expliciete omgevingsconfiguratie conflicteert met de permanente sleutel, faalt het starten gesloten. Tijdens rotatie moet een gedetecteerde verouderde omgevings-/bestandssleutel onder de exacte sleutel-ID legacy in de geversioneerde toewijzing blijven totdat oude enveloppen zijn herschreven en gecontroleerd. Ontbrekende, misvormde, afwijkende en onbekende sleutels falen gesloten.

Ingebedde vectorquery's passen ACL- en metadatapredicaten in SQLite toe en aggregeren daarna het aantal kandidaten, versleutelde bytes en scoringswerk per dimensie voordat ciphertekst aan Node wordt geretourneerd voor ontsleuteling. Query's die een budget overschrijden, falen gesloten en moeten via resource- of metadatabereik worden versmald.

Coördinatie

Het coördinatorcontract biedt gebeurtenissen, cachevermeldingen met vervaldatum, afgeschermde leases en verbruik van snelheidslimieten met een vast venster. De lokale implementatie is alleen bestemd voor het soloprofiel met één replica. De Redis-implementatie gebruikt afzonderlijke clients voor opdrachten en abonnementen, begrensde payloads, statuscontroles, sleutelnaamruimten, atomaire scripts, unieke eigenaarstokens, leaseverval en afschermingstokens. Na een Redis-fout valt deze nooit terug op lokale coördinatie.

Redis is niet de bron van waarheid. Autorisatie, duurzame taken en opnieuw afspeelbare gebeurtenissen moeten in de database blijven; Redis is een laag voor wake-up, cache-ongeldigverklaring, aanwezigheid, quota en coördinatie. Kritiek werk moet vóór het committen van een neveneffect ook de databaselease of het afschermingstoken controleren.

Applicatietickets, caches, gedeelde ongeldigverklaring, verbindingslimieten, Work-gebeurtenissen en gedistribueerde runtimevergrendelingen gebruiken deze grens. Alleen Redis selecteren maakt lokale persistentie nog steeds niet deelbaar; teammodus vereist het volledige gedeelde profiel.

Duurzame taken en gebeurtenissen

SQLite-migratie v3 biedt tabellen voor duurzame taken, pogingen, koppen van gebeurtenisstromen en geordende gebeurtenissen. Het dienstcontract ondersteunt idempotent in de wachtrij plaatsen, begrensde nieuwe pogingen, annulering, voortgang, leasehartslag/-terugvordering, dead-letterstatus en opnieuw afspelen via een algemene cursor. Versleutelde JSON-payloads gebruiken de platformsleutelring met taak-/gebeurtenisidentiteit als geauthenticeerde gegevens; payloadreferenties zijn ondoorzichtige begrensde ID's.

SQLite-migratie v13 en PostgreSQL-migratie v12 voegen de overeenkomende index (stream_id, subject_id, global_cursor) toe die door generatiegebonden chatreplay wordt gebruikt. Stroom- en onderwerpfilters worden vóór de inhaallimiet toegepast, zodat eerdere generaties van een lange sessie noch het replaybudget van de huidige generatie verbruiken, noch een volledige scan van de gebeurtenisstroom afdwingen.

De opstartprocessen van applicatie en zelfstandige worker registreren gecontroleerde handlers voor documentopname, mediavervolg en opnieuw te proberen resourceopschoning. De beheerdersgrens biedt begrensde inspectie en annulering. In de wachtrij plaatsen is idempotent en relationele aanmaak-/verwijderpaden voegen hun duurzame taak in dezelfde SQLite-/PostgreSQL-transactie in. Resourceopschoning verwijdert vectoren, privéblobs, duurzame referenties, cachevermeldingen en resourcegerichte taken in de wachtrij via bewerkingen die veilig opnieuw kunnen worden geprobeerd.

De herstelinventaris telt elke taakstatus en poginguitkomst, registreert gebeurtenisstromen en hun laatste cursor, blokkeert onveilig actief werk en authenticeert versleutelde payloads onder totaallimieten. Herstel weigert ook afwijkende stroomkoppen en niet-aaneengesloten reeksen per stroom.

Monotone leasetokens schermen verouderde workers af van latere databasecommits. Afscherming biedt geen precies-eenmaal-uitvoering: een worker kan een extern neveneffect voltooien en falen voordat succes wordt geregistreerd. Het overnemen van handlers vereist daarom idempotentiesleutels van providers of een transactioneel outbox-/inboxprotocol, plus hernieuwde validatie van actorautorisatie onmiddellijk vóór elk neveneffect.

SQLite-migratie v4 voegt naast willekeurige identiteitsciphertekst een uniek sleutelgebonden e-mailzoektoken toe. Het token is een HMAC onder de applicatieversleutelingssleutel: het herstelt atomaire afdwinging van dubbele e-mails zonder platte tekst op te slaan of deterministische versleuteling te gebruiken. Bij het starten wordt elke verouderde identiteits-e-mail geauthenticeerd en aangevuld voordat verkeer wordt geaccepteerd.

Status en herstel

Implementatieprobes onderscheiden nu proces-liveness van afhankelijkheids-readiness:

• /health en /health/live zijn uitsluitend voor het proces;
• /health/ready controleert de database, het canonieke schemalogboek, schrijfbare gegevensopslag en geregistreerde vereiste afhankelijkheden terwijl details worden afgeschermd. Het wacht niet op optionele providers; en
• /health/deep vereist een huidige beheerder en voert SQLite-integriteits- en vreemde-sleutelcontroles uit in een begrensde worker buiten de HTTP-gebeurtenislus. Ook voegt het optionele providerprobes op serverniveau, zoals Ollama, als waarschuwingen samen zonder de kern-readiness te wijzigen.

Voer libre-webui recovery-check --json uit; bouw vanuit een broncheckout de backend eenmaal en gebruik npm run recovery:check -- --json. De inventaris is alleen-lezen en rapporteert schema-/sleutelidentiteiten, de lokale blobhoofdmap, aantallen verouderde en platformvectoren, authenticeert lokale platformblob-/vectorciphertekst, verouderde applicatie- en opgeslagen-stemciphertekst en versleutelde duurzame taak-/gebeurtenispayloads en rapporteert gegevensgrootten, plug-indefinities en of deze binnen de back-uphoofdmap staan, ingebedde media, Work-resources en exacte eigendomslabels, taak-/poging-/gebeurteniscontrolepunten, actieve Work-uitvoeringen/-voorbeelden en taken, blokkades en bekende uitsluitingen. Het is een poort vóór de back-up, geen volledige back-up. Zie Herstelgereedheid.

Gecertificeerde werking met meerdere replica's

Het teamprofiel is gecertificeerd voor drie of meer applicatiereplica's plus minstens één externe duurzame worker, mits elke gedeelde afhankelijkheid samen is geconfigureerd: PostgreSQL, PGVector, Redis, S3-compatibele blobs, stabiele gedeelde geheimen en JOB_WORKER_MODE=external. De Helm-chart dwingt die vereisten tijdens rendering af: een replicaaantal boven één zonder het volledige teamprofiel laat de rendering mislukken in plaats van een onveilige topologie te implementeren. Schemamigraties kiezen via een PostgreSQL-advisory lock één leider, zodat replica's met verschillende versies nooit om het logboek wedijveren.

Certificering is uitvoerbaar, niet alleen een streven: de releasepijplijn voert een oefening met drie replica's uit (npm run test:team-platform) die de werkelijke image bouwt en het hervatten van stromen tussen replica's, uitval van een worker tijdens schrijven met deterministische replay, Redis-uitval met terugval op gezaghebbende SQL, afdwinging van intrekking tijdens verlies van de coördinator, consistentie van gedeelde snelheidslimieten, nieuwe pogingen voor S3-verwijdering en tenantisolatie onder belasting test. Beheerders kunnen de pods verder versterken met secrets.existingSecret (verwijs naar een door de beheerder beheerd Secret in plaats van chartwaarden erin te renderen) en networkPolicy.enabled (standaard alle inkomende verbindingen weigeren behalve de applicatiepoort; de duurzame worker accepteert geen inkomende verbindingen). Standaardinstellingen voor podbeveiliging blijven hoe dan ook streng: zonder root, alleen-lezen hoofdbestandssysteem, verwijderde capabilities, seccomp RuntimeDefault en geen bevoegdheidsverhoging.

Bekende resterende omschakelingen

De basis betekent niet dat elk binair veld al een blob is. Audio van opgeslagen stemmen, chatbijlagen, avatars en toekomstige door plug-ins gedefinieerde binaire resources hebben expliciete referentiemetadata, dubbel lezen/aanvullen, retentie- en verwijdertests nodig voordat ze kunnen worden verplaatst. Evenzo moet elke toekomstige embeddingaanroeper model, dimensies, versie, bronrevisie, eigenaar, resourcebereik en vertrouwde toekenningen via VectorStore meenemen; rechtstreekse toegang tot de vectortabel is geen geaccepteerde sluiproute.

Nieuwe langdurige of extern zichtbare neveneffecten moeten een duurzaam resourcedoel registreren, annulering en nieuwe pogingen ondersteunen en een transactionele wachtrij-/outboxgrens gebruiken met de bijbehorende relationele mutatie. Voeg elke nieuwe resource toe aan de acceptatiepoorten voor upload/lezen/zoeken/verwijderen tussen replica's en back-up/herstel voordat u haar in teamimplementaties inschakelt.