HDMSOFT

Visit our page

Official Documentation

RKD as ROCKETDOO

Odoo Development Framework

Made with passion, not just programming skills.

Developed by:

• "Horacio Montaño"

Version:

• "3.7.0"

Simple Description:

RKD, also known as ROCKETDOO, is version 3 of the framework designed for assisted and automated deployment of development environments. In this version, unlike its predecessor, it no longer depends on a repository. In other words, it is no longer necessary to create a repository from a template — the framework is now fully independent.

Developers simply need to install the framework on their local machines using either the pip or pipx package managers. The latter is the recommended option, as it allows installing the framework globally on the developer’s system without dealing with Ubuntu and Debian security restrictions that prevent the direct use of pip install. To achieve this, we provide the following two installation options:

Ensure you have pip installed, or pipx if necessary.

 pip install rocketdoo  --break-system-packages

or

 pipx install rocketdoo

• This development environment is intended for those developing on Linux operating systems, such as Ubuntu, Debian, etc. However, for those who prefer to develop on Windows, we suggest installing WSL2, the Windows Subsystem for Linux.

• To use this framework, it is essential to have Docker, Docker Compose, and Git installed.

• ROCKETDOO version 2 now includes its own execution commands, meaning it is no longer necessary to remember or manually use Docker or Docker Compose commands, as the framework effectively replaces the most essential ones.

• Starting from this version, there is no need to use the previous repository as a template to build your environment. Simply by installing the framework, you can create your own directories where the Odoo development environment will be applied.

• In version 2, you can use either the command rocketdoo or its alias rkd for greater convenience and agility.

• Gitman is used for downloading and installing external repositories.

• Make sure you have Docker and Docker Compose installed on your computer. If not, you can follow the official Docker installation guide, Docker Installation Guide.

Comand Line

Below we will list the commands that make up the new version of rocketdoo

 rocketdoo --version

 rocketdoo --help

 rocketdoo scaffold

 rocketdoo init

 rocketdoo info

 rocketdoo up

 rocketdoo up -d

 rocketdoo status

 rocketdoo logs

 rocketdoo stop

 rocketdoo pause

 rocketdoo down

 rocketdoo down -v

 rocketdoo build

 rocketdoo deploy

 rocketdoo mail on

 rocketdoo mail off

 rocketdoo mail status

 rocketdoo mail open

 rocketdoo traefik on

 rocketdoo traefik off

 rocketdoo traefik status

 rocketdoo traefik guide

 rocketdoo instance init

 rocketdoo instance deploy --env stage

 rocketdoo instance deploy --env prod

 rocketdoo instance status

 rocketdoo gui

 rocketdoo gui --port 9090

 rocketdoo gui --open

INSTRUCTIONS:

1. From your Linux or WSL2 terminal, install the framework using one of the following commands:

   pip install rocketdoo --break-system-packages

or

 pipx install rocketdoo

Make sure you already have pip or pipx installed.

2. Once the framework is installed, navigate to your preferred working directory and create a new directory for your development environment.

3. Inside your development directory, you can start by running the scaffold command. This command will automatically create all the necessary files and directories required to deploy your Odoo development environment.

4. Next, you can launch the setup wizard using the init command. This command will prompt you for all the necessary information to configure your environment. The questions include:

• Project name

• Odoo version (a list from version 15 to 20 is available for selection)

• Odoo edition (options include Community and Enterprise)

• Whether to use private repositories (for your own developments; it will list your SSH keys connected to your repositories)

• Whether to use third-party repositories (if you answer YES, it will prompt you for the URLs of each repository or repository package)

• PostgreSQL version (selectable option)

• Odoo Master Password (for database creation)

• Container restart policies (selectable option)

• Odoo port (with port validation)

• Visual Studio Code debug port (with port validation)

Port validation checks whether the selected ports are already in use by another instance or service. If so, it suggests alternative ports or allows you to set them manually

5. Once the setup wizard is completed, you can start the deployment with:

rocketdoo up

or

 rocketdoo up -d

or

 rkd up -d

The -d flag runs the deployment in detached mode.

6. After the environment has been successfully deployed, you can access Odoo from your preferred web browser using:

• http://localhost:8069

or the port you selected during setup.

7. You can check all environment details using:

rocketdoo info

This command displays detailed information about the current environment in your working directory.

8. From this point on, you can begin developing with Visual Studio Code by opening the environment’s directory in your editor.

9. A partir de este momento ya puedes comenzar a desarrollar con Visual Studio Code, abriendo en el editor de codigo, el directorio de este ambiente!

Remember that the addons folder is intended for your own developments, but you can also place standalone modules there if needed.

