Deploy Odoo 18 on Google Cloud Run: Complete 2025 Guide

Integration Architecture and Data Flow

Core Serverless Components

Google Cloud Run operates on a simple, powerful premise: it runs stateless containers. Your Odoo application, with all its code and dependencies, packages into a single Docker image. Cloud Run executes this image in a secure, isolated environment. It scales the number of container instances automatically based on incoming HTTP requests. When traffic subsides, it scales down to zero, which eliminates costs when no one uses your Odoo instance.

The architecture separates compute from data. Odoo itself runs as the stateless component on Cloud Run. A Google Cloud SQL for PostgreSQL instance serves as the stateful, durable data store. This separation is critical for a serverless design. It lets Cloud Run tear down and recreate Odoo containers without any risk of data loss. All user data, configurations, and logs persist securely in the managed database.

A Google Cloud Storage bucket provides persistent filestore. Odoo generates many files, including module attachments, user uploads, and report documents. In a traditional setup, these files reside on the server’s local disk. In our serverless architecture, local disk storage is ephemeral. We configure Odoo to use the Cloud Storage bucket as its filestore backend. This ensures all file data persists independently of the Odoo container’s lifecycle.

Request and Data Flow Patterns

A user’s web browser sends an HTTP request to your Odoo application’s custom domain. Google Cloud’s global load balancer receives this request first. It routes the traffic to the Cloud Run service endpoint. If no container instances are running, Cloud Run initializes a new one, a process known as a “cold start.” The newly started Odoo container then handles the incoming request.

Odoo processes the request by communicating with the Cloud SQL database. It executes SQL queries to fetch or update records. For file operations, Odoo uses a Python library to interact with the Cloud Storage API. It uploads new files or fetches existing ones directly from the bucket. This keeps the container lightweight and stateless, as all important data resides in external, managed services.

Session data and user cache require special handling. The default in-memory cache becomes useless when containers terminate. We configure Odoo to use a Redis-based caching backend, which we deploy on Google Cloud Memorystore. This externalizes the cache, allowing any container instance to access shared session data. This setup is essential for maintaining user sessions across multiple container instances and ensuring a consistent user experience.

Step-by-Step Configuration

Prerequisites and Project Setup

Start with a Google Cloud Project. Use the Google Cloud Console or the gcloud CLI to create a new project. Note your Project ID, as it will be essential for all subsequent commands. Enable the necessary APIs for this deployment: Cloud Run API, Cloud SQL Admin API, Cloud Storage API, and Secret Manager API. You can enable them via the console or by running gcloud services enable run.googleapis.com sqladmin.googleapis.com storage.googleapis.com secretmanager.googleapis.com.

Install the Google Cloud CLI and Docker on your local machine or development server. Authenticate the gcloud CLI with your account using gcloud auth login and set your project with gcloud config set project [YOUR_PROJECT_ID]. This setup ensures all your resource creation commands deploy to the correct project. Verify your installation can build and push Docker images by testing with a simple hello-world container.

Create a dedicated service account for the Odoo application. This account will grant your Cloud Run service the specific permissions it needs, following the principle of least privilege. Craft a custom role or assign predefined roles like Cloud SQL Client, Storage Object Admin, and Secret Manager Secret Accessor. This service account will impersonate the Odoo container, allowing it to access the database and storage bucket securely without embedding keys.

Database and Storage Infrastructure

Provision a Cloud SQL for PostgreSQL instance. Select the PostgreSQL 15 or 16 version for optimal compatibility with Odoo 18. Choose a machine type that matches your expected workload; a db-g1-small instance works for initial development and testing. Configure a private IP address for the instance to enhance security, ensuring database traffic never traverses the public internet. Note the connection name, which follows the format [PROJECT_ID]:[REGION]:[INSTANCE_NAME].

Create a new database and user for Odoo. Connect to your Cloud SQL instance using the Cloud SQL Auth Proxy or the built-in console SQL editor. Execute the commands CREATE DATABASE odoo; and CREATE USER odoo_user WITH PASSWORD 'your_secure_password';. Grant the user full privileges on the Odoo database with GRANT ALL PRIVILEGES ON DATABASE odoo TO odoo_user;. Store the database password securely in Google Secret Manager as a new secret, for example, named odoo-db-password.

