odoobot

Bring your fleet

Migrate existing Odoo
without rebuilding by hand.

odoobot ships a real migration pipeline for externally hosted Odoo — whether it lives on a hosting panel, a hand-rolled server, or a mix of both. Clone onto an enrolled host at a temporary hostname, validate, then cut over when you're ready. The source is never modified during the clone.

Get migration accessSee how it works

Why move

Keep the automation. Own the plane.

Your hosts, your margins

Stop paying a middle layer for every instance. Enroll Hetzner, GCP, DO, or bare metal and run density you choose.

Fleet ops, not tabs

Agents, drift, multi-tenant roles, Postgres clusters, and activity history — built for operators, not a single-box panel.

Migration as a workflow

The same dump → provision → restore → surgery → adopt path becomes instance duplication for staging and QA later.

Pipeline

Six steps from external instance to odoobot host.

Runs on the target host. Each step is toggleable so you can resume after a failure — dumps and tars are cached when present.

  1. 01

    Dump

    pg_dump -Fc the source database over SSH into a staging path on the target host. Source stays online.

  2. 02

    Filestore

    Tar the source filestore and extra-addons (enterprise, OCA, custom) so modules and attachments land intact.

  3. 03

    Provision

    POST to the control plane to build a fresh compose stack on the enrolled odoobot host — isolated user, container, proxy.

  4. 04

    Restore

    Restore the dump into the target Postgres, copy filestore in, fix ownership. PG version gaps are handled in the pipeline.

  5. 05

    Surgery

    Set web.base.url, freeze it, disable mail servers and crons so the clone never emails customers or runs jobs.

  6. 06

    Verify & adopt

    Poll /web/login, then adopt the instance into odoobot so it appears in the console with credentials and Studio access.

What you need

Migration checklist

  • SSH access to the source host (key-based)
  • An enrolled odoobot target host with Docker + agent
  • Operator JWT for provision / adopt API calls
  • Unique HTTP port and hostname on the target
  • Time window for validation before DNS cutover
env sketch · target host
INSTANCE_NAME='myinst'
SOURCE_SSH='user@source.example.com'
SOURCE_DB_HOST='10.0.0.5'
LB_SUFFIX='myhost.odoobot.net'
HTTP_PORT='8069'
API_TOKEN='<operator-jwt>'
AGENT_ID='<target-host-agent-id>'

# then on the target:
# migrate-instance.sh

Safety defaults

Clones that don't phone home.

Source untouched

Read-only pull of DB, filestore, and addons. Cutover is a separate DNS decision.

Mail & crons off

ir_mail_server and ir_cron rows disabled so validation never emails clients.

Temporary hostname

Validate at <instance>.<host>.odoobot.net before pointing production domains.

Resumable steps

Re-run with STEPS=restore,surgery,verify,register — cached artifacts are reused.

Migration access

Ready to move an existing instance?

Tell us how many instances you host and which clouds you run. We'll follow up with enrollment and migration options.

No spam. We'll reply with setup options for partners and operators.

Also exploring odoobot generally? Join the early access list.