LIFEHUBBER
Theme

AI Resources

Onyx

Onyx is a self-hostable AI workspace for chatting with connected team knowledge, searching internal and web sources, and giving agents tools through built-in actions, OpenAPI, or MCP.

Onyx supports more than 50 connectors and two deployment shapes: Lite keeps the stack smaller for chat and agents, while Standard adds the indexing and background services needed for connector-backed knowledge work. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.

What it is

A workspace around connected knowledge

Onyx combines chat, retrieval, connectors, custom agents, web search, code execution, image generation, and external actions in one interface. It can connect to hosted or self-hosted model providers instead of requiring one model backend.

Why it stands out

The workspace and admin layers meet

Recent v4 releases make long-running answers reconnectable, add per-share permissions and ownership for agents, let searches target connected sources and time ranges, and expose more indexing, audit, authentication, and security controls to admins.

Availability

Public source with two deployment shapes

Readers can inspect the repository, documentation, releases, deployment files, and upgrade notes. Lite mode trims the stack for chat and agents; Standard mode adds the search index and background services needed for connector-backed knowledge workflows.

Why it matters

What makes it useful

Onyx gives teams one place to compare how an internal AI workspace handles source access, long-running answers, agent ownership, model choice, and tool permissions. Durable runs can continue after a browser disconnect, while scoped search and sharing controls make the surrounding workflow easier to inspect than a basic chat-over-documents screen.

Notable points

What stands out

The jump to v4 matters most for existing deployments: Onyx replaced Vespa with OpenSearch, added durable chat runs and per-share agent permissions, expanded search scoping, and moved more authentication and security settings into the admin interface.

Before using

What to review

Choose Lite or Standard from the features and resource requirements, not only the easier install path. The current docs list a much larger minimum stack for Standard because it adds OpenSearch, workers, model servers, Redis, and object storage.

Before moving an older self-hosted deployment to v4, follow the official Vespa-to-OpenSearch migration path through v3. Skipping that migration can require re-indexing connectors and re-uploading Project files.

Map every connector to Private, Public, or Auto Sync Permissions before indexing internal data. Permission syncing is limited to supported connectors and is documented as an Enterprise feature.

Check which tier includes the sharing, authentication, permission, audit, and admin controls the team expects; Community, Business, and Enterprise paths do not expose every feature in the same way.

Review where connected documents, chat history, model requests, web searches, MCP or OpenAPI actions, code execution, credentials, logs, and generated files can travel in the chosen deployment.

Read the current release notes before upgrading customized deployments. Recent v4 releases changed the document index, authentication setup, container images, public API docs default, required secrets, and other deployment settings.

Reader fit

Who may find it relevant

Teams comparing self-hosted AI workspaces for searching connected company knowledge.

Admins who need connector access controls, agent sharing, deployment choices, audit visibility, and model-provider flexibility in the same system.

Builders who want an API, custom agents, MCP or OpenAPI actions, and a public codebase to inspect.

Less relevant for readers who want a no-setup personal chatbot, a single local model runner, or a lightweight document utility.

Editorial note

Why LifeHubber lists it

LifeHubber lists Onyx because it makes the hard parts of a team AI workspace visible in one public project: which sources an agent can search, how long-running work survives a disconnect, who can share or edit an agent, which tools it can call, and what self-hosting actually requires. That gives readers a concrete system to compare before building internal knowledge work around a simpler chat interface.

Source links

Source materials

Reader note

Before relying on this entry

LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.

What to explore next

Compare the workspace, then protect the workflow.

A self-hosted workspace still concentrates documents, prompts, permissions, connectors, and provider choices. Compare another workspace shape and decide what must stay portable outside either system.

Related in LifeHubber

Keep the thread going

Follow the next layer with AI Resources for AI projects with original links and practical caveats, AI Pulse for separate public activity signals from tracked AI Resources and AI Ballot, AI Guides for decision habits for messy AI choices, AI Access for free and low-cost ways to compare AI model access, AI Ballot for a clearer view of what readers are leaning toward, and AI Radar for AI stories that deserve a second look.

See what’s moving