Why open source matters for enterprise AI
Enterprise AI systems often work with sensitive company information, including documents, conversations, customer records, project details and internal data. Organizations therefore need visibility and control when evaluating an AI agent.
Open source gives technical teams access to the underlying code. They can do a lot of things like:
- Inspect the system
- Review its components
- Assess how it fits their security requirements before deployment
For example, a security team can review the public code during its technical assessment. This reduces reliance on the vendor’s description of how the product works.
Open source can also support greater control over deployment. An organization can run the system within its own cloud environment with a self-hosted setup. It controls:
- Surrounding infrastructure
- Network configuration
- Model connections
Instead of relying entirely on a vendor-managed environment.
This matters for open-source enterprise AI because adoption involves more than model quality. Security reviews, procurement requirements, data policies and operational controls can all affect whether an AI system is suitable for production.
Open source can also give organizations more choice over model providers. Omni supports commercial models and self-hosted or open-weight model endpoints, including:
- Anthropic
- OpenAI
- Gemini
- AWS Bedrock
- Vertex AI
- Azure AI Foundry
- OpenAI-compatible endpoints such as vLLM and Ollama
The organization can therefore decide where Omni runs, which models it connects to and which workplace systems it brings into the platform.
A self-hosted AI assistant on your own infrastructure
A self-hosted AI assistant runs within infrastructure controlled by the organization rather than being hosted entirely by the software provider.
With Omni, teams can deploy the open-source system on their own infrastructure. The repository supports Docker Compose deployments and Terraform modules for production deployments on AWS and GCP. Teams can use these options to deploy Omni within their chosen environment.
Self-hosting gives the organization control over the deployment boundary. The team operating Omni can manage how the system connects to workplace applications, models and internal infrastructure.
It also gives teams flexibility over model selection. Omni can connect to commercial APIs, managed cloud models and self-hosted open-weight models. Organizations can therefore choose a model setup that fits their requirements rather than relying on one provider.
Data handling depends on the deployment and configuration. When an organization self-hosts Omni, the software runs within infrastructure it operates. The organization remains responsible for:
- Network access
- Connected services
- Model endpoints
- Credentials and other parts of the environment
Teams should use the official deployment documentation for the current installation process rather than relying on generic hardware specifications.
How Omni’s open-source AI agent platform works
Omni brings workplace information, search and agent execution into one system.
Workplace tools → Connectors → Shared context → Agent runtime → Employee response or action
| Layer | What it does | Examples |
|---|---|---|
| Workplace tools | Provides company information and data | Google Workspace, Microsoft 365, Slack, Jira |
| Connectors | Brings information from connected systems into Omni | Workplace and business system integrations |
| Shared context | Organizes relevant company information | Permission-aware company context |
| Agent runtime | Processes requests and performs supported tasks | Search, analysis and tool use |
| Employee interface | Delivers results to employees | Answers, analysis and supported actions |
Connectors bring information from the systems a company already uses. Omni’s current repository lists integrations across Google Workspace, Microsoft 365, Slack, Jira, Confluence, HubSpot, GitHub, ClickUp, Linear and other workplace systems. The connected information feeds Omni’s shared company context. The agent connects to multiple systems and uses relevant information to handle requests.
For example, an employee could ask Omni to investigate a customer issue. The agent can use relevant customer communication, project information, tickets and internal knowledge from connected systems to build the required context.
The agent runtime then uses that context to answer questions or perform supported tasks. Omni also supports tool use and sandboxed code execution for tasks that require analysis or processing.
Permissions form an important part of this architecture. Omni uses permission-aware company context and limits indexed information based on source system permissions. This helps keep an employee’s access to company information tied to the permissions of the connected source.
For teams that want to extend the system, Omni also supports MCP and connector SDKs. Developers can build company-specific integrations using Python or TypeScript. For a complete list of current AI agent integrations, see the Omni integrations page.
Deployment paths
Omni supports both self-managed and managed deployment options. The choice depends on how much infrastructure control an organization wants to maintain.
| Deployment option | Who manages it | Infrastructure | Suitable for |
|---|---|---|---|
| Community self-hosted | Your organization | Your cloud or infrastructure | Teams that want to manage the deployment themselves |
| Omni Cloud | Omni | Omni-managed infrastructure | Teams that prefer a managed deployment |
The paid Business plan applies to either deployment. Organizations can run Omni themselves. Omni offers an open-source Community version for self-hosting. Teams can deploy it using their own infrastructure. They can also use it to manage the surrounding environment.
Organizations can choose a managed option. Omni Cloud handles the hosting, updates, security and scaling. This gives organizations two main deployment paths: manage Omni themselves or use a managed deployment.
Self-hosted: Docker and your cloud
The self-hosted route starts with the Omni open-source repository. Teams can use Docker Compose for deployment and Terraform for production deployments on AWS and GCP. The general process is:
- Get the Omni source or deployment package from the official repository.
- Configure the required environment variables and connected services.
- Deploy the application using the supported Docker or Terraform route.
- Connect the workplace systems and model providers required by the organization.
- Configure access, permissions and other operational controls.
- Verify the deployment before making it available to employees.
This makes Omni a self-hosted AI agent that an organization can operate within its chosen infrastructure. The exact configuration depends on the deployment environment. Use the official deployment documentation for current setup instructions instead of relying on fixed server specifications.
Omni Cloud
Omni Cloud is Omni’s managed deployment option. Omni manages the hosting, updates, security and scaling.
The Omni website currently asks visitors to get notified when Omni Cloud is available. It also offers an early access form.
Omni Cloud is for organizations that want to use Omni without managing the infrastructure themselves.
The current pricing page lists a free Community self-hosted version. It also lists paid Business and Enterprise plans. Business costs $10 per user per month when billed annually. Organizations can use it as a self-hosted enterprise license or with Omni Cloud.
Security, permissions and governance
Enterprise AI needs to control not only what a model can generate but also what information an employee can access.
Omni’s architecture includes permission-aware company context. The repository states that indexed information is scoped according to permissions inherited from each source system.
This matters when employees have different access levels. Two employees may ask about the same project. One may have access to a restricted document. The other may not have access. Omni uses source permissions when retrieving information. Omni also provides governance features through its paid enterprise offering.
| Capability | Purpose |
|---|---|
| Permission-aware context | Keeps retrieved information aligned with source-system permissions |
| SSO | Supports centralized authentication |
| SCIM | Supports user and access provisioning |
| Audit logs | Provides visibility into system activity |
| Model policies | Helps organizations control model usage |
| Access policies | Provides administrative control over access |
| Self-hosting | Gives organizations control over their deployment environment |
Model control is another part of the deployment. Organizations can connect different model providers rather than using one fixed model. This includes commercial APIs and self-hosted model endpoints.
Self-hosting also changes who operates the infrastructure. With a self-managed deployment, the organization controls its cloud or on-premises environment, network configuration and operational processes. This can matter for companies with specific data residency, security or network requirements.
These controls do not remove the need for an organization’s own security review. Teams still need to configure:
- Identity
- Credentials
- Network access
- Connected applications
- Model providers according to their internal policies
Open-source platforms vs frameworks: know the difference
The term “open-source AI agent” covers several types of software.
An AI agent framework gives developers the building blocks for creating an agent. It can provide components for workflows, state, tool use, model calls and agent logic. The development team still designs and assembles the application around those components.
LangGraph is one example. Its current Python package is released under the MIT license and is designed for building stateful, multi-actor applications with language models. CrewAI is another framework. Its repository describes CrewAI as an open-source framework and lists the MIT License.
Dify takes a broader application platform approach. Its current website describes Community Edition as source-available, self-hostable with Docker, and licensed under an Apache-2.0-derivative license. Glean is an enterprise AI platform that connects company information across workplace tools. Dust is an AI platform for building and using agents with company data and tools.
The main difference is the problem each product solves.
| Product | Category | Licensing position | Primary use |
|---|---|---|---|
| LangGraph | Agent framework | MIT | Building customized agent applications |
| CrewAI | Agent framework | MIT | Building multi-agent applications |
| Dify | AI application platform | Source-available | Building and deploying AI applications |
| Omni | Enterprise AI agent platform | Apache 2.0 open-source core | Company-wide AI work and connected company context |
A framework is useful when developers want to build a customized agent system. A platform provides more of the surrounding product and deployment experience.
Omni is positioned as a deployable platform for company-wide work. Its open-source repository combines:
- An agent runtime
- Company context
- Workplace connectors
- Model support
- Permissions
- Deployment options in one system
Frameworks and platforms address different development needs. Teams building a highly customized agent application may want a framework. Teams looking for a deployable system for company-wide work may instead evaluate an agent platform.
Built in the open
Omni’s source code is publicly available through the Omni GitHub repository. The repository is licensed under the Apache License 2.0.
As of September 2026, it has 770+ GitHub stars, showing public interest in the project.
GitHub also provides a public view of the project’s development activity. The repository has nearly 1,000 commits, along with public issues, pull requests and discussions.
The public repository includes application code, connectors, deployment files, SDKs and infrastructure-related components. Developers can inspect the code and contribute through the project’s public development workflow.
Omni also publishes first-party performance research through its EnterpriseRAG benchmark.
In a May 2026 benchmark, Omni was tested against EnterpriseRAG-Bench, a 500-question test covering synthetic workplace knowledge. The test used roughly 512,000 documents across nine source types. Omni recorded an overall score of 68.07, with 73.40% correctness and 69.43% document recall in the reported run.
This benchmark represents a specific test rather than a guarantee of performance for every organization. Its corpus, models, evaluation method and question set define the scope of the reported results. The full methodology and results are available in the EnterpriseRAG benchmark.
Frequently asked questions
What’s included in Community, and what requires a paid license?
Community includes Omni’s open-source core agents, search, and integrations for self-hosted use, with community support. Business adds capabilities such as SAML/OIDC single sign-on, advanced admin controls, priority support, and guided onboarding. Enterprise adds SCIM provisioning, audit and compliance controls, custom SLAs, and custom connectors. Paid capabilities are available with a self-hosted license; you do not have to move to Omni Cloud to use them.
Can I use my own model provider or a self-hosted model?
Yes. Omni supports external model providers as well as OpenAI-compatible endpoints for self-hosted models, including setups using llama.cpp, vLLM, or Ollama. Configure your endpoint and model in the admin settings. Model inference and embeddings are separate configuration choices, so review both when deciding where company data is processed. You remain responsible for provider charges or the hardware required to run a local model.
What am I responsible for operating when I self-host Omni?
Your team operates the deployment: infrastructure, persistent data and backups, upgrades, monitoring, network access, connector services, credentials, and model configuration. You also need to check sync failures and source API limits. Docker Compose and Terraform deployment options help with setup, but self-hosting still requires ongoing operations. Choose Omni Cloud if you want the Omni team to manage hosting, updates, security, and scaling instead.
Is Omni really free to self-host?
The Community software is free to self-host. Running it can still incur costs for servers, storage, backups, model inference, embeddings, and engineering time. A local model shifts inference costs to your own hardware rather than making them disappear. Budget for those operating costs separately from any optional paid Omni license.
What license is Omni’s open-source core released under?
Omni’s core is released under Apache License 2.0, which permits use, modification, and distribution subject to its terms. That does not make paid enterprise features part of the Apache-licensed core. Review the repository’s LICENSE file and any applicable commercial terms before redistributing or building on the software.
How is Omni different from CrewAI or LangGraph?
CrewAI and LangGraph are developer frameworks for building agent applications. Omni is a deployable company-wide agent platform with workplace connectors, indexed context, search, and an employee-facing interface. Choose a framework when your engineering team wants to build its own application and architecture; evaluate Omni when you want to deploy a shared assistant around existing workplace tools.
Does self-hosting mean no company data leaves my network?
Not automatically. Self-hosting controls where Omni runs, but external model and embedding providers still receive the data sent to their APIs. Connected SaaS applications also communicate over their own APIs. For a deployment with local inference, configure the model and embedding endpoints accordingly and review network access, connectors, and other external services. Do not treat self-hosting alone as an air-gap guarantee.
References: deployment documentation, the core license, and Omni plans.