# On-Premise AI Deployment > Source: https://ibl.ai/resources/capabilities/on-premise-deployment *Deploy a production-grade AI platform entirely on your own infrastructure — with full source code, zero external dependencies, and complete control.* On-premise AI deployment means running the entire AI platform stack inside your own data center, private cloud, or hybrid environment — not routing data through a vendor's servers. ibl.ai delivers pre-built Docker images and Kubernetes-ready configurations that your infrastructure team can deploy, configure, and operate independently. No callbacks to external services. No SaaS dependencies. No shared tenancy. With 1.6M+ users across 400+ organizations — including NVIDIA's global AI training platform — ibl.ai is purpose-built for production environments where security, performance, and sovereignty are non-negotiable. ## The Challenge Most enterprise AI vendors offer a cloud-hosted SaaS product with an "enterprise tier" that still routes your data through their infrastructure. Your sensitive documents, user queries, and operational data leave your environment every time someone interacts with the system. Compliance teams flag it. Security teams block it. Procurement stalls. When organizations try to self-host alternatives, they inherit fragmented open-source components with no production support, no audit trail, and no clear upgrade path. The result is months of integration work, brittle deployments, and an AI system that can't scale — leaving teams back where they started. ## How It Works 1. **Receive the Complete Platform Package:** ibl.ai delivers the full platform as versioned Docker images and Helm charts alongside complete source code. Your team receives everything needed to deploy, inspect, and modify the system — no black boxes. 2. **Deploy to Your Infrastructure:** Stand up the platform on your data center hardware, VMware environment, private cloud (OpenStack, vSphere), or air-gapped Kubernetes cluster. Pre-tested configurations reduce deployment time from months to days. 3. **Connect Your Models:** Configure the platform to use your preferred LLM — whether that's a locally hosted Llama or Mistral instance, an on-premise GPU cluster, or a private Azure OpenAI endpoint. The platform is fully model-agnostic. 4. **Integrate Your Data Sources via MCP:** Use the built-in Model Context Protocol (MCP) layer to connect AI agents to internal databases, document repositories, APIs, and enterprise systems — all within your network perimeter. 5. **Configure Multi-Tenant Access Controls:** Define organizations, roles, and permissions using the multi-tenant architecture. Integrate with your existing identity provider (LDAP, SAML, OIDC) to enforce role-based access across departments and user groups. 6. **Operate and Audit Independently:** Every agent action, model call, and data access event is logged to your infrastructure. Your security team owns the audit trail. Updates are applied on your schedule — the platform runs without any dependency on ibl.ai's servers. ## Features ### Full Source Code Ownership Customers receive the complete codebase — not a compiled binary or a managed service. Your engineering team can audit, modify, extend, and fork the platform. No license restrictions on internal use. ### Air-Gapped Operation The platform is architected to run with zero external network dependencies. Once deployed, it operates entirely within your environment — no telemetry, no license callbacks, no external API requirements. ### Kubernetes-Native Deployment Pre-built Helm charts and Docker Compose configurations support deployment on any Kubernetes distribution — including OpenShift, Rancher, and air-gapped K3s clusters. Horizontal scaling is built in. ### Model-Agnostic Architecture Connect to Claude, GPT-4, Gemini, Llama 3, Mistral, or any custom fine-tuned model. Swap models without rebuilding workflows. Run multiple models simultaneously for different use cases or security tiers. ### Complete Audit Trail Every agent action, tool call, API request, and model response is logged with full context — user identity, timestamp, inputs, outputs, and execution path. Logs are stored in your infrastructure and exportable to your SIEM. ### Multi-Tenant Isolation Serve multiple departments, business units, or client organizations from a single deployment with strict data isolation. Role-based access control enforces boundaries at the API, data, and agent level. ### API-First Integration Layer Every platform capability is exposed through documented RESTful APIs. Integrate AI agents into existing enterprise workflows, internal portals, and operational systems without UI dependency. ## With vs. Without | Aspect | Without | With | |--------|---------|------| | Data Residency | User queries, documents, and context are transmitted to vendor cloud infrastructure for processing. Data residency is a contractual promise, not a technical guarantee. | All data is processed exclusively within your infrastructure. No data leaves your network perimeter at any point — by architecture, not by policy. | | Vendor Dependency | The platform stops functioning if the vendor has an outage, changes pricing, discontinues the product, or terminates your contract. You have no fallback. | The platform runs independently on your infrastructure indefinitely. ibl.ai's operational status has zero impact on your deployment. You own the code. | | Source Code Access | You receive a compiled binary, a managed service, or a containerized black box. Security review is limited to what the vendor discloses. Internal modification is prohibited. | You receive the complete, unobfuscated source code. Your security team can audit every line. Your engineers can modify, extend, and fork the platform for internal use. | | Audit & Compliance | Audit logs are partial, vendor-controlled, and accessible only through vendor tooling. Demonstrating compliance requires vendor cooperation and is limited by their logging architecture. | Every agent action, model call, and data access event is logged to your infrastructure in your format. Your team controls retention, access, and export — no vendor coordination required. | | Model Flexibility | The platform is tightly coupled to one or two model providers. Switching models requires rebuilding integrations or migrating to a different vendor entirely. | Connect any model — GPT, Claude, Gemini, Llama, Mistral, or custom fine-tuned models — through a unified interface. Swap or run multiple models simultaneously without rebuilding workflows. | | Deployment Timeline | Self-hosting open-source components requires assembling an LLM runtime, vector database, orchestration layer, auth system, and UI — typically 12–18 months of engineering effort. | Pre-built Docker images and Helm charts reduce deployment to days. The platform arrives tested, versioned, and production-ready with documented configuration for your environment. | | Air-Gapped Environments | Cloud AI vendors cannot serve air-gapped networks, classified environments, or OT networks by definition. These environments are simply excluded from AI adoption. | The platform is architected for air-gapped operation from the ground up. Deploy on classified networks, factory floors, and disconnected environments with full capability. | ## FAQ **Q: Does ibl.ai's on-premise deployment truly run with no external dependencies?** Yes. Once deployed, the platform operates entirely within your infrastructure. There are no license callbacks, telemetry endpoints, or external API requirements. The system continues running regardless of ibl.ai's operational status. **Q: What infrastructure is required to deploy ibl.ai on-premise?** The platform runs on any Kubernetes-compatible environment, including on-premise data centers, VMware clusters, OpenShift, and private clouds. Minimum requirements depend on user load and agent workload — ibl.ai provides sizing guidance based on your deployment profile. **Q: Can we use our own LLM models with the on-premise deployment?** Yes. The platform is fully model-agnostic. You can connect locally hosted models via Ollama or vLLM, use a private Azure OpenAI endpoint, or integrate any OpenAI-compatible API. Multiple models can run simultaneously for different use cases. **Q: What does 'full source code ownership' mean in practice?** You receive the complete, unobfuscated codebase — not a compiled binary. Your team can audit every component, modify functionality, apply internal security patches, and extend the platform without restriction. You are not dependent on ibl.ai to make changes. **Q: How does the platform handle multi-tenant isolation in an on-premise deployment?** The multi-tenant architecture enforces strict data and access isolation between organizations, departments, or client groups at the API, database, and agent execution layers. A single deployment can serve multiple isolated tenants without data commingling. **Q: Is the on-premise deployment suitable for classified or air-gapped government networks?** Yes. The platform is architected specifically for air-gapped operation. It has been deployed in environments with no internet connectivity. All dependencies are packaged for offline installation, and no external network calls are made during operation. **Q: How are updates and new versions handled for on-premise deployments?** ibl.ai delivers versioned release packages with documented upgrade paths and changelogs. Your team applies updates on your own schedule. There are no forced updates, and the platform continues operating on older versions without degradation. **Q: How does on-premise deployment support compliance requirements like HIPAA, FedRAMP, or SOC 2?** Because all data processing occurs within your controlled infrastructure, you retain full ownership of the compliance boundary. The complete audit trail, RBAC controls, encryption in transit, and source code access support ATO processes, security assessments, and regulatory audits without vendor coordination.