Initialize a new Cloud Storage bucket for Odoo filestore. Choose a globally unique name, typically incorporating your project ID. Set the bucket’s access control to uniform, which applies permissions at the bucket level rather than the individual object level. This simplifies management. The Odoo service account you created earlier will need write access to this bucket, which we handle through IAM bindings, not bucket ACLs.

Docker Image Construction

Odoo requires a custom Docker image for Cloud Run. Start with the official Odoo 18 image as your base. Create a Dockerfile that adds necessary dependencies and configuration. You must install the psycopg2 PostgreSQL adapter and the google-cloud-storage Python library. This library enables the Odoo filestore integration with your Cloud Storage bucket.

Your Dockerfile should copy a custom Odoo configuration file (odoo.conf) into the container. This file contains all environment-specific settings. Use build-time arguments or environment variables for sensitive data that you will inject at runtime from Secret Manager. A multi-stage build can help minimize the final image size, which improves cold start performance on Cloud Run.

Build the image using Google Cloud Build for consistency and to store it in Google Container Registry (GCR). Run the command gcloud builds submit --tag gcr.io/[PROJECT_ID]/odoo:latest . from your Dockerfile’s directory. This command packages your code, pushes the image to GCR, and makes it ready for deployment to Cloud Run. Always tag your images meaningfully to manage different versions of your application.

Cloud Run Service Deployment

Deploy the container image to Cloud Run with a precise gcloud run deploy command. Specify the service name, region, and the image URL you built. Crucially, set the --add-cloudsql-instances flag with your Cloud SQL instance’s connection name. This action creates a secure sidecar that allows your container to connect to the database via a Unix socket. Set the --service-account flag to the email of the dedicated Odoo service account.

