Odoo 18 on Docker

1. What? — Definition and context

Odoo is an open-source ERP (Enterprise Resource Planning) that centralises business data into a single database. This Odoo 18 Community instance runs on Docker, on its own dedicated PostgreSQL, with three custom modules that adapt the ERP to the technical workflow: GitHub sync, Claude Code telemetry, and web experiments for the website.

ERP

An ERP replaces the sprawl of spreadsheets and disparate tools with a unified database. Projects, contacts, invoices, time spent: everything is interconnected and traceable from one place.

Modules in use

Native modules enabled:

Module	Usage
Project	Projects and tasks
Timesheets	account.analytic.line — fed by TimeTrackr
Website	Landing page and hub
CRM	Leads and conversion (to be extended)

Custom modules maintained in odoo-stack/addons/:

Module	Version	Usage
project_github_sync	v18.0.5.6.0	GitHub ↔ tasks sync + Claude Code telemetry + AI double-triage + estimation
website_experiments	v18.0.1.1.0	Interactive snippets (Flip Display, Glass Splat) for the Website Builder
powered_by_odoo_remove	third-party	Removes the “Powered by Odoo” branding on public pages

Database name: `guig_db`

The PostgreSQL database is called guig_db (not odoo like the image default). Every pg_dump, psql, --database, -d command must use it. The historical filestore stays under /var/lib/odoo/filestore/odoo/ because it was created under the previous DB name — do not rename it or ir_attachment references will break.

Business vision

To understand why Odoo was chosen over the alternatives, see Why Odoo.

---

2. Why? — Stakes and motivations

Problems solved

Problem	Odoo solution
Scattered data	Unified base: projects, time, contacts
No GitHub ↔ task traceability	Two-way sync via project_github_sync
Quote estimation by guesswork	x_estimated_hours / x_complexity fields + real actual_hours from timesheets
Manual issue triage	AI double-triage (x_ai_project_triaged_at + x_ai_personal_triaged_at)
Invisible Claude Code effort	Per-session telemetry (project.task.claude.session) with cost, tokens, LOC, TLDR, category
Fuzzy marketing attribution	Source tracking via Website (CV, business card, LinkedIn)

Why Odoo 18 Community (vs Enterprise)?

1. Cost — Enterprise is billed per user/month. Community is free and self-hosted.
2. Custom modules unrestricted — No restriction on installing project_github_sync or website_experiments on Community.
3. Functional sufficiency — The native Project, Timesheets, Website and CRM modules cover current needs.
4. Migration possible — To Enterprise later if advanced modules (eCommerce, Manufacturing) are needed.

Data-driven strategy

End-to-end traceability (lead → project → GitHub issue → Claude + human time spent → real cost) lets future quotes be calibrated on data rather than rough estimates.

---

3. How? — Technical implementation

Network architecture

Docker Compose configuration (excerpt)

services:
  odoo:
    image: odoo:18
    volumes:
      - odoo-data:/var/lib/odoo
      - odoo-config:/etc/odoo
      - ./addons:/mnt/extra-addons
    environment:
      - HOST=odoo-postgres
      - USER=odoo
      - PASSWORD=${ODOO_DB_PASSWORD}
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8069/web/health"]
      interval: 30s
      timeout: 10s
      retries: 3
    networks: [odoo-internal, webproxy]

  odoo-postgres:
    image: postgres:15
    volumes: [odoo-db:/var/lib/postgresql/data]
    environment:
      - POSTGRES_USER=odoo
      - POSTGRES_PASSWORD=${ODOO_DB_PASSWORD}
      - POSTGRES_DB=guig_db
    networks: [odoo-internal]

Health check

The /web/health endpoint returns {"status": "pass"} when Odoo is healthy. Used by Docker for container health and the Monitoring Stack for alerts.

project_github_sync module (v18.0.5.6.0)

The module adds many fields to project.task (plus a dedicated model for Claude Code session history). The fields fall into four families.

GitHub fields (8)

