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 revertor 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:
| Branch | Environment | Purpose |
|---|---|---|
dev | Local / dev server | Active development, breaking changes OK |
staging | Staging instance | QA and user acceptance testing |
main | Production | Stable, tagged releases only |
Workflow:
- Feature branches are cut from
devand merged back via pull request. - When a sprint is complete, merge
dev→staging. The webhook deploys to staging automatically. - After QA sign-off, merge
staging→mainand 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.,
mainfor 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.