getomnico/omni: a self-hosted AI agent that inherits your company's permissions

The problem Omni targets: agents that cannot see company data, or see too much of it

Most agent deployments fail at one of two points. Either the agent cannot reach the systems where work actually happens (Drive, Slack, Jira, Confluence, HubSpot), or it reaches them with a single service account and therefore shows an employee a document they were never allowed to open. Omni is built around the second problem. The README describes "Permission-Aware Company Context": indexed information stays scoped by the permissions inherited from each source system. That is a retrieval-time constraint, not a prompt instruction, and it is the reason the project ships a connector per system rather than one generic crawler.

The audience is an internal platform team. Omni expects you to run Postgres, Redis and a set of containers, and to register OAuth applications with each provider. A single developer can start it with Docker Compose, but the configuration surface (database credentials, Redis URL, roughly twenty connector ports, per-service CPU limits) reads as something an operations team owns.

How the Omni stack is put together: Rust services, a Python agent runtime, and one Postgres

The Cargo workspace in Cargo.toml is the clearest view of the architecture. It lists services/searcher, services/indexer, services/connector-manager and services/sandbox, plus connectors for google, slack, atlassian, filesystem, fireflies, web, imap, nextcloud and darwinbox, alongside shared, benchmarks, cli and sdk/rust. The README states that core services are written in Rust for search, indexing and connector orchestration, Python for the agent runtime and model orchestration, and SvelteKit for the frontend. Each connector runs as its own lightweight container, so an integration can carry its own language and dependencies.

The data layer is the design decision worth pausing on. Omni uses Postgres with ParadeDB as the single store for BM25 full-text search, pgvector semantic search and application data. The README is explicit about the trade: "No Elasticsearch. No dedicated vector database. One database to tune, backup, monitor, and operate." That is a real reduction in operational surface, and it also means your search quality and your vector recall are now coupled to one engine's configuration and one upgrade path.

Code execution is separated into services/sandbox. According to the README, the agent runtime can run Python and bash in a sandboxed container on an isolated Docker network with no access to internal services or the internet, using Landlock filesystem restrictions, resource limits and a read-only root filesystem. The .env.example confirms a SANDBOX_PORT of 8090 and a separate OMNI_SANDBOX_CPUS limit, so the sandbox is a distinct service rather than a subprocess of the agent.

Installing Omni with Docker Compose and running a first permission-scoped query

The README points deployment at three guides: Docker Compose for single-server deployments, the Omni CLI for Docker Compose upgrades and diagnostics, and Terraform for AWS and GCP. There is no published install command in the README itself, and no package on a registry is mentioned, so the entry point is the repository's docker/ and setup/ directories plus the deployment documentation at docs.getomni.co.

Configuration starts from .env.example. The values below are the database and Redis settings as they appear in that file; the defaults assume the Compose network, where the Postgres host is literally named postgres.

DATABASE_HOST=postgres
DATABASE_PORT=5432
DATABASE_USERNAME=omni
DATABASE_PASSWORD=omni
DATABASE_NAME=omni
DATABASE_SSL=false
DB_MAX_CONNECTIONS=10
REDIS_URL=redis://redis:6379

If you run Postgres outside the Compose network, DATABASE_HOST and DATABASE_SSL are the two values you will change first. DB_MAX_CONNECTIONS defaults to 10 with a DB_ACQUIRE_TIMEOUT_SECONDS of 3, which is a small pool for a service that also handles BM25 and vector queries; the file's own comment notes the resource defaults are conservative for a 4-core host.

The service ports are fixed by the same file. The web frontend listens on WEB_PORT=3000, the searcher on 3001, the indexer on 3002, the AI service on 3003 and the connector manager on 3004, with connectors occupying 4001 upward (Google 4001, Slack 4002, Atlassian 4003, and so on through the list).

WEB_PORT=3000
SEARCHER_PORT=3001
INDEXER_PORT=3002
AI_SERVICE_PORT=3003
CONNECTOR_MANAGER_PORT=3004
GOOGLE_CONNECTOR_PORT=4001
SLACK_CONNECTOR_PORT=4002
ATLASSIAN_CONNECTOR_PORT=4003

For a first real use, the README's own example of the workflow is asking Omni to investigate an issue, prepare an update, analyze company data or find information across connected systems from one conversation. Practically, that means connecting one source first (Slack or a filesystem connector are the cheapest to authorise), letting the indexer populate, and then asking a question whose answer you can verify against the source. Grounded answers with citations are a stated feature, so the check is whether the citation points at a document the account you connected can actually open. If it does not, the permission scoping is not working and nothing else in the deployment matters.

