Ways to use it

Four ways to connect AI to your Odoo.

Same tools, same safety rails — the difference is where your Odoo credentials live and which AI clients you use. Pick the one that matches how private you need to be. The honest one-liner: hosted is for trying it, local is for trusting it.

Start here Option 1

Hosted trial

Use our hosted server and a trial token. Point it at the demo Odoo, or attach your own Odoo from a form. Zero install — the fastest way to see it work, and the only option that works with ChatGPT.

Best forEvaluating quickly; ChatGPT users
CredentialsOn our server, encrypted at rest
Works withChatGPT, Claude, Cursor, our agent
SetupA token + one config line
Option 2

Desktop agent — fully local

Install the erpAIbridge desktop app. It runs the bridge on your own machine and stores your Odoo connection in your operating system's keychain — nothing reaches our servers, and your Odoo needn't be on the internet.

Best forNon-technical users who want it all local
CredentialsYour OS keychain — never sent to us
Works withThe built-in agent (bring your AI key)
SetupInstall, then "Connect your Odoo"
Option 3

Self-hosted bridge

Run the bridge yourself — a single container, or a local command your MCP client launches. Use Claude Desktop, Cursor or Gemini and keep every credential inside your own network. Licensed, verified offline (works air-gapped).

Best forTechnical users wanting privacy + their client
CredentialsYour infrastructure only
Works withClaude, Cursor, Gemini, any MCP client
SetupOne container or one config block
Governed Option 4

Enterprise deployment

A private, secure MCP server inside your infrastructure — on-premise, private cloud, a dedicated appliance, or fully air-gapped. Role-based access, complete audit trail, AI-provider independent, and protected packaging.

Best forCompany-wide, regulated, security-led
CredentialsYour infrastructure, your controls
Works withAny AI model — no vendor lock-in
SetupWe scope and deploy it with you
Compare

All four, side by side.

The one row that decides most of the choice is the second: where your Odoo credentials live. With a dedicated, least-privilege Odoo user, even the hosted option keeps the blast radius small — and the local and self-hosted options remove us from the picture entirely.

1 · Hosted 2 · Desktop (local) 3 · Self-hosted 4 · Enterprise
Where the bridge runsOur serverYour machineYour machine / serverYour infrastructure
Odoo credentials liveOur server, encryptedYour OS keychainYour infrastructureYour infrastructure
Odoo must be internet-reachableYesNoNoNo
Works with ChatGPTYesIf you expose itInside your network
Works with Claude / Cursor / GeminiYes— (built-in agent)YesYes
Setup effortMinutesInstall an appOne container / configWe deploy with you
Audit trailBasicLocalYesFull, centralised
Best forTrying itTrusting it, non-technicalTrusting it, technicalCompany-wide & governed
Not sure? A 30-second guide

Just want to see it work, or you use ChatGPT → Hosted. You use Claude/Cursor/Gemini and want credentials to stay on your machine → Self-hosted. You want an app that handles everything locally → Desktop agent. Company-wide, regulated, or security-led → Enterprise.

The same safety rails on every option

Read-only by default; every change previewed and approved by a person; deletes off; business actions allow-listed; Odoo's own per-user permissions always apply; every action logged. The security architecture doesn't change with the option you pick — only where it runs does.

Get going

Pick a path and connect your Odoo.

Start hosted in minutes, or go fully local — you can always move between them later. Same tools, same safety, your choice of where it runs.