Deployment Options

Intric offers three main deployment options to meet different requirements for security, data control and infrastructure. Regardless of which option is chosen, all communication (both between web server and application and to external services) occurs encrypted via SSL/TLS.

Multi-tenant Cloud

Multi-tenant is the most common deployment form for Intric, where resources are used efficiently to deliver a stable and cost-effective service. In this solution, multiple customers share the application server and database, but data is kept strictly separate through logical separation. The solution is operated on virtual servers at Glesys AB, which is ISO 27001-certified, and all data storage occurs securely in their data centers.

This option suits organizations that want a smooth and maintenance-free solution without needing to manage their own infrastructure.

Dedicated Instance Cloud

For organizations that have higher requirements for isolation but still want to benefit from the cloud’s advantages, we offer dedicated instance. Here, each customer is assigned a completely own, isolated database, despite being on a shared server infrastructure. This guarantees that your data is never physically mixed with other customers’ data in the database layer, which provides an extra level of security. Just like with the Multi-tenant solution, operation occurs on virtual servers at Glesys AB.

On-prem Managed

On-prem Managed is the option for organizations with very strict security requirements, where data according to policy must stay within the own IT environment. In this case, Intric is installed and run locally on your own server, and the platform is by default only accessible from within your internal network. This gives you full control over both hardware and data flows. External services are only reached if you specifically open for them in your firewall, according to the instructions under the section about Language Models.

As a complement to this option, there’s also the possibility to install local GPUs. By doing this, you can run even the language models themselves locally in your data center. This minimizes, or in some cases completely eliminates, the need for external API calls, which creates a completely closed environment for maximum security and integrity.

Intric architecture

Intric is not a single program but a set of cooperating services, each with a clear responsibility:

• Web application (frontend): The interface users work in. Rendered server-side for fast load times and delivered over HTTPS.
• API and background worker (backend): The core of the platform — permissions, spaces, assistants, knowledge and all business logic. A separate background worker handles long-running jobs so the interface stays responsive.
• Identity provider: All sign-in happens via OpenID Connect (OIDC). Intric bundles an identity provider (Zitadel), or connects to the one your organization already uses, such as Microsoft Entra ID.
• Datastores: PostgreSQL (with the pgvector extension) is the primary database and vector store, Redis handles caching and job queues, and an S3-compatible object store holds uploaded files. A dedicated vector database (Weaviate) can be enabled for large knowledge bases.
• Processing services: A message queue (RabbitMQ) feeds specialized workers for document ingestion, PDF pre-processing with OCR, and audio transcription. A sandboxed runner executes user-generated code in isolated, unprivileged jobs. These workers scale independently of the core application — see Server and Hardware for sizing.

 browser ──HTTPS──> frontend <──> backend (API + worker)
                                     │
                    ┌────────┬───────┼──────────┐
                    v        v       v          v
                PostgreSQL Redis  object     identity
                (pgvector)        store      provider
                                     │
                                     v  signed JWTs
                              message queue ──> processing workers
                                                (documents, PDF/OCR,
                                                 transcription, sandbox)

All internal traffic is encrypted, and the services authenticate to each other with signed tokens — the processing tier never trusts a request it cannot verify.

Deployment on Kubernetes with Helm

All on-prem installations of Intric run on Kubernetes — this is how the platform is delivered. It is packaged as two Helm charts, published as OCI packages from ghcr.io/inoolabs/charts:

• intric-helm — the application tier: frontend, backend, identity provider and all datastores. Every bundled datastore is optional; each can be switched off in favor of infrastructure you already operate (an existing PostgreSQL cluster, Redis, S3 endpoint or identity provider).
• intric-services — the processing tier: message queue and the document, PDF and transcription workers.

What your platform team needs to provide:

• Kubernetes 1.29 or later and Helm 3.8 or later.
• An ingress controller, a default StorageClass, TLS certificates and DNS records for the application hosts.
• Credentials for pulling Intric’s container images.

Installation follows standard Kubernetes practice: write a values file describing your environment, install the charts, and complete a one-time bootstrap that creates the first tenant and administrator. Upgrades are ordinary Helm upgrades. GitOps workflows (for example ArgoCD) are fully supported, as are air-gapped environments — all images can be mirrored to a private registry, and outbound traffic can be routed through a proxy.

The processing workers can scale automatically based on queue depth (via KEDA), so capacity follows your actual document and audio volume instead of being fixed.

A complete configuration reference is included with the charts themselves.

Observability

Intric is built to plug into the monitoring stack you already run:

• OpenTelemetry: The platform exports traces, metrics and logs over OTLP/HTTP to a collector you point it at — compatible with Grafana, Prometheus, Loki, Tempo, Elastic and other OpenTelemetry-based stacks.
• Error reporting: Optional Sentry integration for application errors, disabled by default.
• Environment tagging: Telemetry is tagged per environment (for example staging or production) so signals stay separated across installations.
• Logs: All components write structured logs to standard output, with configurable log level, ready for whatever log pipeline your cluster uses.
• Privacy-aware by default: Calls to language models are traced for latency and errors without recording prompt content, and error reports scrub user questions and credentials before leaving the platform.

What can be customized

Everything below is decided per installation — no code changes required. This is the non-technical map of the knobs; the technical details live in the chart documentation.

Area	What you decide
Sign-in and identity	Use the bundled identity provider or your own (any OIDC provider, such as Microsoft Entra ID). How users get access: personal invitations, automatic provisioning at first sign-in, or self-service sign-up. Group memberships can be synced from your directory.
AI models	Which language-model providers are available: OpenAI, Anthropic, Azure OpenAI, Google Gemini, AWS Bedrock, Mistral, Berget, OVHcloud, Intric’s EU-hosted models — or your own self-hosted models, including fully local models on your own GPUs. Embedding, transcription and image-generation models are equally selectable, including Swedish and Norwegian Whisper variants and diarization (who-said-what) for audio.
Language and branding	The interface ships in five languages: English, Swedish, Norwegian, German and Finnish. Each installation can carry its own color theme (light and dark), and each organization sets its own display name and logo. A site-wide banner message can be shown to all users.
Data and storage	Run the bundled databases or connect your existing PostgreSQL, Redis, object storage and vector database. Storage sizes are set per component. Encryption keys for sensitive data at rest can be supplied and managed by you.
Security and network	Your own TLS certificates and domains. Secrets can be managed by your own tooling (for example Vault or sealed secrets) instead of being generated by the platform. Private container registries, outbound proxies and fully air-gapped installations are supported. Outbound traffic is limited to the endpoints you explicitly allow. Administrative and user actions are recorded in an audit log, and stored credentials (for integrations and MCP servers) are encrypted at rest.
Email	Invitations and password resets are sent through your own SMTP server or an email service — or not at all.
Assistant capabilities	Which tools assistants may use: web search, website crawling for knowledge bases, browser automation, image generation, connections to MCP servers, sandboxed code execution, and integrations with systems like SharePoint, OneDrive, Teams, Confluence, Slack and Google Workspace. Each is off until you enable it. Assistants can also be embedded as chat widgets on your own websites, with per-widget color, greeting, privacy-policy text and an allowlist of domains.
Organization-level controls	Per-organization storage quotas and monthly usage credits, which capability packages are enabled for each organization, security classifications that restrict which models and tools may handle sensitive data, and automatic data retention — conversations can be deleted after a number of days you choose per assistant.
Feature switches	Organization-wide switches such as whether users can self-register, whether creators can publish widgets and issue API keys, and which parts of the interface are shown (for example templates, widgets, web search and the help center).
Scale and operations	How many workers of each kind run, whether they autoscale with load, resource limits per component, log levels, and where telemetry is sent.

If a requirement isn’t covered here, raise it with your Intric contact — the list above reflects the standard configuration surface, and it grows over time.