11. You can also use the available ROCKETDOO commands to stop, pause, remove, or clean up the environment’s containers and volumes, or to view logs.

In this version of ROCKETDOO, you can use either the command rocketdoo or its alias rkd.

Suggestions and Considerations:

• We recommend using Visual Studio Code Extensions, such as Docker, Dev Container, and any others you find useful for working in VSCode.

• If you are developing on Windows with WSL2, it is recommended to use the WSL:Ubuntu extension in Visual Studio Code for optimal integration and performance.

• If you wish to develop in the Enterprise edition, Rocketdoo will ask you, and will make the necessary configurations. However, you should ensure that you have the "enterprise" folder with all the modules and place it in the root of this project.

• This development framework allows you to use private repositories for your developments. For this, the system will ask you if you want to use “private repositories” and if your answer is YES, it will map your local user folder “~/.ssh/” and ask you to choose which ssh key to use. Don't worry, these private keys are not saved in your repository after the commit and push; it simply stores them locally and inside the development docker container. Remember that your selected key must be previously configured with your GitHub repository. This private information is as ephemeral as your environment.

HOW TO ADD MORE MODULES TO GITMAN IF YOU DID NOT DO IT WITH THE LAUNCHER?

• If you need to use third-party addons after setting up your development environment with our launcher, you’ll need to manually edit the gitman.yml file and also add lines to the odoo.conf addons_path using:

  sudo nano gitman.yml

and complete each line, starting with the repository URL and version, according to your development deployment version. You’ll need to replicate the set of lines to add more third-party repositories.

If you need help, you can refer to the gitman official guide.

• In this example, you can see how to add your new module package paths.

Example: addons_path: usr/lib/python/dist-packages/odoo/extra_addons/,usr/lib/python/dist-packages/odoo/external_addons/account-financial-tools

• Gitman creates a folder containing all declared modules under external_addons, which can be found inside your Odoo web container at the path declared in odoo.conf.

• All paths should be separated by a comma ","

New in Version 3: Mail, Traefik & Instance Deployment

rkd mail — Email Testing with Mailpit

Rocketdoo v3 integrates Mailpit, a local SMTP testing server. All emails sent by Odoo are captured in Mailpit's web UI instead of reaching real inboxes.

rkd mail on      # Enable Mailpit (SMTP on port 1025, Web UI on port 8025)
rkd mail off     # Disable Mailpit and restore Odoo mail settings
rkd mail status  # Check if Mailpit is active
rkd mail open    # Open http://localhost:8025 in your browser

Mailpit is toggled by commenting/uncommenting its service block in docker-compose.yaml using special markers (# rkd:mailpit). When enabled, Odoo's SMTP configuration is automatically updated to route emails through Mailpit.

rkd mail on/off also write a Mailpit (rkd) record straight into the project's ir.mail_server table (Odoo's technical settings, Outgoing Mail Servers), so emails are captured with no extra manual setup. on creates or reactivates that record with sequence = 1; off archives it (never deletes it), leaving any of your own mail servers untouched. With a single database this is automatic; with more than one, pass --db NAME to on, off, or status — with several databases and no --db, nothing is written or read and the command tells you to re-run with it. If the db container isn't reachable (project stopped, Docker not running), the rest of the command still runs and it reports the reason; re-running rkd mail on once the project is up fixes it.

rkd mail status shows this record's state (active, archived, not created yet, or not checked, with the reason) plus any other active ir.mail_server in the database. A sequence = 1 on the Mailpit record does not guarantee it captures every email: Odoo's server selection filters by from_filter before it sorts by sequence, so a server you (or a restored production dump) already have, with a from_filter matching the sender, can still win even with a higher sequence number. mail status warns loudly when another active server has sequence <= 1 (it can win the sequence tie-break outright), and with a softer note whenever any other server is active at all, since from_filter can override sequence regardless.

rkd traefik — Traefik Reverse Proxy

Integrate Traefik v2 as a reverse proxy for your development or production environment. Supports two modes:

• local: HTTP only, use with /etc/hosts
• production: HTTPS with automatic Let's Encrypt certificate

rkd traefik on     # Interactive wizard — choose local or production mode
rkd traefik off    # Remove Traefik integration
rkd traefik status # Show current Traefik configuration
rkd traefik guide  # Show /etc/hosts setup instructions for your OS

Every answer the wizard asks for can be given up front, so the command runs unattended:

rkd traefik on --mode local --domain myodoo.local
rkd traefik on --mode production --domain odoo.example.com --email ops@example.com

Traefik is configured via a generated docker-compose.override.yml (Docker Compose merges it automatically). Disabling Traefik simply deletes the override file — your original docker-compose.yaml is never modified.