Field	Type	Usage
x_github_sync_enabled	Boolean (on project.project)	Enables sync on the project
x_github_repo	Char	owner/repo source
x_github_issue_id	Integer	Issue / PR number
x_github_url	Char	Canonical GitHub URL
x_github_commit_ids	One2many → project.task.commit	Linked commits (sha, message, author, url)
x_github_commit_count	Integer (compute)	Number of linked commits
x_github_milestone_id	Integer	GitHub milestone number
x_github_parent_issue_id	Integer	Parent issue (sub-issues)

Claude Code telemetry fields (13)

Fed by the SessionEnd hooks (see Claude Code Telemetry).

Field	Type	Usage
x_claude_time_total	Float (h)	Aggregated Claude Code time
x_claude_cost_total	Float ($)	Aggregated cost
x_claude_token_total	Integer	Total tokens (in + out + cache)
x_claude_tokens_input / _output / _cache	Integer × 3	Per-category detail
x_claude_sessions	Integer	Number of sessions
x_claude_lines_added / _removed	Integer × 2	Aggregated LOC
x_claude_last_session	Datetime	Last recorded session
x_claude_cost_by_model	Text (JSON)	Breakdown per model (Sonnet/Opus/Haiku)
x_claude_session_ids	One2many → project.task.claude.session	Session-by-session history
x_claude_category	Selection	Auto category for generic tasks (no issue)

Each project.task.claude.session row captures the detail of a session: ID, timestamps, tokens, cost, LOC, TLDR (short summary generated by the hook) and category. This lets us drill from the aggregate down to the source session.

