A module tested in a sandbox is not yours yet until it lives in your repository. This page covers the last steps: versioning, publishing on the Odoo Apps Store if you wish, then going live.

Connecting your repository

Aidoo pushes the code to your GitHub repository. You remain the owner, and nothing depends on Aidoo to read it back or take it over.

Connect GitHub

From Aidoo's GitHub page, an owner or an administrator of the workspace connects the GitHub account that will host your modules.

Pin your Odoo repository

Pick the repository that hosts your Odoo developments, its production branch and, if needed, its staging branch, then "Pin & import modules": the modules already on those branches are imported into Aidoo Modules. Modules created with Aidoo are then pushed there, each in its own folder.

Without a pinned repository, a module's first push creates a private repository dedicated to it. On the "My modules" page, "Resync from GitHub" re-imports the modules of the environment's branch.

Pushing the code

The module works, push it to GitHub.

Claude sends the module's full directory tree, with a commit message describing the change. The "Push to GitHub" button, at the top of the module page, does the same ("Create repo & push" on the first push). What you find in the repository is standard Odoo code: Python models, XML views, access rights files, manifest.

Check where pushes land

An imported module goes back to the branch it came from; a new module goes to the default branch of the pinned repository. If that branch is deployed automatically (Odoo.sh, continuous integration), every push lands there: preferably pin a repository whose default branch is used for development.

Push early, push often

Nothing requires waiting until the module is perfect. Every push creates a restore point, and the Git history tells the module's story far better than the conversation does.

Each version variant (see Creating a module) is pushed to the same repository, on a branch named after its version: 17.0, 18.0… That is the Odoo module convention, the one the Odoo Apps Store reads.

Push the Odoo 18 variant of the module to GitHub.

Publishing on the Odoo Apps Store

The Odoo Apps Store (apps.odoo.com) has no publishing API: it reads the manifest and the static/description/index.html page from a Git repository whose branches carry the version number. The Odoo Store tab of the module page prepares all of that.

Fill in the listing

Tagline, summary, highlights (6 at most), license, price and currency (EUR or USD), website, support, and a user guide of 10 steps at most, each of which can carry a screenshot. These settings are copied into the manifest of every version of the module.

Generate the listing

"Save and generate the listing" writes, in every version, the description page, the main image (1200 × 630 px, drawn from the icon, the name and the tagline, or uploaded) and up to 6 screenshots, taken from the Media gallery or uploaded from your computer. A preview shows the page as it will be published, and it refreshes on its own after every new automatic capture.

Submit to the store

The checklist flags what is missing. Blocking: icon, summary, license, price consistent with the license, description page generated, GitHub connected. Recommended: tagline, guide, main image, screenshots, every version tested, public repository. "Submit to the store" pushes one branch per version, and can make the repository public.

Register the repository on apps.odoo.com

This is the only manual step. Paste the repository URL on apps.odoo.com's repository upload page; if it is private, add the public key shown by Odoo as a read-only "deploy key" in GitHub. Odoo scans the branches and publishes one listing per version: allow a few hours for the first indexing.

Prepare the module's Odoo Apps Store listing, free under LGPL-3, with a step-by-step user guide illustrated with the gallery screenshots.

Paid app, public repository

A paid app must be licensed under OPL-1 (the licenses offered are LGPL-3, OPL-1, AGPL-3 and MIT). Making the repository public exposes all of its content: if your module lives in your main Odoo repository, alongside other modules, prefer the deploy key.

Approval before production

Claude cannot deploy to production

This is a product limit, not a setting. No tool in the Modules connector can install anything on your real Odoo, and neither can Aidoo: going live is a human approval, and the installation is done from your Git repository.

Going live has three cumulative conditions:

the module has been tested on sandbox in its current state
an owner or an administrator of the workspace approves it from the production deployment card, on the Overview tab
your plan allows production deployment, which excludes the free trial

Approval moves the project to the In production status. Any change to a base version file after a test voids the first condition. There is no workaround: that is what guarantees nothing gets approved without having passed through a test instance.

Installing the module on your Odoo

The module is installed like any other Odoo module, from your repository: pull the code into your Odoo's addons path (git pull), update the apps list, then install or upgrade the module. On Odoo.sh, pushing to the production branch is what triggers the build. Odoo then applies the migrations, creates the tables, loads the views and the access rights.

Take a backup first

An Odoo module can create columns and alter views. The operation is reversible in most cases, but a recent backup is the only real guarantee. On Odoo.sh, trigger a manual backup; on your own server, back up the database and the filestore.

Install outside business hours where possible: new Python code requires restarting the Odoo service.

Evolving a module already in production

The cycle starts again identically: you describe the change, Claude edits the files, the project returns to draft, fresh sandbox test, fresh Git push, fresh approval, then the module is upgraded on your Odoo.

Data migrations deserve particular care

Adding a field is risk-free. Renaming or removing a field that already holds production data is not: Odoo does not migrate existing values automatically. Say so explicitly to Claude so it writes the migration script, and test it on a sandbox loaded with a representative data set.

Diagnostics

The sandbox installation fails

That is normal development, not an incident. Claude reads the logs, identifies the Python or XML error, and fixes it. If the same failure returns three times, rephrase the need: the problem usually lies in the request, not the code.

The module installs but nothing is visible

Almost always a mis-targeted view or missing access rights. Check that your user belongs to the expected group, and ask Claude to verify the view inheritance.

The GitHub push fails

Check that GitHub is still connected to the workspace and that the branch exists. A revoked connection can be restored from Aidoo's GitHub page.

The production deployment button does not show

It only shows for a module in the Tested on sandbox status, and only to an owner or an administrator. During the free trial, the approval is refused with a message inviting you to move to the Standard plan.

The store does not find my module

Check that the branches carry exactly the version number (18.0), that the repository is public or the deploy key added, and allow a few hours for the first indexing.

I want to take the module over without Aidoo

That is by design: the code sits in your repository, in standard Odoo format. Clone it, open it in your editor, install it like any module. No dependency on Aidoo remains in the produced code.

Next step

Developing a module from Claude: reviewing the full cycle
Creating a module: starting again from the need