Model selection is configuration, not code. The README lists Anthropic, OpenAI, Gemini, AWS Bedrock, Vertex AI, Azure AI Foundry, or any OpenAI-compatible endpoint such as vLLM, Ollama, LM Studio or LiteLLM. The .env.example also exposes LOCAL_EMBEDDINGS_PORT=8001 for local embedding models via TEI, DOCLING_PORT=8003 for document conversion via Docling, and LOCAL_INFERENCE_MODEL_PORT=8000 for a local LLM via llama.cpp.

Where Omni is the wrong tool

Omni is a platform, not a library. If you want to add retrieval to an existing application, adopting a container topology with a connector manager, a searcher, an indexer, a sandbox and a connector per source is disproportionate. The same applies to a single-team deployment: the permission-inheritance machinery exists to reconcile many users against many sources, and one shared mailbox does not need it.

The harder constraint is search. Because BM25 and pgvector both live in ParadeDB, the quality of your retrieval is bounded by how that engine is tuned and by the embeddings you feed it. A team already running a dedicated vector database with tuned recall, or one that needs search features ParadeDB does not implement, will find the "one database" argument a cost rather than a benefit. The README does not discuss migration away from ParadeDB, and no alternative search backend appears in the workspace members.

Version maturity is the other boundary. The workspace package version is 0.1.0 and the most recent release is v0.1.18, pushed on 2026-08-29. Release numbering has moved quickly (v0.1.16 on 2026-08-07, v0.1.17 on 2026-08-28, v0.1.18 on 2026-08-29), which is normal for a young project and also means interfaces can move between releases. The README does not document rollback, and the CLI page is described only as covering "upgrades and diagnostics". If you need a frozen API for a long-lived integration, this is early.

Omni compared with building on LangChain or LlamaIndex

The natural alternative is assembling the same capability from a framework such as LangChain or LlamaIndex and running it yourself. The difference is where the work sits. A framework gives you abstractions for models, tools and retrievers, and leaves connector authentication, per-source permission mapping, incremental indexing, sandbox isolation and the web UI to you. Omni ships those as services with fixed ports and a Compose file. You trade control over the retrieval pipeline for a topology you did not design.

A second comparison is the hosted agent products that connect to the same SaaS tools. Those remove the operational burden entirely, and they also move your indexed company data to a vendor. Omni's answer is the opposite: the README's stated position is "Self-Hosted by Design", running entirely in your cloud, on-premises or in an isolated environment. That is the whole reason to accept the container count.

On extensibility, Omni does not force you inside its own connector set. The README describes connecting MCP tools or building company-specific integrations with the Connector SDKs in Python or TypeScript, and sdk/ appears as a top-level directory with a Rust member in the workspace. The connectors/darwinbox entry is a useful signal: it is a company-specific integration living alongside the general ones.

Maintenance, upgrades and the Apache-2.0 licence

The repository is not archived and the last push was on 2026-08-29, so the project is being worked on now. That says nothing about the durability of the interfaces, and the 0.1.x release cadence suggests you should read release notes before each upgrade rather than assume compatibility. Upgrades are handled through the Omni CLI, which the README scopes to "Docker Compose upgrades and diagnostics". The README does not document rollback, so a downgrade path is something to establish yourself before you upgrade a production instance.

Operationally, the cost is a Postgres instance with the ParadeDB extension, a Redis instance, the core services, and one container per connector you enable. The .env.example sets CPU limits per service, with defaults the file describes as conservative for a 4-core host, and notes to increase them on larger machines. Adding a connector is therefore a small but real resource decision, not a config flag.

Licensing is Apache-2.0 for the workspace, stated in both Cargo.toml and the LICENSE file. That permits commercial use and modification, and it also means you are responsible for the compliance of everything you connect to it. The connectors authenticate against Google Workspace, Microsoft 365, Slack, Atlassian, HubSpot and others; the terms that govern that data are those vendors' terms, not the Apache-2.0 grant. This is not legal advice, and an organisation handling regulated data should have its own counsel review the connector scopes before enabling them.

Editorial conclusion

Adopt Omni if your organisation already runs Postgres and wants agent answers scoped by the permissions of each source system, with connectors isolated in their own containers. Do not adopt it if you need a hosted service, a stable API surface, or a single-binary install: the workspace version is 0.1.0, the connectors each need OAuth credentials, and the README documents no rollback path for the Omni CLI. Before committing, verify that ParadeDB is acceptable as your only search and vector store, and check the docker-compose guide for the resource limits you will need on your host.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes