Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.jitera.ai/llms.txt

Use this file to discover all available pages before exploring further.

This page lists all requirements for deploying Jitera Self-Hosted. Items are categorized as Mandatory (deployment will not function without them) or Optional (enhance functionality but can be added later).

Mandatory Requirements

Kubernetes Cluster

Jitera Self-Hosted is verified with Kubernetes 1.35.x. The following environments are verified by Jitera:
PlatformType
Amazon EKSManaged
Azure AKSManaged
On-premises (kubeadm, k3s, RKE2)Self-managed
For supported Kubernetes versions on managed platforms, see the Amazon EKS version documentation and Azure AKS version documentation.
Earlier versions (1.28-1.34) may work but are either in Extended Support on AWS EKS (with premium pricing) or require the LTS support plan on Azure AKS (Premium tier). If omitting the version flag on cluster creation commands, the cloud provider selects the latest stable version automatically.

Cluster Specifications

ComponentProduction MinimumEvaluation Minimum
CPU architecturex86-64 (AMD64) — ARM is not supportedSame
CPU (total)16 cores12 cores
Memory (total)64 GB48 GB
Storage (per node)200 GB SSD200 GB SSD
The evaluation minimum (e.g., 3x m6i.xlarge on AWS or 3x Standard_D4s_v3 on Azure) is sufficient for development, proof-of-concept, and small-team deployments (up to 10 users). For production workloads, use the production minimum or refer to the Sizing Guide for detailed tier recommendations.
For detailed architecture information including component resource requirements and scaling strategies, see Architecture.

Required Software

ToolMinimum Version
Helm3.20.x (verified)
kubectl1.35.x (verified)
Helm 4.x is not supported. Use Helm 3.20.x.
The Helm chart includes Kong as an ingress controller. You do not need to install a separate ingress controller (e.g., NGINX) unless your environment requires one for other workloads.

Jitera Registry Credentials

Access to Jitera container images requires authentication credentials. These will be provided by Jitera after the contract is signed. See Registry Credentials for configuration details.

Jitera Helm Chart

The Jitera Helm chart is provided as a zip file. It will be delivered by Jitera along with the registry credentials after the contract is signed.

LLM Provider

Jitera requires an LLM provider for AI-powered code generation, chat, and document analysis. One of the following is required as the primary provider:
ProviderConfiguration
OpenAIAPI key with access to GPT-4 class or later models
Azure OpenAIAzure OpenAI resource with model deployments
At minimum, a chat/completion model (e.g. gpt-4.1) and an embeddings model (e.g. text-embedding-ada-002) must be available from your chosen provider. See AI Configuration for provider setup, model requirements, and additional provider options.

DNS Hostnames

Two resolvable hostnames belonging to the same domain are required:
HostnamePurposeExample
Main domainApplication UI, API, and servicesapp.example.com
Chat domainChat/AI interface (SWEF service)chat.example.com
Both hostnames must share the same root domain (e.g., example.com) because authentication cookies are set on the root domain.
Additional hostnames are required if you enable optional services: MinIO API (minio.example.com), MinIO Console (minio-console.example.com), and Grafana (grafana.example.com). These should also resolve to the load balancer IP.
DNS records are configured after deployment, once the load balancer IP or hostname is available. See the post-installation steps in each installation guide for provider-specific instructions.

Server Certificates

TLS certificates are required for HTTPS access. The certificate must cover both hostnames (main domain and chat domain). The following methods are verified:
MethodNotes
cert-managerAutomatic certificate management with Let’s Encrypt or other ACME CAs
AWS ACMAWS Certificate Manager, used with AWS Load Balancer
Self-signed certificates are not supported.
For provider-specific TLS setup, see the installation guides: AWS EKS (ACM or cert-manager), Azure AKS (cert-manager), or On-premises (cert-manager or existing certificate).

Object Storage

Jitera requires object storage for file uploads, generated code artifacts, and project exports. The following providers are verified:
ProviderType
AWS S3Managed
Azure Blob StorageManaged
MinIO (in-cluster)Self-hosted, included in Helm chart
See Storage Configuration for setup instructions and CORS requirements.

SMTP Service

An SMTP service is required for email notifications, user invitations, and password resets. The following are verified:
ProviderType
AWS SESManaged
Azure Communication ServicesManaged
SendGridManaged
Postfix (in-cluster)Self-hosted, included in Helm chart
For provider-specific setup, see the installation guides: AWS EKS Installation (SES), Azure AKS Installation (Communication Services), or On-premises Installation (Postfix / generic SMTP).
When using SendGrid, set mailer.smtp_settings.user_name to apikey (literal string) and use your SendGrid API key as the password.
Most cloud email services start with restricted sending limits (e.g., AWS SES sandbox mode). Before deploying to production, verify your domain (SPF, DKIM, DMARC), request production access from your provider, and gradually warm up sending volume to establish reputation. Without this, invitation emails and notifications may fail or land in spam.

Optional Requirements

GitHub Integration

A GitHub App is required to connect GitHub repositories as code sources within Jitera projects. See GitHub Integration for setup instructions.

GitLab Integration

A self-managed GitLab instance (version 16.8+) is required to connect GitLab repositories as code sources. A Personal Access Token with admin-level access is configured through the Jitera UI. See GitLab Integration for setup instructions.

External Services

All data stores, caches, and message brokers are bundled in the Helm chart and deployed in-cluster by default. No external setup is required for initial deployment.
ServiceType
PostgreSQLDatabase
PGVectorDatabase
MongoDBDatabase
RedisCache
RabbitMQMessage broker
For production high-availability deployments, consider externalizing these services to managed alternatives (e.g., Amazon RDS, Azure Database for PostgreSQL, ElastiCache, Azure Cache for Redis). See External Services for supported versions and configuration details.

Additional AI Providers

Beyond the mandatory primary LLM provider, you can configure additional providers for expanded model access:
ProviderPurpose
AWS BedrockAccess to Claude, Llama, and other models via Bedrock
AnthropicDirect API access to Claude models
Google AIAccess to Gemini models
See AI Configuration for setup instructions.

Web Search Agent

To enable web search, URL reading, and deep research capabilities in Boost, configure one of the following search backends:
BackendConfiguration
Tavily (recommended)API key — no self-hosted infrastructure needed
SearXNGSelf-hosted metasearch engine URL
Jina Reader (r.jina.ai) must be reachable for URL-to-text conversion. See AI Configuration — Web Search Agent for details.

Monitoring Stack

A full monitoring stack (Prometheus, Grafana, Loki, OpenTelemetry) is included in the Helm chart and enabled by default. It can be disabled if you use an existing monitoring solution.

Network Requirements

For detailed firewall rules, port requirements, and network access patterns, see Network and Firewall.

Checklist

Mandatory

  • Kubernetes cluster running (1.35.x) with Helm 3.20.x and kubectl installed
  • Jitera registry credentials received
  • Jitera Helm chart zip file received
  • LLM provider configured (OpenAI API key or Azure OpenAI resource)
  • Two DNS hostnames configured on the same domain
  • Object storage ready (S3, Azure Blob, or MinIO)
  • SMTP service configured
  • TLS certificates ready (cert-manager or AWS ACM)

Optional

  • GitHub OAuth application created (for repository integration)
  • GitLab Personal Access Token ready (for repository integration)
  • Additional AI provider keys (Bedrock, Anthropic, Google AI)
  • Web search backend configured (Tavily API key or SearXNG URL)
  • External services configured (for production HA)

What’s Next?

AWS EKS

Deploy on Amazon EKS

Azure AKS

Deploy on Azure AKS

On-premises

Deploy on self-managed Kubernetes