Enabling Traefik starts the proxy and restarts your project so the new override takes effect — from the CLI and, since 3.6.0, from the web GUI too. To reconfigure an already-enabled project, run rkd traefik off first.

rkd instance — Full Odoo Instance Deployment to VPS

Deploy a complete Odoo instance (stage and/or production) to a remote VPS. Supports two deployment strategies:

• Docker (recommended): Transfers files and builds the Docker image directly on the VPS using BuildKit SSH agent forwarding for private repositories.
• Native: Installs Odoo via official nightly packages (apt), configures /etc/odoo/odoo.conf, and manages it as a systemd service.

rkd instance init                    # Interactive configuration wizard
rkd instance deploy --env stage      # Deploy to staging environment
rkd instance deploy --env prod       # Deploy to production environment
rkd instance deploy --env stage --dry-run  # Preview without executing
rkd instance status                  # Show configured environments

Authentication options:

• SSH key: select from keys listed in ~/.ssh/
• Password: stored as environment variable reference (${INSTANCE_PROD_PASSWORD})

PostgreSQL resource profiles: small (<2 GB RAM), medium (4–8 GB), large (16+ GB)

Odoo tuning by environment:

• Stage: 2 workers, log_level = info, 1.5 GB memory limit
• Production: 4 workers, log_level = warn, 2.5 GB memory limit, proxy_mode = True, list_db = False

Note: Docker deployment requires a running SSH agent with the relevant keys loaded (ssh-add -l). Password authentication requires sshpass installed on your local machine; the password itself travels through the SSHPASS environment variable (sshpass -e), never as a command-line argument visible to other processes on the same host.

rkd gui — Web GUI Interface

Rocketdoo v3 includes a professional web-based management interface, accessible from your browser just like Odoo — no installation of additional tools required.

rkd gui                  # Launch GUI, prints a tokenized URL to open
rkd gui --open           # Also open that same URL in the browser automatically
rkd gui --port 9090      # Use a custom port
rkd gui --cwd /my/proj   # Point to a specific project directory

rkd gui prints a URL of the form http://127.0.0.1:8070/?token=<session-token> — use that exact URL, not a bare http://localhost:8070. Every API and WebSocket call requires this session token (generated fresh on each rkd gui start), so opening the GUI without it shows a message asking you to use the printed URL instead of the project's data. --open already opens the correct, tokenized URL for you.

The GUI provides a complete visual interface for all Rocketdoo v3 features:

Additional interface features:

• Dark / Light mode toggle — follows your system's preference until you pick one explicitly; that choice then persists in localStorage
• Spanish / English switch — in the top bar, remembers your choice, defaults to your browser's language on first run
• A persistent top bar shows the active project and how many containers are running, on every screen
• Real-time log streaming via WebSocket
• Runs entirely from the installed package — no Node.js or build step required

The GUI server runs locally and is bound to 127.0.0.1 by default, so it is only accessible from your own machine. The session token adds a second layer on top of that: even another process running as your own user on the same machine cannot call the API without it. See SECURITY.md for the full threat model.

New in Version 3.5: generated CI and nested addons

rkd ci — CI for your own project

rkd ci init writes a GitHub Actions workflow to .github/workflows/rkd-ci.yml, parameterised from the project you already have — it reads your Dockerfile and compose file, so nothing extra has to be recorded anywhere.

rkd ci init                          # asks how often the expensive job runs
rkd ci init --install-trigger never  # or decide up front
rkd ci init --force                  # overwrite a workflow you have edited

Two jobs. Lint runs ruff over addons/ plus rkd deploy validate, on every pull request, on pushes to the default branch, and on manual dispatch. Install boots the project's own compose file and runs odoo -i <your modules> --stop-after-init against a real Odoo, which is what catches a broken manifest or a missing dependency.

Only your modules are involved: ruff only reads addons/, and third-party code cloned by Gitman lands in external_addons/, so it is never linted or installed by the workflow.

About Actions minutes. Public repositories get unlimited standard runner minutes. Private ones share 2,000 minutes a month across the whole account on the Free plan, and the install job costs a few minutes per run, so it defaults to running only on pull requests against your default branch:

The job is also skipped for Enterprise projects and for projects whose Dockerfile clones private repositories over SSH — a public runner has neither the subscription nor the key. The generated file says so in a comment.

Running rkd ci init again never overwrites a workflow you edited: it reports the file as modified and leaves it alone unless you pass --force.

rkd ci prepare — make a fresh clone buildable

config/odoo.conf and odoo_pg_pass are gitignored because they carry credentials, but the Dockerfile copies config/odoo.conf into the image. A clean clone of a teammate's project therefore fails to build with "/config/odoo.conf": not found.

