Setup Coveo for Dockerized Sitecore
Challenge
I just started working on a new project with Sitecore + Docker. In this project, one of the requirements is to use the Coveo search instead of Solr search. While we have a regular Sitecore setup for the development or production, the Coveo setup is straightforward. But I have Docker as the development environment and K8S as the production environment. I found that setting up the Coveo for the containerized Sitecore is not working as expected with the initial research. Coveo stores the following required information in the configuration files when you first-time set up and authorize with the Coveo.
- API key
- Organizaton ID
- Search api key
- And other all such information….
It works well with a traditional Sitecore setup, but with the containerized environment, this is not possible. To make the Coveo work with containerized Sitecore, we need all these files prepared with the necessary value. And, these files are deployed during the image build. However, considering the security, we should not commit these files to version control containing the sensitive key values.
I took up this challenge and started researching and doing hands-on to make this work.
I am glad that I’m successful in setting up the Coveo with containerized Sitecore, at least for Docker. Yet, I’ve to try this solution on K8S, for which I’ll share my findings once I finish my research.
I’ve used Sitecore 10.1 docker images and related Coveo packages, which you can download from the Coveo Releases and Downloads page.
Solution
Now, let’s talk about what is the solution to make the Coveo work with Dockerized Sitecore.
I started with how I should manage the sensitive key values in the .env file for my dockerized environment, so those values should not get committed to the version control.
Looking for the solutions, I found the following documentation from Coveo, which helped me get my dockerized environment up and running successfully.
As described in the documentation, I prepared one PowerShell script which configures and activates the Coveo on my CM container.
To make the entire solution work, I did the following steps:
Verify first created the cm-init Dockerfile in a dedicated folder named ‘cm-init.’ This folder resides inside the xxx/docker/build/. Please refer to the below image.

The Dockerfile contains the steps to copy the activate-coveo.ps1 file to the image of the cm-init service. This activate-coveo.ps1 file is the entry point for the cm-init container when it is initialized.
Following is the activate-coveo.ps1 file, which does the configuration and activation of the Coveo module.
After the above step, I modified the docker-compose.override.yml with the following:
cm-init:
image: ${REGISTRY}${COMPOSE_PROJECT_NAME}-xp0-cm-init:${VERSION:-latest}
build:
context: ./build/cm-init
args:
PARENT_IMAGE: ${REGISTRY}${COMPOSE_PROJECT_NAME}-xp0-cm:${VERSION:-latest}
entrypoint: powershell -Command "& C:\build\activate-coveo.ps1"
environment:
sc_cm: 'http://cm'
COVEO_API_KEY: ${COVEO_API_KEY}
COVEO_ORGANIZATION_ID: ${COVEO_ORGANIZATION_ID}
COVEO_SEARCH_API_KEY: ${COVEO_SEARCH_API_KEY}
COVEO_SITECORE_USERNAME: ${COVEO_SITECORE_USERNAME}
COVEO_SITECORE_USER_PASSWORD: ${COVEO_SITECORE_USER_PASSWORD}
COVEO_FARM_NAME: ${COVEO_FARM_NAME}
COVEO_SCRIPT_SITECORE_USERNAME: ${COVEO_SCRIPT_SITECORE_USERNAME}
COVEO_SCRIPT_SITECOREPASSWORD: ${COVEO_SCRIPT_SITECOREPASSWORD}
depends_on:
cm:
condition: service_healthy
Important:
Make sure you add the following entries in your .env file with appropriate values:
COVEO_API_KEY
COVEO_ORGANIZATION_ID
COVEO_SEARCH_API_KEY
COVEO_SITECORE_USERNAME
COVEO_SITECORE_USER_PASSWORD
COVEO_FARM_NAME
COVEO_SCRIPT_SITECORE_USERNAME
COVEO_SCRIPT_SITECOREPASSWORD
In the above code block, you can see that I set the Coveo API keys and other information in the environment section of the cm-init service, where values are read from the .env file.
The cm-init service has a dependency on the cm instance so, the cm-init will start once the cm is finished.
The entry point activate-coveo.ps1 for cm-init service will first check if the cm site is up or not. It waits till the CM site comes up. Once the cm site is up, it configures the Coveo configuration files in the disabled mode. After that, it activates the Coveo by renaming the files, and hence the cm site application pool restarts.
This is the way that I used to set up the Coveo for the containerized Sitecore.
Please refer to the Github code repository for a complete reference to understand how this has been set up.