ibl.ai/os: An Open Source Agent Platform That Ships as Web, Desktop and Mobile

A platform for agents, not a chat widget

ibl.ai/os is described as the open-source AI agent platform, and the pitch is one codebase that runs everywhere with your code, your data and any LLM of your choice. The feature list is broad in a way that distinguishes it from a chatbot library. On the build side there are AI agents with configurable LLMs, system prompts, tools and safety filters, collaborative projects with shared context and goals, a canvas area for generating and versioning rich documents alongside the chat, and MCP servers so agents can be extended with Model Context Protocol tool servers. On the data side there is RAG training through uploads, Google Drive, OneDrive or Dropbox connections or a site crawl, web search for grounding, and a deep research mode for extended multi-step reasoning. The topics list calls it an operating system, which is the ambition rather than a description.

Provider choice and the enterprise layer

Two claims in the readme are about control rather than features. The first is any LLM, your choice: you can bring OpenAI, Anthropic, Google, Microsoft, Meta or your own models, and switch providers without rewrites, which matters when a model price change or a policy change would otherwise force a code change. The second is enterprise-ready, with multi-tenancy, SSO, RBAC, Stripe billing and whitelabeling described as built in rather than bolted on later. The security side covers OAuth, OIDC and SAML with granular role-based access. The consequence is that this is closer to an application server for agents than to a library, and the operational surface is correspondingly larger: you are deploying a multi-tenant application with billing and identity, not running a script.

One codebase across seven targets

The platform table lists the targets and how each is delivered. The web version is live at os.ibl.ai in any modern browser. The Chrome build is a side-panel extension that lets you chat with your agents on any page, with its own build config in the package scripts. macOS ships as a signed and notarised universal disk image covering Intel and Apple Silicon, and Windows as an installer for x64 and ARM64. There are native iOS and Android apps in the App Store and on Google Play, and Linux is a native app built from source rather than a packaged download. The readme notes Windows ARM64, older builds and Linux as separate links, so the download matrix is a moving target. A Tauri shell wraps the same Next.js frontend for the desktop builds, which is what the tauri dev, build and mas scripts in the package manifest are for.

Real-time voice and screen sharing through LiveKit

The rich conversation features are specific: voice calls with real-time WebRTC voice chat powered by LiveKit, and screen sharing directly inside a session. WebRTC is the right primitive for it, since it gives you the low-latency media path that a turn-based text API cannot, and the environment file shows a dedicated LiveKit server variable pointing at a wss endpoint. There is also a separate base websocket URL for the application's own realtime channel, which suggests the two realtime concerns, media and application events, are handled by different systems. Analytics sit alongside with usage dashboards, topic analysis, transcripts and financial reporting, and the embed and API surface covers iframe embed mode, custom domains and API keys, which is how the platform is meant to be embedded into someone else's product.

The environment file points at vendor endpoints by default

The environment example is the most useful document in the repository for anyone planning a deployment, and it deserves reading in full. The defaults are not local: the auth URL points at a hosted login service, the API base URL at a hosted API, and there are separate hosts for a legacy learning system, the mentor application, the websocket service, the LiveKit server and a second mentor instance. There is also a platform base domain, a main tenant key and a tenant name. Alongside those sit the feature flags that define what the build does: whether the free trial banner shows, whether analytics and advertising are enabled, whether RBAC is on, whether Stripe billing is enabled, which datasets are disabled, and a training maximum file size. For a self-hosted deployment the URL variables are the ones you must change first, and the flag variables are how you turn off the parts of the hosted product that do not apply to you.

Running it in Docker, and why the patch files are copied first

A compose file is provided and it is deliberately small, with a single web service built from the repository Dockerfile and NODE_ENV set to production. The service joins two networks, one named ibl_local_default and marked external, and one internal bridge network.

version: '3.8'

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      NODE_ENV: production
    networks:
      - ibl_local_default
      - internal-network

The external network is the part that carries the meaning. Because it is marked external, Docker expects it to already exist, which is how the container reaches services running elsewhere on your host, such as a database or a search index that you run outside the compose stack. The Dockerfile is a multi-stage build on node:20 that installs the pinned Node 25.3.0 through the n tool, enables Corepack for pnpm, and copies the package manifest, the lockfile, the workspace file and the patches directory before installing with a frozen lockfile, so the dependency layer caches independently of the source. The Dockerfile comments explain a failure that would otherwise look mysterious. pnpm v10 reads overrides and patchedDependencies from pnpm-workspace.yaml rather than from the pnpm field in package.json, and without that file present a frozen install fails with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH, because the lockfile records overrides the install configuration cannot see. The same applies to the patches directory, since pnpm hashes the patched files at install time, so they have to be copied before the install runs. This is a good example of a build that is more than a two-line Dockerfile, and the comments are the reason a reader can fix it. The build stage also accepts arguments for image patterns, the public base path, a Sentry auth token, the app version and a static asset CDN, and the asset CDN argument switches the build into an immutable hosting mode where the assets are emitted under a versioned path.

The repository layout and the tooling around it

The top level shows a large workspace with an app directory, features, components, hooks, providers, lib, constants, messages and i18n directories, plus extensions for the Chrome side panel and a src-tauri directory for the desktop shell. There are two end-to-end suites, one named e2e and one named e2e-tauri, and the package scripts show the e2e run creating a Playwright auth state for Chrome, Edge and Safari separately, which is the shape you need when the same app runs in three browsers with different session handling. The test stack is Vitest for unit and integration tests with coverage and a UI mode, plus a separate gallery config, and there is a middleware test file at the root next to the middleware itself. Releases are handled by release-it with a commitlint config, and husky is installed as a prepare script for the git hooks.

Licence, release pace and the awkward parts

The licence is MIT, and the readme ties that to the self-hosting claim: no vendor lock-in and full ownership of the stack and of everything flowing through it. The release pace is fast, with v0.172.0 and v0.173.0 both tagged on 2026-10-19, and a desktop app build released the same day, and the last push was on 2026-10-19 as well. That pace is good for a platform that has to track many providers and frameworks, and it is a caution for anyone who self-hosts, since the version you pin will age quickly. The repository also shows some rough edges worth naming before you commit: there are two backup copies of configuration files in the tree, one named next.config.ts.bak and one middleware.ts.bak, and a file named BUGGY_CODE.md at the root. The readme claims SOC 2 Type II for the hosted service, which is a statement about the vendor's operation rather than about the open source artefact.

Editorial conclusion

ibl.ai/os fits an organisation that wants to build and host its own conversational agents with a documented set of enterprise features already in place, and that is prepared to run the platform itself. It is the wrong choice if you need a small assistant and not a platform, since the surface area is large, and the wrong choice if you cannot accept a codebase that ships a hosted commercial service alongside the open source part. Before deploying, read the environment example end to end, because the defaults point at vendor-hosted authentication, API and LiveKit endpoints rather than at your own.

Frequently asked questions

Official sources

1. iblai/os on GitHub
2. License: MIT
3. Project website
4. README
5. Releases