Skip to content

How to Use Git with Odoo (Module Deployment)

DeployMonkey Team · March 11, 2026 8 min read

Deploying Odoo modules by hand — copying files over SSH, hoping nothing breaks — is a recipe for downtime. Git-based deployment brings repeatability, auditability, and automation to your Odoo workflow. This guide covers repository structure, deploy keys, webhook-triggered deployments, and a branching strategy that scales from solo developer to full team.

Why Use Git for Odoo Module Deployment?

  • Rollback in seconds: git revert or checkout a previous tag to undo a bad deploy.
  • Audit trail: Every change is attributed to a commit, making debugging easier.
  • Team collaboration: Pull requests enforce code review before changes reach production.
  • Automation: Webhooks trigger deploys on push, eliminating manual steps.

Repository Structure

Keep all your custom modules in a single repository. Each subdirectory is one Odoo module:

your-odoo-modules/
├── .git/
├── requirements.txt          # pip dependencies for all modules
├── my_custom_crm/
│   ├── __manifest__.py
│   ├── __init__.py
│   ├── models/
│   ├── views/
│   └── security/
├── my_stock_extension/
│   ├── __manifest__.py
│   └── ...
└── shared_utils/
├── __manifest__.py
└── ...

Alternatively, use a mono-repo approach with one module per repository for independent versioning. The single-repo approach is simpler for most teams.

Step 1 — Create a Deploy Key

A deploy key is an SSH key pair associated with a specific repository. The server uses the private key to pull code; the public key is registered in the repository settings.

# On your Odoo server
ssh-keygen -t ed25519 -C "odoo-deploy" -f ~/.ssh/odoo_deploy_key -N ""
cat ~/.ssh/odoo_deploy_key.pub

In GitHub: go to your repository → Settings → Deploy keys → Add deploy key. Paste the public key. Keep Allow write access unchecked — read-only is sufficient for deployment.

Configure SSH to use this key for your repository host:

# ~/.ssh/config
Host github.com
IdentityFile ~/.ssh/odoo_deploy_key
IdentitiesOnly yes

Step 2 — Clone and Configure addons_path

cd /opt/odoo/custom
git clone [email protected]:yourorg/your-odoo-modules.git modules

Add /opt/odoo/custom/modules to addons_path in odoo.conf. See the Odoo configuration guide for full config file reference.

Step 3 — Webhook-Triggered Auto-Deploy

A deploy script handles the pull, module upgrade, and server reload. Create /opt/odoo/deploy.sh:

#!/bin/bash
set -e
MODULES_DIR="/opt/odoo/custom/modules"
ODOO_DB="production"
MODULES_TO_UPGRADE="${1:-}"

echo "Pulling latest code..."
cd "$MODULES_DIR"
git pull origin main

if [ -f requirements.txt ]; then
  echo "Installing pip dependencies..."
  /opt/odoo/venv/bin/pip install -r requirements.txt -q
fi

if [ -n "$MODULES_TO_UPGRADE" ]; then
  echo "Upgrading modules: $MODULES_TO_UPGRADE"
  sudo systemctl stop odoo
  /opt/odoo/venv/bin/python /opt/odoo/src/odoo-bin \
-c /etc/odoo/odoo.conf -d "$ODOO_DB" \
-u "$MODULES_TO_UPGRADE" --stop-after-init
  sudo systemctl start odoo
else
  sudo systemctl restart odoo
fi

echo "Deploy complete."

Make it executable: chmod +x /opt/odoo/deploy.sh. Wire it to a webhook receiver (e.g., a small Flask app or GitHub Actions self-hosted runner) that calls this script on push events.

Step 4 — Branching Strategy

A three-branch strategy maps directly to your Odoo environments:

BranchEnvironmentPurpose
devLocal / dev serverActive development, breaking changes OK
stagingStaging instanceQA and user acceptance testing
mainProductionStable, tagged releases only

Workflow:

  1. Feature branches are cut from dev and merged back via pull request.
  2. When a sprint is complete, merge devstaging. The webhook deploys to staging automatically.
  3. After QA sign-off, merge stagingmain and create a version tag: git tag v1.4.0 && git push origin v1.4.0. The production webhook deploys on tag push.

Step 5 — Rolling Back a Bad Deploy

# Option 1: Revert the last commit
git revert HEAD
git push origin main

# Option 2: Hard reset to a known-good tag
git reset --hard v1.3.2
git push origin main --force

# Option 3: Checkout a specific commit on the server
cd /opt/odoo/custom/modules
git checkout abc1234
sudo systemctl restart odoo

Always keep a database backup before upgrading modules. DeployMonkey takes automatic S3 backups before every deployment.

Git Deployment on DeployMonkey

DeployMonkey has Git deployment built in — no deploy scripts to maintain:

  • Connect your repository from Instance Settings → Git Integration. DeployMonkey generates and registers the deploy key automatically.
  • Choose the branch to track (e.g., main for production).
  • Push to the tracked branch; DeployMonkey pulls, installs pip requirements, upgrades listed modules, and reloads the server — all without downtime on supported plans.
  • Every deployment is logged with the commit SHA for full auditability.

FAQ

Should I store my Odoo database in Git?

No. Never store database dumps in Git. Use a dedicated backup solution (S3, local snapshots) for database backups. Git is for source code only.

Can I use GitHub Actions for Odoo deployment?

Yes. Use a self-hosted runner on your Odoo server or use SSH actions (appleboy/ssh-action) to trigger your deploy script remotely on push to main. This gives you CI checks before deployment.

How do I handle database migrations in Git workflows?

Odoo handles schema migrations automatically when you run -u module_name. For data migrations, use Odoo's pre/post migration scripts in a migrations/ directory inside your module.

What files should I add to .gitignore for an Odoo module repo?

Add: *.pyc, __pycache__/, *.pot (compiled translations), .DS_Store, and any local config files with credentials. Keep i18n/*.po files if you maintain translations.

Automate Your Odoo Deployments

Stop copying files by hand. DeployMonkey's Git integration gives you automated, auditable deployments on every plan — starting free. Connect your repo and deploy in minutes.