Driftalternativ

Intric erbjuder tre huvudsakliga driftsalternativ för att möta olika krav på säkerhet, datakontroll och infrastruktur. Oavsett vilket alternativ som väljs sker all kommunikation (både mellan webbserver och applikation samt till externa tjänster) krypterat via SSL/TLS.

Multi-tenant Cloud

Multi-tenant är den vanligaste driftsformen för Intric, där resurser nyttjas på ett effektivt sätt för att leverera en stabil och kostnadseffektiv tjänst. I denna lösning delar flera kunder på applikationsservern och databasen, men data hålls strikt åtskild genom logisk separation. Lösningen driftas på virtuella servrar hos Glesys AB, som är ISO 27001-certifierade, och all datalagring sker säkert i deras hallar.

Det här alternativet passar organisationer som vill ha en smidig och underhållsfri lösning utan att behöva hantera egen infrastruktur.

Dedikerad instans Cloud

För organisationer som har högre krav på isolering men fortfarande vill dra nytta av molnets fördelar, erbjuder vi dedikerad instans. Här tilldelas varje kund en helt egen, isolerad databas, trots att de ligger på en gemensam serverinfrastruktur. Detta garanterar att er data aldrig blandas fysiskt med andra kunders data i databaslagret, vilket ger en extra nivå av trygghet. Precis som med Multi-tenant-lösningen sker driften på virtuella servrar hos Glesys AB.

On-prem Managed

On-prem Managed är alternativet för organisationer med mycket strikta säkerhetskrav, där data enligt policy måste stanna inom den egna IT-miljön. I detta fall installeras och körs Intric lokalt på er egen server, och plattformen är som standard endast åtkomlig inifrån ert interna nätverk. Detta ger er full kontroll över både hårdvara och dataflöden. Externa tjänster nås endast om ni specifikt öppnar för dem i er brandvägg, enligt instruktionerna under avsnittet om Språkmodeller.

Som ett komplement till detta alternativ finns även möjligheten att installera lokala GPU:er. Genom att göra detta kan ni köra även själva språkmodellerna lokalt i er serverhall. Detta minimerar, eller i vissa fall helt eliminerar, behovet av externa API-anrop, vilket skapar en helt sluten miljö för maximal säkerhet och integritet.

Intrics arkitektur

Intric är inte ett enda program utan en uppsättning samverkande tjänster, var och en med ett tydligt ansvar:

Webbapplikation (frontend): Gränssnittet användarna arbetar i. Renderas på servern för snabba laddtider och levereras över HTTPS.
API och bakgrundsarbetare (backend): Plattformens kärna — behörigheter, spaces, assistenter, kunskap och all affärslogik. En separat bakgrundsarbetare hanterar långvariga jobb så att gränssnittet förblir responsivt.
Identitetsleverantör: All inloggning sker via OpenID Connect (OIDC). Intric levereras med en inbyggd identitetsleverantör (Zitadel), eller ansluts till den er organisation redan använder, till exempel Microsoft Entra ID.
Datalager: PostgreSQL (med tillägget pgvector) är primär databas och vektorlager, Redis hanterar cache och jobbköer, och ett S3-kompatibelt objektlager lagrar uppladdade filer. En dedikerad vektordatabas (Weaviate) kan aktiveras för stora kunskapsbaser.
Bearbetningstjänster: En meddelandekö (RabbitMQ) matar specialiserade arbetare för dokumentinläsning, PDF-förbearbetning med OCR och ljudtranskribering. En sandlåda kör användargenererad kod i isolerade jobb utan särskilda rättigheter. Dessa arbetare skalas oberoende av kärnapplikationen — se Server och Hårdvara för dimensionering.

 webbläsare ──HTTPS──> frontend <──> backend (API + arbetare)
                                        │
                       ┌────────┬───────┼──────────┐
                       v        v       v          v
                   PostgreSQL Redis  objekt-    identitets-
                   (pgvector)        lager      leverantör
                                        │
                                        v  signerade JWT:er
                                 meddelandekö ──> bearbetningsarbetare
                                                  (dokument, PDF/OCR,
                                                   transkribering, sandlåda)

All intern trafik är krypterad, och tjänsterna autentiserar sig mot varandra med signerade tokens — bearbetningslagret litar aldrig på en förfrågan det inte kan verifiera.

Drift på Kubernetes med Helm

Alla on-prem-installationer av Intric körs på Kubernetes — det är så plattformen levereras. Den paketeras som två Helm-charts, publicerade som OCI-paket från ghcr.io/inoolabs/charts:

intric-helm — applikationslagret: frontend, backend, identitetsleverantör och alla datalager. Varje medföljande datalager är valfritt; vart och ett kan stängas av till förmån för infrastruktur ni redan driftar (ett befintligt PostgreSQL-kluster, Redis, S3-endpoint eller identitetsleverantör).
intric-services — bearbetningslagret: meddelandekö samt dokument-, PDF- och transkriberingsarbetarna.

Vad ert plattformsteam behöver tillhandahålla:

Kubernetes 1.29 eller senare och Helm 3.8 eller senare.
En ingress-controller, en standard-StorageClass, TLS-certifikat och DNS-poster för applikationens värdnamn.
Uppgifter för att hämta Intrics container-images.

