Real-World Use Cases¶

Repository Management Strategies¶

Odoofly supports three strategies for managing Git repositories in your Odoo projects. Each has its advantages depending on the context.

1. Odoo.sh Strategy — Single repo with submodules¶

Best for: Clients with a single "mother" repository that contains all development (custom modules, dependencies, assets) organized via submodules.

Workflow¶

# 1. Create the project (no environment)
of project new --name client --json --yes

# 2. Add the mother repository (SSH)
of repo add git@github.com:client/client-repo.git

# 3. Create the environment (clones mother repo + submodules)
of env new --name main --yes

Resulting project.yml¶

repositories:
  - url: git@github.com:client/client-repo.git
    branch: 18.0

How it works¶

A single url in project.yml pointing to the mother repository
The mother repo contains submodules (git submodule) with all dependencies
Odoofly runs git submodule update --init --recursive automatically after every clone/pull
Ideal when the client already has a defined submodule structure

Production considerations¶

Required: Add an SSH deploy key on the client's GitHub/GitLab for each production server
The deploy key must have access to the mother repository
Submodules pointing to private repositories will also need access via the same SSH key (or separate keys configured via ~/.ssh/config or GIT_SSH_COMMAND)
Advantage: no tokens to rotate, everything revolves around the server's SSH key

# Generate a deploy key on the production server
ssh-keygen -t ed25519 -C "odoofly-prod"
# Add the public key to GitHub/GitLab as a deploy key
cat ~/.ssh/id_ed25519.pub

2. Odoofly Strategy — Individual repos with tokens¶

Best for: Clients where each addon lives in its own repository, or when granular per-repository permissions are needed.

Workflow¶

# 1. Create the project (no environment)
of project new --name client --json --yes

# 2. Add individual repositories with tokens
of repo add https://github.com/client/addons-core.git --token ghp_abc123
of repo add https://github.com/client/l10n_cl.git --token ghp_abc123
of repo add https://github.com/client/migrations.git --token ghp_abc123

# 3. Verify tokens were converted to variables
of repo auth --env main

# 4. Create environment (uses tokens from .env)
of env new --name main --yes

Resulting project.yml¶

repositories:
  - url: https://github.com/client/addons-core.git
    branch: 18.0
    token: ${GIT_TOKEN_CLIENT_ADDONS_CORE}
  - url: https://github.com/client/l10n_cl.git
    branch: 18.0
    token: ${GIT_TOKEN_CLIENT_L10N_CL}
  - url: https://github.com/client/migrations.git
    branch: 18.0
    token: ${GIT_TOKEN_CLIENT_MIGRATIONS}

How it works¶

Each repository is declared individually with its URL and token
of repo add --token <value> automatically converts the token to a ${GIT_TOKEN_<NAME>} variable reference and stores the real value in <env>/.env
of repo auth interactively fills any pending ${VAR} tokens
Tokens are resolved from: shell environment variable → .env file

Production considerations¶

Required: Provide the same tokens in production. Options include:

Export variables in the shell before running Odoofly

export GIT_TOKEN_CLIENT_ADDONS_CORE=ghp_abc123
of env update main --git

Copy the <env>/.env file with tokens to the production server (outside the Git repo since .env is in .gitignore)
Use a secret manager (Hashicorp Vault, GitHub Actions Secrets, etc.) to inject variables before running Odoofly
Advantage: granular permissions per repository (each token can have scope limited to a single repo)
Disadvantage: managing N tokens instead of 1 deploy key

3. Hybrid Strategy¶

Best for: Mixed clients where part of the code is in a mother repo with submodules and part consists of external addons with tokens.

Workflow¶

repositories:
  # Mother repo with submodules (SSH + deploy key)
  - url: git@github.com:client/client-repo.git
    branch: 18.0

  # External addon with token
  - url: https://github.com/thirdparty/invoicing-addon.git
    branch: 18.0
    token: ${GIT_TOKEN_INVOICING}

# Add both
of repo add git@github.com:client/client-repo.git
of repo add https://github.com/thirdparty/invoicing-addon.git --token ghp_xyz

Both strategies coexist without issues. The caveats of each apply: SSH deploy key + token management.

Comparison¶

Aspect	Odoo.sh (SSH + submodules)	Odoofly (tokens)
Setup	One deploy key per server	One token per repo (stored in `.env`)
Permissions	Access to everything the key can reach	Granular per repository
Submodules	Native support	Not applicable (each repo is independent)
Production	Add deploy key on target server	Provide tokens via `.env` or env vars
Rotation	Rotate deploy key (single point)	Rotate each token individually
Ideal for	Single repo with submodules, traditional clients	Multiple addons, distributed teams, CI/CD