All projects
OdooForge banner
DevOps · 2026 Open source

OdooForge

Open-source Odoo deployment kit with a Claude-powered support agent, portable across AWS, Azure, DigitalOcean, and local Docker.

Tech stack
Odoo 18 Community PostgreSQL 16 pgvector OCA helpdesk_mgmt Python Groq Anthropic Claude Docker Compose Terraform nginx

The problem

Small and mid-size businesses pick Odoo Community because the licence is free and the feature set rivals SaaS ERPs that charge per seat. The friction is everything around it. Getting it onto a cloud you actually trust, keeping backups, plugging it into modern AI without paying for a second SaaS layer, and not getting locked into one vendor. Most public Odoo repos solve one of these in isolation. None ship the whole stack with AI baked in.

Goals

  • One CLI command stands up the same Odoo stack on AWS, Azure, DigitalOcean, or local Docker
  • Native Odoo addon adds AI customer support that operators can install from the Apps menu
  • Pluggable LLM provider so Groq, Claude, or Ollama is a settings toggle, not a code change
  • Audit log on every AI action, filterable inside Odoo
  • Zero-cost demo target via Oracle Cloud Always Free + Groq free tier

The solution

  • docker-compose foundation with Odoo 18 Community, Postgres 16 with pgvector, and OCA helpdesk_mgmt 18.0 ready to go
  • Custom Odoo addon adds a Draft AI reply button on every Helpdesk ticket
  • Agent retrieves top-k knowledge base articles via pgvector and calls four bound tools (lookup_customer, search_kb, check_order_status, escalate_to_human)
  • Provider abstraction lets the same agent run on Groq (default, free), Claude (when a key is present), or Ollama (fully self-hosted)
  • Every tool call and draft is written to a custom Odoo audit model with a backend filter view
  • Sensible SME defaults: multi-currency, multi-language (English, Urdu, Arabic), Pakistan timezone, Let's Encrypt-ready nginx config, daily pg_dump and filestore backup scripts

My role

  • Solo architect and engineer, requirements to deploy
  • docker-compose stack design and port allocation that avoids conflicts with other local stacks
  • Custom Odoo 18 module with manifest, models, views, and Helpdesk extension
  • Agent loop with Anthropic-style tool use, pgvector retrieval, and audit persistence
  • LLM provider adapter so Groq, Claude, and Ollama share one interface

UI direction

Native Odoo backend the whole way through. The AI flow is one button on the existing ticket form, one chatter thread for the draft, and one new menu for the audit log. Operators do not learn a new app, they get a new button.

User flows

Draft AI reply on a ticket

  1. 1 Operator opens a Helpdesk ticket
  2. 2 Clicks Draft AI reply
  3. 3 Agent retrieves relevant knowledge base articles via pgvector
  4. 4 Agent calls bound tools as needed (customer lookup, KB search, order status, escalate)
  5. 5 Draft reply lands in the ticket chatter for the operator to review and send
  6. 6 Every step is written to the audit log with timestamps and tool inputs

Provider swap

  1. 1 Operator opens OdooForge AI settings inside Odoo
  2. 2 Picks Groq, Claude, or Ollama from a dropdown
  3. 3 Saves; the next ticket action uses the selected provider with no restart

Screenshots

Click any image to open at full size.

Key learnings

  • Odoo's ORM does not natively know pgvector, so vector search has to be raw SQL inside the addon. Documenting that pattern is half the value of the repo.
  • A provider adapter that treats Groq, Claude, and Ollama as one interface keeps the demo fully free while still proving Claude works for paying clients
  • Audit logging as a first-class Odoo model (not just file logs) means operators can filter AI actions the same way they filter any other Odoo record
  • Phase 1 to 3 ship the AI flow on local Docker first; cloud portability is a separate phase, which keeps the build honest and the screenshots truthful

Want something like OdooForge?

I'm open to senior contract work. Let's talk about what you're building.

Get in touch