Installationen följer vanlig Kubernetes-praxis: skriv en values-fil som beskriver er miljö, installera charterna och genomför en engångs-bootstrap som skapar den första organisationen och administratören. Uppgraderingar är vanliga Helm-uppgraderingar. GitOps-arbetsflöden (till exempel ArgoCD) stöds fullt ut, liksom helt isolerade miljöer — alla images kan speglas till ett privat registry, och utgående trafik kan gå via en proxy.

Bearbetningsarbetarna kan skalas automatiskt utifrån kölängd (via KEDA), så att kapaciteten följer er faktiska dokument- och ljudvolym i stället för att vara fast.

En komplett konfigurationsreferens medföljer själva charterna.

Observerbarhet

Intric är byggt för att kopplas in i den övervakningsmiljö ni redan kör:

OpenTelemetry: Plattformen exporterar traces, metrics och loggar över OTLP/HTTP till en collector ni pekar ut — kompatibelt med Grafana, Prometheus, Loki, Tempo, Elastic och andra OpenTelemetry-baserade miljöer.
Felrapportering: Valfri Sentry-integration för applikationsfel, avstängd som standard.
Miljömärkning: Telemetri märks per miljö (till exempel staging eller produktion) så att signaler hålls åtskilda mellan installationer.
Loggar: Alla komponenter skriver strukturerade loggar till standard output, med konfigurerbar loggnivå, redo för den loggpipeline ert kluster använder.
Integritetsmedveten som standard: Anrop till språkmodeller spåras för svarstider och fel utan att promptinnehåll registreras, och felrapporter rensas från användarfrågor och inloggningsuppgifter innan de lämnar plattformen.

Vad som kan anpassas

Allt nedan bestäms per installation — inga kodändringar krävs. Detta är den icke-tekniska kartan över valen; de tekniska detaljerna finns i chart-dokumentationen.

Område	Vad ni bestämmer
Inloggning och identitet	Använd den inbyggda identitetsleverantören eller er egen (valfri OIDC-leverantör, till exempel Microsoft Entra ID). Hur användare får åtkomst: personliga inbjudningar, automatisk provisionering vid första inloggning, eller självregistrering. Gruppmedlemskap kan synkas från er katalogtjänst.
AI-modeller	Vilka språkmodellsleverantörer som är tillgängliga: OpenAI, Anthropic, Azure OpenAI, Google Gemini, AWS Bedrock, Mistral, Berget, OVHcloud, Intrics EU-hostade modeller — eller era egna självhostade modeller, inklusive helt lokala modeller på egna GPU:er. Embedding-, transkriberings- och bildgenereringsmodeller är lika valbara, inklusive svenska och norska Whisper-varianter och diarisering (vem-sa-vad) för ljud.
Språk och varumärke	Gränssnittet levereras på fem språk: engelska, svenska, norska, tyska och finska. Varje installation kan ha ett eget färgtema (ljust och mörkt), och varje organisation sätter sitt eget visningsnamn och sin egen logotyp. Ett webbplatsövergripande banner-meddelande kan visas för alla användare.
Data och lagring	Kör de medföljande databaserna eller anslut er befintliga PostgreSQL, Redis, objektlagring och vektordatabas. Lagringsstorlekar sätts per komponent. Krypteringsnycklar för känslig data i vila kan tillhandahållas och hanteras av er.
Säkerhet och nätverk	Era egna TLS-certifikat och domäner. Hemligheter kan hanteras av era egna verktyg (till exempel Vault eller sealed secrets) i stället för att genereras av plattformen. Privata container-registries, utgående proxy och helt isolerade installationer stöds. Utgående trafik begränsas till de adresser ni uttryckligen tillåter. Administrativa åtgärder och användaråtgärder registreras i en granskningslogg, och lagrade uppgifter (för integrationer och MCP-servrar) är krypterade i vila.
E-post	Inbjudningar och lösenordsåterställningar skickas via er egen SMTP-server eller en e-posttjänst — eller inte alls.
Assistentfunktioner	Vilka verktyg assistenter får använda: webbsökning, webbplatscrawling för kunskapsbaser, webbläsarautomation, bildgenerering, anslutningar till MCP-servrar, sandlådekörning av kod samt integrationer med system som SharePoint, OneDrive, Teams, Confluence, Slack och Google Workspace. Varje funktion är avstängd tills ni aktiverar den. Assistenter kan även bäddas in som chattwidgetar på era egna webbplatser, med färg, hälsningsfras, integritetspolicytext och en lista över tillåtna domäner per widget.
Kontroller på organisationsnivå	Lagringskvoter och månatliga användningskrediter per organisation, vilka funktionspaket som är aktiverade för varje organisation, säkerhetsklassningar som begränsar vilka modeller och verktyg som får hantera känslig data, samt automatisk datalagring — konversationer kan raderas efter ett antal dagar som ni väljer per assistent.
Funktionsval	Organisationsövergripande val som huruvida användare kan självregistrera sig, om skapare kan publicera widgets och utfärda API-nycklar, samt vilka delar av gränssnittet som visas (till exempel mallar, widgets, webbsökning och hjälpcentret).
Skalning och drift	Hur många arbetare av varje typ som körs, om de autoskalas med belastningen, resursgränser per komponent, loggnivåer och vart telemetri skickas.

Om ett krav inte täcks här, lyft det med er Intric-kontakt — listan ovan speglar den standardiserade konfigurationsytan, och den växer över tid.