git clone <your project> && cd <your project>
rkd ci prepare
rkd up -d

prepare regenerates only what is missing — an existing odoo.conf is never touched, so your own master password survives. Useful in CI, and useful to anyone onboarding onto an existing project.

The GUI is readable in daylight

The web GUI now follows your system's light/dark preference by default (falling back to light if the system has none) and meets WCAG 2.1 AA: 4.5:1 for text and icons, and 3:1 for the borders that are the only thing identifying a control, such as inputs and ghost buttons. Badges and pills are checked against the translucent tint they actually sit on, not against the surface underneath it.

Every colour is a CSS custom property declared in three theme blocks — the light default, prefers-color-scheme: dark, and the explicit dark toggle — so the two themes cannot drift apart. Anything clickable is a real <button> or a link with an href, which is what puts it in the browser's tab order and makes the focus outline meaningful.

Modules in subdirectories now work

Odoo's addons_path is a static list of directories, so a module at addons/oca/my_module was invisible to Odoo unless that subdirectory was listed too. It did not fail loudly: Odoo logged Modules loaded and exited 0 with the module simply absent, which is why the GUI's per-module Update button did nothing for them.

rkd up, the GUI's Up button and the GUI's Update button now sync the addons_path before starting, and rkd info warns when it is out of date. Existing projects are fixed in place on the next rkd up — nothing to recreate. The merge only ever rewrites the addons_path line and preserves entries it does not manage, such as enterprise or Gitman's external_addons.

New in Version 3.6: language switch and a clearer GUI hierarchy

The GUI now speaks Spanish and English

A button in the top bar switches the whole interface between Spanish and English without a reload. The choice is saved in localStorage; the very first time, it follows your browser's own language (Spanish if it starts with es, English otherwise). Only interface text is translated — Docker logs, addon names and versions, container and image names, and the raw status text Docker itself reports (Up 3 hours) stay exactly as the system produces them.

One highlighted action, project context on every screen

A persistent top bar now shows the active project and how many containers are running on every screen, not just the Dashboard. The four metric cards that used to sit at the top of the Dashboard (Odoo version, PostgreSQL version, port, container count) became compact tags next to the project name, and the container table moved into the space they freed up. On the Dashboard, exactly one button is ever shown filled with colour: "Open Odoo" (in the top bar) when the Odoo container itself is running, "Start All" when it isn't. The other nine screens still show their own primary actions — the top bar's "Open Odoo" is a global shortcut, not a claim that every screen has only one highlighted button.

Keeping secrets out of git

A Rocketdoo project keeps credentials on disk: the SSH private key copied into the build context, the PostgreSQL secret, and the Odoo master password written into config files. rkd scaffold and rkd init therefore always write a .gitignore covering them:

An existing .gitignore is never overwritten — your own rules are kept and only the missing entries are appended. rkd info warns when a project is missing coverage; run rkd scaffold in it to fix it.

config/odoo.conf is ignored because rkd init regenerates it and it carries the master password. If your team needs to version it, commit a sanitized copy as config/odoo.conf.example.

Instance secrets and re-deploys

rkd instance deploy needs its passwords to stay the same across deploys. PostgreSQL only applies the password while initialising its data directory and ignores it afterwards, so a fresh password on a later deploy would leave Odoo unable to authenticate against its own database.

Both the PostgreSQL password and the Odoo master password are therefore generated once and stored in .rkd/secrets/instance_<env>_db.env (mode 600, git-ignored). Later deploys reuse them, so re-deploying is safe and the passwords stay recoverable:

cat .rkd/secrets/instance_stage_db.env

If an environment was first deployed with Rocketdoo ≤ 3.1.6, the password already on the VPS is adopted automatically and stored locally on the next deploy — no manual step needed.

Recovering an environment already broken by the old behaviour: the database keeps the password from its first deploy, which was not saved anywhere. Reset the role on the VPS and let the next deploy take over:

# on the VPS, inside <remote_path>/<env>/
docker compose exec db psql -U <db_user> -c "ALTER ROLE <db_user> PASSWORD '$(cat odoo_pg_pass)';"

Security

Rocketdoo is a local, single-user development tool, not a hardened multi-user service. See SECURITY.md for the threat model: what the GUI exposes, where credentials live on disk, and the residual risks that are accepted rather than solved.

Technical Support

• If you have any questions or issues with our development environment, you can contact us and submit your inquiry or support ticket by clicking on the link below.

• Support Link

• If you like this project, and you want to collaborate with a donation, you can do it here !!!

• Cafecito

• Patreon