Effort estimation fields (#188)

Field	Type	Usage
x_estimated_hours	Float	A priori estimate
x_complexity	Selection	Complexity (low / medium / high)

The ground truth comes from timesheets: actual_hours = SUM(account.analytic.line.unit_amount) WHERE task_id = X. The x_claude_time_total attribute is not a substitute — it measures Claude machine time, not human effort. See the Effort Estimator V1 workflow for the cohort-based estimation logic.

-- Paired samples (estimate + actual) for re-calibration
SELECT
    t.id, t.name,
    t.x_estimated_hours,
    COALESCE(SUM(a.unit_amount), 0) AS actual_hours,
    t.x_claude_time_total,
    t.x_claude_sessions
FROM project_task t
LEFT JOIN account_analytic_line a ON a.task_id = t.id
WHERE t.x_estimated_hours IS NOT NULL
GROUP BY t.id, t.name, t.x_estimated_hours,
         t.x_claude_time_total, t.x_claude_sessions
HAVING COALESCE(SUM(a.unit_amount), 0) > 0;

AI double-triage fields (#296)

Field	Type	Usage
x_ai_project_triaged_at	Datetime	Cache of last project-side triage (stage)
x_ai_personal_triaged_at	Datetime	Cache of last personal-horizon triage (Today / This week / …)

The N8N workflow Daily GitHub Issue Triage proposes stage + horizon assignments via codex-yolo, then stores the timestamp to skip re-triaging for 7 days (configurable TTL). The user validates via Telegram (/triage), which POSTs to an internal API that updates Odoo.

website_experiments module

Adds three drag-and-drop snippets to the Website Builder:

• Flip Display: animated split-flap display (airport-style).
• Glass Splat Desktop: 3 side-by-side panels with a fragmented-glass 3D render.
• Glass Splat Mobile: equivalent mobile carousel.

Asset side: CSS + IIFE JavaScript loaded through web.assets_frontend.

Filestore and ir_attachment

The filestore lives in the odoo-data volume, under /var/lib/odoo/filestore/odoo/ (sub-folder named odoo historically, even though the DB is now guig_db). It stores every binary referenced by ir_attachment.store_fname.

Don't blindly clean the filestore

Any unverified purge breaks the website rendering. Four critical categories:

• /_custom/ URLs → theme SCSS assets (broken pages if removed).
• /web/content/ → documents embedded in pages.
• res_model = 'ir.ui.view' → website building blocks.
• res_model = 'ir.attachment' + type = 'binary' → downloadable files.

Backup

Backups are handled by scripts/backup-databases.sh (daily cron at 03:00) which produces:

• pg_dump -U odoo guig_db → SQL archive
• tar czf - -C /var/lib/odoo filestore → filestore archive
• Local rotation (7 d) + GDrive push (30 d) via rclone.

# Manual backup
docker exec odoo-postgres pg_dump -U odoo guig_db > odoo_backup.sql

# Restore
docker exec -i odoo-postgres psql -U odoo guig_db < odoo_backup.sql

# Manual filestore backup
docker exec odoo tar czf - -C /var/lib/odoo filestore > odoo-filestore.tar.gz

N8N integration via XML-RPC

// Task creation from github-project-sync
{
  "url": "http://odoo:8069/xmlrpc/2/object",
  "method": "POST",
  "body": {
    "service": "object",
    "method": "execute_kw",
    "args": [
      "guig_db",                  // database (NOT "odoo")
      2,                          // uid after authentication
      "{{ $env.ODOO_PASSWORD }}",
      "project.task",
      "create",
      [{
        "name": "Issue #123 — Fix bug",
        "project_id": 1,
        "x_github_issue_id": 123,
        "x_github_url": "https://github.com/owner/repo/issues/123"
      }]
    ]
  }
}

XML-RPC

XML-RPC is Odoo’s native protocol for programmatic access. Older than REST but very well supported on the N8N side (a single HTTP Request node is enough). Prefer it over /jsonrpc endpoints for consistency with existing workflows.

Module management

# Install a new module
cp -r my_module odoo-stack/addons/
docker restart odoo
# UI: Apps → Update Apps List → Install

# Update an existing module in place
docker exec odoo odoo -u project_github_sync -d guig_db --stop-after-init

Troubleshooting commands

# Health check
curl http://localhost:8069/web/health

# Odoo logs
docker logs odoo --tail 100

# PostgreSQL connection
docker exec odoo-postgres pg_isready -U odoo
docker exec odoo-postgres psql -U odoo -d guig_db -c "SELECT count(*) FROM project_task;"

# Odoo shell for debug
docker exec -it odoo odoo shell -d guig_db

# Look at recent Claude sessions
docker exec odoo-postgres psql -U odoo -d guig_db \
  -c "SELECT id, name, tldr, category FROM project_task_claude_session ORDER BY id DESC LIMIT 10;"

---

4. What if? — Perspectives and limits

Current limits

Limit	Impact	Mitigation
Community without vendor support	No Odoo hotline	Documentation + community
Single PostgreSQL instance	No native HA	Daily backups + monitoring
Custom modules to maintain	Future Odoo 19+ compatibility	Versioned migrations in migrations/
Effective single user	All telemetry is attributed to a single employee	Multi-user mapping planned via timetrackr_user_mapping if needed

Evolution scenarios

If the estimation pipeline becomes critical:

• Calibrate the V1 → V2 model on paired samples (x_estimated_hours vs actual_hours).
• Extend telemetry to issue-less tasks (already addressed via x_claude_category).

If AI triage gets noisy:

• Lower the cache TTL (currently 7 d) to re-triage more often.
• Filter at the workflow level by project or label.

If invoicing is needed:

• Activate the Invoicing module.
• Connect account.analytic.line to invoices via tasks/projects.

If migrating to Enterprise:

• Audit custom fields and existing migrations.
• Verify project_github_sync compatibility (LGPL-3, should be fine).
• Budget: per-user/month pricing.

---

Related pages

Infrastructure

• VPS Architecture — Overview
• Why Odoo — ERP comparison and choice
• TimeTrackr Stack — Source of account.analytic.line

Workflows

• GitHub-Odoo Sync — Issues / PRs / commits sync
• Claude Code Telemetry — SessionStart / SessionEnd hooks
• Cal.com → Odoo bookings — Calendar integration

Reference

• Glossary — ERP, XML-RPC, ir_attachment