Configure all environment variables during deployment. These variables tell Odoo how to connect to its external services. Key variables include HOST (set to /cloudsql/[CONNECTION_NAME] for the Cloud SQL socket), PGUSER, PASSWORD (which you reference from Secret Manager using sm://odoo-db-password), and DB_NAME. Also, set the ODOO_RC environment variable to point to the location of your configuration file inside the container.

Set the necessary resource allocations for your service. Allocate adequate memory (at least 1Gi, but 2Gi is better for production) and CPU (at least 1) based on Odoo’s requirements. Configure the request timeout to a higher value, such as 300 seconds, to accommodate longer-running operations like module installation or report generation. Set the maximum number of container instances to prevent runaway scaling costs during unexpected traffic surges.

Data Mapping and Transformation

Odoo Module and Database Schema

Odoo employs a dynamic data model. Its core consists of fundamental models like res.partner for contacts, product.product for products, and account.move for accounting entries. Each installed application module extends the system by adding new models or fields to existing ones. This extensible architecture means your database schema evolves as you install new Odoo apps, such as CRM, Inventory, or Manufacturing.

The system uses an object-relational mapping (ORM) layer that abstracts direct SQL queries. When you define a new model in a custom module, Odoo’s ORM handles the creation of the corresponding database table. It also manages the complex relationships between models, like many-to-one or many-to-many. This ORM layer simplifies development but requires an understanding of how Odoo structures data versus raw PostgreSQL tables.

Understanding the ir.model and ir.model.fields tables is crucial. These are Odoo’s metadata tables that define all the models and fields in the system. They act as a data dictionary. When you need to perform complex data migrations or integrations, you often query these tables to understand the current schema structure programmatically, rather than assuming a fixed table layout.

Filestore to Cloud Storage Mapping

The default Odoo filestore saves files on the server’s local filesystem. It uses a naming convention based on the file’s SHA1 hash, splitting the hash into two directory levels for efficient storage. For example, a file with the hash abc123def... saves to a path like ab/c1/abc123def.... This structure prevents any single directory from containing too many files, which can cause performance issues.

We reconfigure this mechanism to use Google Cloud Storage. The google-cloud-storage Python library provides an S3-compatible API that Odoo’s filestore system can utilize. We implement a custom filestore or use an existing community module that overrides Odoo’s core file storage methods. Instead of writing to /path/to/filestore, the system now makes API calls to store and retrieve files from the designated Cloud Storage bucket.

The data mapping remains consistent; the file content and directory structure mirror the local filesystem approach. The key difference is the storage backend. This transformation is transparent to the Odoo application and its users. All file access operations—uploading invoices, attaching documents to records, or storing product images—continue to work without code changes, but the data now resides in a durable, scalable object store.

Environment Configuration Translation

The standard odoo.conf file contains key-value pairs for all system settings. In our Cloud Run deployment, we translate many of these settings into environment variables. This approach aligns with the twelve-factor app methodology and works better with Cloud Run’s configuration system. For instance, the db_host parameter in the config file becomes the HOST environment variable, and db_password becomes the PASSWORD variable.

Sensitive configuration elements undergo a second transformation. We do not set database passwords or API keys as plaintext environment variables. Instead, we reference them from Google Secret Manager. Cloud Run has native integration with Secret Manager, allowing you to mount secrets as environment variables or volume files. This adds a critical security layer, ensuring credentials never appear in your deployment commands or service configuration UI.

We also handle addons paths dynamically. Odoo needs to know the file system paths to its core addons and any custom modules. In a container, these paths are fixed. We set the addons_path parameter to include /mnt/extra-addons for custom modules, which we can populate during the Docker build stage or mount from a cloud storage bucket at runtime for greater flexibility in development workflows.

Error Handling and Resilience

Common Deployment and Runtime Errors

Cloud Run cold starts present a primary challenge. The first request to a new container instance may time out if Odoo’s initialization process takes too long. Odoo must preload its ORM, connect to the database, and verify all modules. This process can exceed Cloud Run’s default request timeout. The solution involves increasing the --timeout setting to 300s or more and optimizing your Docker image for faster startup by minimizing layers and removing unnecessary packages.

Database connection errors are another frequent issue. The error “Connection to the database failed” often stems from incorrect Cloud SQL instance configuration. Verify the --add-cloudsql-instances flag uses the correct connection name. Ensure your Odoo service account has the roles/cloudsql.client role. Test the database connection from a local environment using the Cloud SQL Auth Proxy to isolate whether the problem is network-related or credential-based.

File storage permissions can cause silent failures. If Odoo lacks write permissions to the Cloud Storage bucket, file uploads will fail without always showing a clear error in the Odoo log. Check the IAM permissions for the service account. It needs the roles/storage.objectAdmin role on the specific bucket. Review the Cloud Run logs in Google Cloud Console, as they often capture underlying permission denial errors from the Google Cloud client libraries.

Proactive Health Monitoring

Configure Cloud Run health checks to monitor your Odoo instance. By default, Cloud Run sends HTTP requests to the root URL of your service. Odoo’s web interface may require a login, causing these checks to fail. Create a custom health check endpoint. A simple controller that returns a 200 status code after verifying database connectivity works best. This tells Cloud Run the container is healthy and ready to receive traffic.

Implement structured logging throughout your application. Odoo generates extensive logs, but in a containerized environment, you must write them to stdout and stderr. Cloud Run captures these streams and forwards them to Google Cloud Logging. Use consistent log formats and severity levels. This practice enables you to create log-based metrics and alerts for specific error patterns, such as a sudden spike in 5xx HTTP status codes or database connection timeouts.

Set up alerting policies for critical errors. Google Cloud Monitoring allows you to define conditions that trigger alerts. Create alerts for high error rates, elevated latency, or container instance crashes. Configure notification channels like email, Slack, or PagerDuty to ensure your team responds to issues promptly. For business-critical operations, also monitor Odoo-specific metrics, such as failed transaction posts or inventory synchronization errors.

Data Recovery Procedures

Despite a managed database, you need a robust backup strategy. Cloud SQL provides automated backups and point-in-time recovery. Configure a backup schedule that aligns with your business’s data tolerance. Typically, this involves daily backups with a 7-day retention. For additional safety, enable point-in-time recovery, which lets you restore your database to any specific second within the last 7 days, protecting against accidental data corruption or deletion.

Prepare a documented recovery playbook. This document should outline the exact steps to restore your Odoo service from a backup. Test the recovery process periodically. A recovery drill involves creating a new Cloud SQL instance from a backup, deploying a new Cloud Run service pointing to this instance, and verifying data integrity. Regular testing ensures your team can execute a recovery under pressure without missing critical steps.

Version your Docker images and database schemas. Every deployment to Cloud Run should use a unique image tag, not just latest. This practice lets you roll back a faulty application update by redeploying the previous known-good image version. Similarly, use Odoo’s module versioning and database migration scripts. This control over application and data state versions forms the foundation of a reliable, resilient deployment.

Testing and Validation

Pre-Deployment Verification Checklist

Before deploying to Cloud Run, validate your Docker image locally. Run the container with docker run -p 8069:8069 -e DB_HOST=... [IMAGE_URL] and access Odoo from your browser. This test confirms the image builds correctly and the application starts. Use the Cloud SQL Auth Proxy to simulate the database connection, ensuring your container can reach the Cloud SQL instance over a secure channel.

Verify all environment variables and secrets. Create a test script that checks the availability of every secret in Secret Manager and validates the permissions of the Odoo service account. This script should attempt a dummy read from the Cloud Storage bucket and a test connection to the Cloud SQL database. Catching configuration errors in this pre-flight stage prevents deployment loops and diagnostic headaches after going live.

Test the Odoo configuration in a staging environment. Deploy your Cloud Run service to a separate, identical project or use a different service name within the same project. This staging environment should mirror production exactly, including the database and storage bucket. Perform a full installation of Odoo, including all the modules you plan to use in production. This end-to-end test uncovers environment-specific issues before they affect users.

Post-Deployment Functional Tests

Execute a comprehensive smoke test suite immediately after deployment. This test should include accessing the Odoo login page, creating a new database (if in multi-tenant mode), and installing a core module like Sales or Contacts. Verify that basic CRUD operations work: create a new contact, update its details, and then delete it. These actions test the database connection, ORM functionality, and basic UI rendering.

Validate the filestore integration thoroughly. Upload a file attachment to a record, such as a PDF to a sales order. Then, download the same file. Confirm the file stores in your Cloud Storage bucket with the correct path and permissions. Test with different file types and sizes to ensure the integration handles various scenarios. This validation is critical, as filestore issues may not manifest as immediate, visible errors.

Test user access control and multi-company settings if applicable. Create test users with different permission groups and verify they can only access the intended data and menus. If you use Odoo’s multi-company features, ensure data isolation works correctly. These tests confirm that the underlying security and access control mechanisms, which rely on database rules and Odoo’s ORM, function in the Cloud Run environment.

Load and Performance Benchmarking

Assess the cold start performance. Time how long it takes for the first request to succeed after deploying a new revision or when traffic triggers a scale-from-zero event. This measurement sets user expectations and helps you evaluate image optimization efforts. If cold starts are too long, consider using minimum instances set to 1 to keep a container always warm, though this increases cost.

Simulate concurrent user traffic. Use a load testing tool like Apache JMeter or artillery to send multiple simultaneous requests to your Odoo instance. Monitor the Cloud Run metrics in the console, specifically the request count, latency, and container instance count. Observe how the service scales under load and where bottlenecks occur—whether in the Odoo application logic, the database, or the network.

Establish performance baselines for key operations. Measure the response time for loading the dashboard, opening a list view of 1000 records, and generating a standard report. Run these tests periodically and compare results against your baseline. A significant deviation can indicate a problem with the database, a new inefficient module, or resource constraints on the Cloud Run service. This proactive monitoring maintains a quality user experience.

Security Considerations

Identity and Access Management

The principle of least privilege governs our entire setup. The Odoo service account possesses only the permissions essential for its operation: connecting to the specific Cloud SQL instance and reading/writing to the specific Storage bucket. It does not have broad project-level editor roles. This containment limits the potential impact of a compromised container. Even if an attacker gains code execution inside the container, their lateral movement remains restricted.

Secure your database connections with private IP. During Cloud SQL instance creation, you configured a private IP address. The Cloud Run service connects to this IP via a VPC connector or the --add-cloudsql-instances flag, which uses a sidecar proxy. This configuration ensures all database traffic occurs within Google’s internal network, never exposing your database to the public internet. It eliminates a major attack vector.

Manage all secrets with Google Secret Manager. Database passwords, Odoo master passwords, and API keys for external services all reside in Secret Manager, not in your Docker image or environment variables in plaintext. Cloud Run can inject these secrets as environment variables or mount them as files in the container’s filesystem. This approach provides centralized management, audit trails, and automatic secret rotation capabilities.

Application and Network Security

Configure Odoo with a strong master password. This password controls access to the database management screens in Odoo. Without it, users cannot create, duplicate, or drop databases. In a production environment, you typically pre-create the database, so set this password via Secret Manager and use it to lock down administrative functions. This prevents unauthorized access to Odoo’s most powerful operations.

Enforce HTTPS for all traffic. Cloud Run provides TLS termination by default, automatically serving your service over a secure HTTPS connection. It also offers a managed SSL certificate feature for your custom domains. Redirect all HTTP traffic to HTTPS by setting the X-Forwarded-Proto header or using a separate load balancer configuration. Encrypted data in transit protects user sessions and sensitive business information.

Implement Odoo’s built-in security features. Regularly update your Odoo image to incorporate the latest security patches for both Odoo itself and its underlying Python dependencies. Use Odoo’s access control lists (ACLs) to define user groups and permissions with precision. Disable any unused Odoo apps or endpoints to reduce the application’s attack surface. A minimal, well-configured application is a secure application.

Performance Optimization

Cold Start Mitigation Strategies

Cold starts represent the most significant performance challenge for serverless Odoo. The key is to minimize your Docker image size. Use a slim base image, like the official odoo:18.0 image, but consider building from a lighter base like python:slim if you have advanced control over dependencies. Combine RUN instructions in your Dockerfile to reduce layers and clean up the package cache in the same layer that installs packages.

Optimize the Odoo startup sequence. Odoo preloads its module registry, which can be slow. For production, consider using the --load command-line option to specify only the core modules needed for initial operation, deferring the loading of less critical modules. You can also explore using the --workers parameter, even in a Cloud Run context, to pre-fork processes, though this requires careful memory management.

The most direct solution is to configure a minimum number of instances. Set the --min-instances parameter to 1 to keep at least one container instance running at all times. This setting eliminates cold starts for the first user but incurs a continuous cost. Balance this cost against your user experience requirements. For development instances, you might accept cold starts; for production, the cost of a minimum instance is often justified.

Database and Cache Optimization

Database performance dictates overall application responsiveness. On Cloud SQL, enable the cloudsql.iam_authentication flag if you use IAM-based authentication, which can streamline connections. Configure the max_connections parameter on your Cloud SQL instance to a value that accommodates the maximum number of concurrent Cloud Run container instances multiplied by the database connections each uses.

Implement a Redis cache for Odoo sessions and frequently accessed data. Deploy a Google Cloud Memorystore Redis instance. Configure Odoo to use this Redis instance for its cache and session storage. This externalization prevents cache loss when Cloud Run terminates containers and allows all container instances to share a common cache. This is vital for user session consistency and for caching expensive database queries.

Monitor and analyze slow database queries. Odoo’s ORM can sometimes generate inefficient SQL. Use Cloud SQL’s built-in query insights and slow query logs to identify problematic queries. Often, adding a specific database index on a frequently filtered field can improve performance by orders of magnitude. Regularly review the performance of key reports and list views, as these are common bottlenecks.

Cost-Performance Trade-offs

Your choice of CPU and memory allocation impacts both performance and cost. Odoo is a memory-intensive application. Allocating too little memory (less than 1Gi) will cause excessive disk swapping inside the container, leading to terrible performance. Start with 2Gi of memory and 1 CPU, then monitor the container’s memory usage. Adjust upwards if you see the service approaching its memory limit.

Understand Cloud Run’s concurrency model. The --concurrency setting defines how many requests a single container instance can handle simultaneously. A higher concurrency value (e.g., 80) improves resource utilization and reduces the number of container instances, which can lower cost. However, setting it too high may increase response latency as requests queue up. Test different concurrency values under load to find the sweet spot for your workload.

Use a CDN for static assets. While Odoo serves its own static files (JavaScript, CSS, images), this consumes container CPU cycles. For a global user base, configure a CDN like Google Cloud CDN to cache these static assets at edge locations. This reduces latency for users and offloads work from your Cloud Run service, allowing it to dedicate more resources to dynamic application logic.