This is a foundation document for candidates and every new KomITi engineer. It teaches the infrastructure layer from scratch — not through abstract toy examples, but through the real KomITi AWS/Terraform/Docker context.
The purpose is not to turn you into a cloud/platform specialist in 4 hours, but to give you an operational mental model:
docker compose do,By the end of this document you will understand the full infra stack, and in the hands-on lab (section 6) you will bring up the Odoo runtime that serves as the foundation for all future tutorials.
When we say “infra” in this repo, we don’t mean a single tool, but multiple layers working together:
docker compose,The professional thinking here is:
AWS (Amazon Web Services) is a cloud platform — a collection of on-demand computing services (servers, storage, networking, databases, and more) hosted in Amazon's data centres worldwide. Instead of buying and maintaining physical hardware, you rent exactly the resources you need and pay only for what you use.
In this learning context, you don’t study AWS as a catalog of 200 services, but as a minimal operational set which is:
EC2: the virtual machine where the runtime actually lives — in KomITi, a single host carries the entire runtime layer,VPC / subnet: network space and segmentation — part of production safety, not a side detail,EIP (Elastic IP): a stable public IP address — how other systems reach the host as a stable endpoint,S3: the object storage layer for backups and operational artifacts, decoupled from the VM lifecycle,Route 53 / DNS thinking: how a domain reaches the right host,Docker is a platform for building, shipping, and running applications inside containers. Solomon Hykes created it in 2013 at dotCloud to solve the "works on my machine" problem by packaging an application with everything it needs to run.
A container is an isolated runtime process with its own filesystem view, network namespace, and agreed-upon entrypoint — not a virtual machine. Containers build on Linux kernel features (cgroups and namespaces) that date back to 2006–2008, but Docker made them practical and accessible.
You need to know these concepts:
docker compose — a declarative YAML description of multiple services working together.In the KomITi stack you will encounter these patterns early:
docker compose is the contract that defines how these services live together.Once you understand the Docker concepts, the next question is: where do those decisions live in the odoo4komiti repo?
This is the Docker equivalent of the Terraform file map in section 4: you do not read the repo as a random folder dump; you read it by responsibility.
docker-compose.ymldocker-compose.yml is the entry point of the local Docker stack. Docker Compose was introduced by Docker in 2014 so teams could define a multi-container application in one YAML file.
In odoo4komiti, this file answers the practical runtime questions:
odoo-web and db) and which image each service uses or builds,services:
odoo-web:
build:
context: . # build context = repo root
dockerfile: Dockerfile.odoo # custom Dockerfile (adds boto3 to stock Odoo image)
image: odoo:19.0-boto3 # tag for the built image
db:
image: postgres:16 # official PostgreSQL 16 image from Docker Hubodoo-web:
ports:
- "8069:8069" # host:container — access Odoo at localhost:8069
db:
ports:
- "5432:5432" # host:container — expose PostgreSQL to host (dev convenience)odoo-web:
volumes:
- odoo-data:/var/lib/odoo # filestore, sessions (named volume)
- ./config/${ODOO_CONF_FILE:-odoo.conf}:/etc/odoo/odoo.conf:ro # Odoo config file (read-only bind mount)
- ./custom-addons:/mnt/extra-addons:rw # your custom modules (bind mount)
- ./third-party-addons:/mnt/third-party-addons:rw # OCA / community modules (bind mount)
db:
volumes:
- pg-data:/var/lib/postgresql/data # database files (named volume)odoo-web:
environment:
AWS_ACCESS_KEY_ID: # passed from host; used for S3 backups (not needed locally)
AWS_SECRET_ACCESS_KEY: # passed from host; used for S3 backups (not needed locally)
AWS_DEFAULT_REGION: # passed from host; used for S3 backups (not needed locally)
HOST: db # network alias of the postgres service
PORT: 5432 # default PostgreSQL port
USER: odoo # must match POSTGRES_USER in db service
PASSWORD: odoo123 # must match POSTGRES_PASSWORD in db service
db:
environment:
POSTGRES_DB: postgres # bootstrap DB for server start; will be unused after admin creates its own
POSTGRES_USER: odoo # PostgreSQL superuser; Odoo connects as this user for ALL database operations
POSTGRES_PASSWORD: odoo123 # must match PASSWORD in the odoo-web serviceodoo is a community convention used in every official Odoo Docker example — changing it does not add real security (that is security through obscurity). What matters is a strong password. In production, replace odoo123 with a long random string; the username can stay odoo.
┌─────────────────────────────────────────────┐
│ odoo service │
│ │
│ environment: │
│ HOST: db ─────────────────────────┐ │
│ PORT: 5432 ───────────────────┐ │ │
│ USER: odoo ───────────────┐ │ │ │
│ PASSWORD: │ │ │ │
│ komiti-library-dev-local│ │ │ │
│ │ │ │ │
└──────────────────────────────┼───┼───┼──────┘
│ │ │
must match ══════╪═══╪═══╪══════
│ │ │
┌──────────────────────────────┼───┼───┼──────┐
│ postgres service │ │ │ │
│ ▼ ▼ ▼ │
│ environment: │
│ POSTGRES_USER: odoo ◄─────┘ │ │ │
│ POSTGRES_PASSWORD: │ │ │
│ komiti-library-dev-local ◄──┘ │ │
│ POSTGRES_DB: postgres │ │
│ │ │
│ listens on port 5432 ◄─────────────┘ │
│ │ │
│ networks: │ │
│ library-dev: │ │
│ aliases: │ │
│ - db ◄────────────────────────┘ │
│ │
└─────────────────────────────────────────────┘
odoo-web:
depends_on:
db:
condition: service_healthy # Odoo waits until pg_isready passes before startingIf you want to understand why Odoo appears on localhost:8069, why Postgres is on 5432, why the filestore survives a container restart, or why Odoo waits for the database healthcheck, docker-compose.yml is the first file you should read.
A junior mistake is to leave too much at the default value. If you want to increase security, the first things that must change are:
.env, and do not treat a development Docker Compose file as a production security baseline.Dockerfile.odooDockerfile.odoo defines the custom image for the Odoo service. A Dockerfile was introduced with Docker itself in 2013 so an image build could be described as code instead of manual shell steps.
In this repo, Dockerfile.odoo starts from the official odoo:19.0 base image, switches to root, installs python3-boto3, and then switches back to the odoo user. That tells you something important about responsibility:
docker-compose.yml says how services run together,Dockerfile.odoo says what the Odoo image contains before the container starts.If a Python package is missing inside the Odoo container, that is usually a Dockerfile.odoo question, not a Compose question.
.env and config/*.conf.env provides local environment variables for Docker Compose. In this repo it selects which Odoo config file to mount and can also provide AWS-related variables needed by the local runtime. Because these values can be sensitive and machine-specific, .env is local-only and must not be treated like normal committed source code.
The config/ directory holds the Odoo application configuration itself:
odoo.conf — the shared/default config,odoo.local.conf — your local override,odoo.local.conf.example — the template you copy when setting up a machine.The short mental model is: .env decides which config and variables the container receives; config/*.conf decides how Odoo behaves after it starts.
Terraform is an infrastructure-as-code (IaC) tool — you describe the infrastructure you want in code, and the tool builds it for you. HashiCorp released it in 2014 to give teams a single declarative language for provisioning resources across any cloud provider.
The core loop:
.tf files. In the KomITi stack, both DEV and PROD environments are defined this way, not through the AWS console.terraform plan shows exactly what will change before anything touches production.terraform apply executes the plan.terraform.tfstate records what Terraform owns. You will find it on your local disk (not in git), e.g. infra/aws/odoo-dev-ec2-compose/terraform.tfstate.A provider is a plugin that enables Terraform to communicate with a given system. In this repo, the most important one is the AWS provider — Terraform by itself doesn’t know what EC2, VPC, or Elastic IP is; the AWS provider gives it that vocabulary and API bridge.
resource describes something that Terraform creates or modifies, such as an EC2 instance, security group, elastic IP, route table etc.
data reads something that already exists without creating or modifying it. For example, you might use a data block to look up the latest Ubuntu AMI ID so your EC2 resource can reference it. The key difference:
data block, nothing gets destroyed in AWS — the thing it referenced still exists.output exposes a value to your terminal so you can use it after terraform apply finishes. Without outputs, Terraform creates the infrastructure but you have to dig through the AWS console to find what you need. In the KomITi stack, typical outputs are the server’s public IP, the SSH command to connect, and the HTTP/HTTPS URL — everything you need to start working with the environment immediately.
When you first read a Terraform repo, it’s not enough to know what a resource is; you also need to know where things live.
The KomITi-specific layout looks roughly like this:
A short rule for reading this layout: modules/odoo_ec2_compose/main.tf and modules/odoo_ec2_compose/variables.tf belong to the reusable module, while odoo-dev-ec2-compose/main.tf and odoo-dev-ec2-compose/variables.tf belong to the root stack that calls that module. In other words, they are not duplicates serving the same role: the module has its own internal Terraform API, and the root stack has its own environment-level API.
Practically, when we say “Terraform code for DEV”, in this repo that most often means: open infra/aws/odoo-dev-ec2-compose/ and read that directory as a single infrastructure system.
Keep in mind that the name odoo-dev-ec2-compose already carries 3 layers within it:
ec2 = AWS compute host,compose = Docker runtime orchestration on that host,.tf files = the infrastructure description that creates that host and its boundary.Once you see that odoo_ec2_compose/ exists in modules/, it’s important not to think of it as just a helper folder. It is a reusable Terraform building block that root stacks call.
There are 3 key files in that module:
main.tfmain.tf in the module describes the internal logic of the reusable block: which AWS resources the module creates and how they are connected. In our KomITi example, the module builds multiple layers at once (VPC, subnet, route table, security group, etc.) so the root stack doesn’t have to write them from scratch every time. If you want to understand what odoo_ec2_compose actually does, the module main.tf is the first place to read.
variables.tfvariables.tf in the module defines the input API of that reusable block. Here the module says: if you want to use me, you must provide or may provide values such as name_prefix, env, allowed_ssh_cidr, instance_type, ssh_public_key, and so on. In other words: the root stack calls the module via its own main.tf, and the module’s variables.tf determines what that call is allowed and required to pass.
outputs.tfoutputs.tf in the module defines what the module returns back to the root stack. In our case, these are important operational values such as public IP, elastic IP, or backup bucket name. This matters because the root stack often doesn’t just want to “fire up” the module, but also to take some of its results and show them to the operator or pass them further.
Once you understand the directory structure, it makes sense to also read what the key Terraform files inside that stack do.
terraform.tfstateterraform.tfstate is the critical artifact that contains the state of all resources.
State remembers:
Key rules:
terraform plan also as a drift detector, not just as an apply prelude.variables.tf, terraform.tfvars.example, and terraform.tfvarsVariables are the input parameters of a Terraform configuration.
They exist so that code doesn’t hardcode:
There are 3 distinct files to understand here:
variables.tf defines which input parameters exist, their types, and what is optional or has a default. It is the schema the stack expects (e.g. instance_type, domain_name, allowed_ssh_cidr).
terraform.tfvars contains the actual local values used during plan/apply (terraform.tfvars.example is a template for it). Important: DEV and PROD intentionally don’t use the same secret model. For PROD, terraform.tfvars must not contain production secrets — those live on the PROD EC2 server itself, not in Terraform git artifacts.
A Terraform beginner assumes it’s normal to put every password in tfvars. Think about whether that value ends up in state, who has access to that state, and whether the secret belongs to the Terraform layer or the bootstrap/runtime layer.
Key discipline:
terraform.tfvars can be sensitive — it does not go into git,terraform.tfstate and terraform.tfstate.backup are local state artifacts and must not be version-controlled.main.tfmain.tf is the entry point of a root stack: which modules are used, how they are called, and with which values. Both this file and the module main.tf from 4.4.1) are called main.tf, but they operate at different levels: the module one is internal implementation, this one is environment-level orchestration.
network.tfnetwork.tf is the file where the network topology logic most often lives: VPC, subnets, route tables, internet gateway, and similar. If you want to understand where EC2 actually lives and how it even reaches the internet, this is one of the first files you should read.
outputs.tfoutputs.tf is the file that declares which important values Terraform exposes to the operator after apply. These are often public IP, SSH command, URL, or some other identifier you need immediately for the next operational step.
That’s why outputs.tf is important: it’s the bridge between infra code and operator work. Without it, Terraform can successfully create resources while the person doing the deploy still can’t quickly see what their most important next entry point into the system is.
One of the most important Terraform concepts is the dependency graph.
Terraform must know:
Practically:
On the local komiti_academy Docker Desktop lab, that dependency graph looks roughly like this. If you have Graphviz dot installed, you can generate it from the terminal:
terraform graph | dot -Tpng > graph.pngHere is the same relationship as an ASCII diagram:
Read the arrows as “depends on”: docker_container.odoo depends on docker_container.postgres because Odoo cannot start without a running database. Postgres in turn depends on its image, a shared network, and a persistent volume for data. Odoo also needs its own image and a volume for the filestore. Terraform reads this graph and creates resources in the right order — volumes and images first, then postgres, then odoo.
A common junior mistake is to read Terraform file by file. The dependency graph is a better starting point — it shows you the actual creation order and which resources are connected.
When reading AWS Terraform directories, think like this:
network.tf = networking topologysecurity.tf = security boundarycompute.tf = instance/runtime hostlocals.tf = naming/tagging/helper compositionvariables.tf = what is configurableoutputs.tf = what the operator needs after applytemplates/*.tpl = rendered bootstrap/user-data contentThis is the infrastructure equivalent of the Odoo mental model:
The most useful foundations mental model for this repo is the following sequence:
That’s why it’s important not to mix problem classes:
4.9.1) Plan is not a formality. terraform plan is a terminal command, and it is not a checkbox before apply.
Its purpose is to clearly show you:
Professional thinking means:
apply.If you can’t read a Terraform plan, then you are not yet operationally safe for infrastructure work.
4.9.2) Apply is not a deploy script. The terminal command terraform apply does not mean “I launched the server and I’m done”.
Apply means:
But that is not the same as:
In the KomITi AWS context, the flow often goes like this:
This is the same mental discipline as with Odoo: infra code truth is not the same as runtime truth.
One more important command: terraform destroy tears down all resources Terraform manages. In a lab, it is how you cleanly remove everything. In production, it is irreversible and must never be run without explicit intent and backup.
When making a Terraform change, the minimum safe sequence is:
terraform init if needed,terraform validate,terraform plan,terraform apply,This is not bureaucracy; it is basic production discipline.
Terraform files and Docker Compose complement each other, since you use each for what it does best. This is the case in odoo4komiti, which is a real production system. But in this komiti_academy lab — which is much simpler than odoo4komiti — you should view these two approaches as mutually exclusive variants (you use either Terraform or Docker Compose, not both simultaneously for the same runtime). Below is a mapping of the local komiti_academy lab so you can clearly see where the same runtime information is recorded in the Terraform variant versus the Compose variant.
| Information | Terraform | Compose |
|---|---|---|
| Local academy runtime name | locals.tf – name_prefix |
docker-compose.yml – name: komiti-academy-dev |
| Odoo image | default: variables.tf – odoo_image = odoo:19.0actual value: terraform.tfvars – odoo:19.0where applied: compute.tf – docker_image.odoo |
docker-compose.yml – services.odoo.image |
| Postgres image | default: variables.tf – postgres_image = postgres:16actual value: terraform.tfvars – postgres:16where applied: compute.tf – docker_image.postgres |
docker-compose.yml – services.postgres.image |
| Host port for Odoo | default: variables.tf – odoo_port = 8067actual value: terraform.tfvars – odoo_port = 8067where applied: compute.tf – ports.external = var.odoo_port |
docker-compose.yml – services.odoo.ports |
Mapping 8067 → 8069 |
compute.tf – ports { external = var.odoo_port, internal = 8069 } |
docker-compose.yml – "${ODOO_PORT:-8067}:8069" |
| Initial Postgres DB | default: variables.tf – postgres_db = postgresactual value: terraform.tfvars – postgreswhere applied: compute.tf – POSTGRES_DB = ${var.postgres_db} |
docker-compose.yml – POSTGRES_DB |
| Postgres user | default: variables.tf – postgres_user = odooactual value: terraform.tfvars – admin.komiti_odoowhere applied: compute.tf – POSTGRES_USER and Odoo USER |
docker-compose.yml – POSTGRES_USER and Odoo USER |
| Postgres password | default: variables.tf – postgres_password = no default valueactual value: terraform.tfvars – komiti-academy-local-devwhere applied: compute.tf – POSTGRES_PASSWORD and Odoo PASSWORD |
docker-compose.yml – POSTGRES_PASSWORD and Odoo PASSWORD |
Odoo connects to Postgres on host db |
compute.tf – Odoo env HOST=db and Postgres network alias db |
docker-compose.yml – Odoo HOST: db and network alias db |
| Addons bind mount | locals.tf – addons_host_pathcompute.tf – used in volume mount to /mnt/extra-addons |
docker-compose.yml – ../../../custom-addons:/mnt/extra-addons:rw |
| Odoo data volume | compute.tf – docker_volume.odoo_data |
docker-compose.yml – odoo-data:/var/lib/odoo |
| Postgres data volume | compute.tf – docker_volume.postgres_data |
docker-compose.yml – postgres-data:/var/lib/postgresql/data |
| Network | network.tf – docker_network.odoo |
docker-compose.yml – networks.academy |
| Odoo dependency on Postgres | compute.tf – depends_on = [docker_container.postgres] |
docker-compose.yml – depends_on.postgres.condition: service_healthy |
| URL output | outputs.tf – odoo_url |
No output block; the practical equivalent is ports and the command docker compose ps |
Especially important notes:
| Topic | Terraform | Compose | What this means |
|---|---|---|---|
| Master Password for localhost Odoo | Not explicitly defined | Not explicitly defined | None of your academy files currently set admin_passwd, so the password you see in the browser does not come directly from this Terraform/Compose wiring. |
| Postgres healthcheck | None | Present | The Compose variant is a bit richer here, because it has an explicit healthcheck and waits for Postgres to be healthy before starting Odoo. |
| Docker Desktop UI grouping | No Compose metadata | Has Compose metadata | That’s why Compose is grouped in the Docker Desktop UI, while Terraform Docker provider resources look more like individual Docker objects. |
| State | terraform.tfstate |
No single state file | Terraform remembers the desired and actual state in its state, while Compose relies more on the current Docker engine state and Compose project metadata labels. |
In this lab the candidate will bring up the runtime on which you will — from zero to hero — develop the Odoo module. This lab is not part of the core product scope of the komiti_academy module, but a learning/support exercise so you can locally run and verify everything you build in the later tutorials.
During this lab you will bring up two separate Odoo instances on your machine:
main branch, running on port 8068. This represents your production-equivalent baseline: only released, verified code is installed here.8067. This is where you actively develop, install your in-progress module, and test before merging.For simplicity we skip the staging branch in this lab. Your workflow will be feature → main (with a PR in between). Both instances share the same custom-addons/ folder on disk, but their databases are completely independent — so the prod database won’t have your half-finished module installed, even though the files are visible on the filesystem.
There are two options depending on your available resources:
If you have access to a cloud account where you can provision resources, this option lets you practice Terraform on real infrastructure. The purpose is not just to get a running Odoo, but for you to practically exercise:
variables.tf, outputs.tf, terraform.tfvars.example, and a local terraform.tfvars,dev and prod variants of a stack,plan / apply / destroy cycle,Even without real cloud, you can run the same Terraform exercise locally via the Docker provider. In that case, this lab does not teach real cloud networking, VM lifecycle, or cloud security boundaries. View it as a bridge: patterns around variables, outputs, naming, and environment separation transfer directly to AWS/Azure Terraform work later, but the local variant is not a 1:1 cloud template.
The suggested lab should live in your repo komiti_library, for example like this:
infra/local/odoo-dev-docker-desktop/infra/local/odoo-prod-docker-desktop/Within each of those two root directories, the candidate should have at least:
versions.tfmain.tfvariables.tfoutputs.tfterraform.tfvars.exampleterraform.tfvars that doesn’t go into gitThe minimal runtime that Terraform should bring up is:
A good minimum viable lab is:
main.tf creates the network, volume, and both containers.variables.tf carries the environment name, port, DB credentials for the lab, and naming prefix.outputs.tf outputs a URL like http://localhost:8067 and key resource names.terraform.tfvars.example exists for both dev and prod, so the candidate sees the separation even when both stacks live locally.The bootstrap sequence in this lab means:
The minimum safe lab flow follows the same sequence as section 4.10, ending with terraform destroy -var-file=terraform.tfvars to cleanly tear down the lab. If you successfully complete this path, you have truly practiced the Terraform shape and lifecycle discipline.
Don’t worry — you can still do everything needed to continue learning. In this option you skip Terraform entirely and use Docker Compose to bring up Odoo directly on Docker Desktop. The result is the same two running Odoo instances (prod + dev) you need for the module development tutorials; the only difference is that Terraform infrastructure management is not part of your exercise.
Prerequisites:
komiti_library repo cloned locally (you did this in tutorial 02, section 4.4).Step 1 — open a terminal and make sure you are on main.
PS C:\Users\you> cd C:\dev\komiti_library
PS C:\dev\komiti_library> git checkout main
PS C:\dev\komiti_library> git pull origin mainYou start on main because infrastructure files belong to all branches — they are not feature-specific. By committing them to main first, every future feature branch will inherit them automatically.
Step 2 — create the directory structure and compose files.
You need two directories — one for each environment. You also need a custom-addons/ folder at the repo root (this is where your Odoo modules will live later). Create them:
PS C:\dev\komiti_library> mkdir infra/local/odoo-prod-docker-desktop
PS C:\dev\komiti_library> mkdir infra/local/odoo-dev-docker-desktop
PS C:\dev\komiti_library> mkdir custom-addons
PS C:\dev\komiti_library> echo $null > custom-addons/.gitkeepecho $null > custom-addons/.gitkeep creates an empty file called .gitkeep. Git does not track empty directories, so without at least one file inside custom-addons/ the folder would not appear in the repository. The name .gitkeep is a widely used convention — Git itself does not treat it specially.
Now create the prod compose file at infra/local/odoo-prod-docker-desktop/docker-compose.yml:
name: komiti-library-prod # Docker Compose project name (prefixes container names)
services:
postgres:
image: postgres:16 # official PostgreSQL 16 image
restart: unless-stopped # auto-restart unless you explicitly stop it
environment:
POSTGRES_DB: postgres # bootstrap DB for server start; unused later
POSTGRES_USER: odoo # PostgreSQL superuser; Odoo connects as this user
POSTGRES_PASSWORD: komiti-library-prod-local # must match PASSWORD in the odoo service
healthcheck:
test: ["CMD-SHELL", "pg_isready -U odoo -d postgres"] # checks if PostgreSQL is ready to accept connections
interval: 10s # check every 10 seconds
timeout: 5s # fail if no response within 5 seconds
retries: 10 # mark unhealthy after 10 consecutive failures
volumes:
- postgres-data:/var/lib/postgresql/data # persist database files across container restarts
networks:
library-prod:
aliases:
- db # other services find postgres at hostname "db"
odoo:
image: odoo:19.0 # official Odoo 19 image
restart: unless-stopped
depends_on:
postgres:
condition: service_healthy # wait for pg_isready before starting Odoo
environment:
HOST: db # network alias of the postgres service
PORT: 5432 # default PostgreSQL port
USER: odoo # must match POSTGRES_USER above
PASSWORD: komiti-library-prod-local # must match POSTGRES_PASSWORD above
ports:
- "8068:8069" # host:container — access prod Odoo at localhost:8068
volumes:
- odoo-data:/var/lib/odoo # filestore, sessions (named volume)
- ../../../custom-addons:/mnt/extra-addons:rw # your modules from repo root (bind mount)
networks:
library-prod:
aliases:
- odoo # optional: other services can find odoo by name
volumes:
postgres-data: # named volume for PostgreSQL data
odoo-data: # named volume for Odoo filestore
networks:
library-prod: # isolated network for this stack../../../custom-addons:/mnt/extra-addons:rw is a bind mount. It tells Docker: “take the custom-addons/ folder from the repo root on your Windows disk and make it appear inside the container at /mnt/extra-addons.” The path starts with ../../../ because the compose file lives three directories deep (infra/local/odoo-prod-docker-desktop/). The dev compose file will have the same line, so both environments see the exact same folder on disk.
Then create the dev compose file at infra/local/odoo-dev-docker-desktop/docker-compose.yml:
name: komiti-library-dev # Docker Compose project name (prefixes container names)
services:
postgres:
image: postgres:16 # official PostgreSQL 16 image
restart: unless-stopped # auto-restart unless you explicitly stop it
environment:
POSTGRES_DB: postgres # bootstrap DB for server start; unused later
POSTGRES_USER: odoo # PostgreSQL superuser; Odoo connects as this user
POSTGRES_PASSWORD: komiti-library-dev-local # must match PASSWORD in the odoo service
healthcheck:
test: ["CMD-SHELL", "pg_isready -U odoo -d postgres"] # checks if PostgreSQL is ready to accept connections
interval: 10s # check every 10 seconds
timeout: 5s # fail if no response within 5 seconds
retries: 10 # mark unhealthy after 10 consecutive failures
volumes:
- postgres-data:/var/lib/postgresql/data # persist database files across container restarts
networks:
library-dev:
aliases:
- db # other services find postgres at hostname "db"
odoo:
image: odoo:19.0 # official Odoo 19 image
restart: unless-stopped
depends_on:
postgres:
condition: service_healthy # wait for pg_isready before starting Odoo
environment:
HOST: db # network alias of the postgres service
PORT: 5432 # default PostgreSQL port
USER: odoo # must match POSTGRES_USER above
PASSWORD: komiti-library-dev-local # must match POSTGRES_PASSWORD above
ports:
- "8067:8069" # host:container — access dev Odoo at localhost:8067
volumes:
- odoo-data:/var/lib/odoo # filestore, sessions (named volume)
- ../../../custom-addons:/mnt/extra-addons:rw # your modules from repo root (bind mount)
networks:
library-dev:
aliases:
- odoo # optional: other services can find odoo by name
volumes:
postgres-data: # named volume for PostgreSQL data
odoo-data: # named volume for Odoo filestore
networks:
library-dev: # isolated network for this stack8068 for prod, 8067 for dev). Keep POSTGRES_DB as postgres in both files. The real Odoo databases (komiti_library_prod and komiti_library_dev) are created later from the Odoo web UI. If you set POSTGRES_DB directly to those names, Postgres creates empty databases first and Odoo may return HTTP 500 instead of the normal database creation screen.
Step 3 — commit the infrastructure files to main.
PS C:\dev\komiti_library> git add -A
PS C:\dev\komiti_library> git commit -m "Add infra: prod and dev Docker Compose stacks"
PS C:\dev\komiti_library> git push origin mainInfrastructure lives on main. Every feature branch you create later will inherit these files.
Step 4 — bring up the prod Odoo instance.
PS C:\dev\komiti_library> cd infra/local/odoo-prod-docker-desktop
PS C:\dev\komiti_library\infra\local\odoo-prod-docker-desktop> docker compose up -dDocker will pull the postgres:16 and odoo:19.0 images (this may take a few minutes the first time). Once done, verify:
PS ...> docker compose psYou should see two services: postgres (healthy) and odoo (running). Open http://localhost:8068 in your browser. You should see the Odoo database creation screen. Create a database named komiti_library_prod — this is your production baseline. Leave it clean for now; don’t install any custom module here yet.
Step 5 — create a feature branch.
PS ...> cd C:\dev\komiti_library
PS C:\dev\komiti_library> git checkout -b 2026-04-01-library-module
PS C:\dev\komiti_library> git push -u origin 2026-04-01-library-moduleYou are now on a feature branch created from main. The infrastructure files you committed in step 3 are already here.
Step 6 — bring up the dev Odoo instance.
PS C:\dev\komiti_library> cd infra/local/odoo-dev-docker-desktop
PS C:\dev\komiti_library\infra\local\odoo-dev-docker-desktop> docker compose up -dcd command above we used forward slashes (/). PowerShell accepts both / and \ when navigating directories, so cd infra/local/odoo-dev-docker-desktop and cd infra\local\odoo-dev-docker-desktop do the same thing. However, inside files like docker-compose.yml, YAML, Linux paths, and URLs always use forward slashes — backslashes will break them. Rule of thumb: use \ only when Windows requires it (e.g. full absolute paths like C:\dev\...); everywhere else, forward slashes are safer and more portable.
Verify with docker compose ps, then open http://localhost:8067. You should again see the Odoo database creation screen. Create a database named komiti_library_dev — this is your development instance where you will install and test your module as you build it.
Step 7 — understand what you now have.
At this point, two independent Odoo instances are running on your machine, but they differ in two important ways:
localhost:8068 — clean baseline, no custom module installed.localhost:8067 — your development playground, tied to the feature branch.custom-addons/ files because it mounts the same folder, but you keep the module uninstalled there until you intentionally install a stable, released version.custom-addons/, but each database decides independently which modules are actually installed and active.
Stopping and restarting. When you are done working:
docker compose stop — stops containers but keeps data (run from the respective directory).docker compose down — stops and removes containers but keeps volumes (data survives).docker compose down -v — removes everything including data.Next time you resume, navigate to the compose directory and run docker compose up -d. As long as you haven’t removed the volumes, your database and filestore will still be there.
What to understand from this option: you now have a working two-environment Odoo setup that is functionally equivalent to what Option A produces via Terraform. The difference is that you did not practice Terraform project structure, variables, or the plan/apply cycle. If you later get cloud access, you can return to Option A to learn that layer. For now, you have everything you need to continue with the Odoo module development tutorials.
The following files live in the odoo4komiti repository. Open them from your local clone:
odoo4komiti/.github/instructions/terraform.instructions.mdodoo4komiti/infra/aws/odoo-dev-ec2-compose/README.mdodoo4komiti/infra/aws/odoo-dev-ec2-compose/RUNBOOK.mdodoo4komiti/infra/aws/odoo-prod-ec2-compose/README.mdodoo4komiti/infra/aws/odoo-prod-ec2-compose/RUNBOOK.mdkomiti_academy: what would you check first if the module doesn’t work, and what if the runtime itself isn’t healthy.komiti_academy, list which runtime assumptions must be true before actually verifying that the module works.komiti_library that uses Docker Desktop to bring up a Postgres and Odoo stack for a local dev runtime, with a clear file structure, variables, outputs, and a clear workflow sequence.variables.tf, terraform.tfvars.example, and terraform.tfvars, 4.3) Directory structure: general and KomITi-specific, 4.9.1) Plan is not a formality, 4.10) Minimal safe workflow in KomITi, and 6) Lab: bring up the Odoo runtime for development.
docker compose do?resource and what is a data source?plan before apply?terraform.tfvars and terraform.tfstate not go into git?terraform apply not the same as application verification?.tf files?odoo4komiti infra: open infra/aws/odoo-dev-ec2-compose in your local clone and do the following:
variables.tf, compute.tf, security.tf, outputs.tf..tf file defines the host, which defines the network boundary, and which defines the operator outputs..github/instructions/terraform.instructions.md and a root stack directory such as infra/aws/odoo-dev-ec2-compose/.Solutions: