DEV Community: DERICK TEMFACK

From ChatGPT to Gemini: How We Built a GDPR-Compliant CV Parser for Odoo

DERICK TEMFACK — Sun, 11 Jan 2026 23:10:17 +0000

A few years ago, a business owner in France contacted us to help digitalize their workflow. This company specializes in recruiting people for Work-Study Programs (known in France as Alternance).

In short, Alternance is a system where you split your time between school and a job. It is a great deal because the student gets a degree for free, gains real work experience, and receives a salary based on the French minimum wage (SMIC). It is designed to help young people and job seekers enter the workforce or switch careers.

The company acts as an expert middleman because the process can be overwhelming to manage alone. Here is how they operate:

Finding Candidates: They source students or job seekers interested in work-study programs.
Screening: They interview applicants to ensure they meet official government criteria (age, educational background, etc.).
Matching with Employers: They find companies looking for apprentices and send them the best profiles.
Handling Paperwork: Once a company decides to hire, the agency handles the complex administrative steps and ensures contracts are signed.

Basically, they bridge the gap between the apprentice and the employer, making the journey smoother for everyone.

The Bottleneck: Manual Data Entry

Before contacting us, they were doing everything manually using notebooks and spreadsheets. We built a complete recruitment pipeline for them based on the Odoo Community Recruitment module.

We developed custom modules to extend Odoo's base functionality to support their specific workflow. Once completed, the solution allowed the company to track everything in one place: the database of applicants and companies, the recruitment stages, appointments, automated Mail/SMS notifications, the calendar, and digital contract signatures.

The solution was a success. Everyone liked the new system, and it made their daily lives much simpler. However, one major pain point remained: Data Entry.

Recruiters still had to find profiles and manually enter them into the recruitment pipeline before they could start working. The business owner was frustrated. He was paying recruiters to hunt for talent, but they were spending hours doing manual data entry.

We decided to automate this using AI.

Designing the Automation Workflow

Our first idea was to build an API so third parties could send data directly to the system. While this would have been ideal, the third-party sources were not ready for it.

We reached an agreement to receive all applicant CVs via email instead. These were simple emails with the CV attached. Once we confirmed we were receiving the CVs in a dedicated mailbox, we designed the following automation workflow:

Read Emails: Log in to the email provider and fetch unread emails.
Extract Attachment: Download the attached CV (usually a PDF).
OCR Processing: Perform Optical Character Recognition to extract raw text from the CV.
AI Parsing: Use an LLM to transform that raw text into a structured JSON format.
Odoo Integration: Use Odoo XML-RPC to create a record in the recruitment module. We also attach the original PDF so the recruiter has a reference if the AI misses anything.
Assignment: Automatically assign the lead to an available recruiter.

Iteration 1: Tesseract and ChatGPT

For our first solution, we developed a microservice using Tesseract for OCR and the ChatGPT API for the LLM logic.

It worked fine for a couple of months, and the client was happy. However, technical issues started to appear. Tesseract struggled to process certain CV layouts, especially scanned documents. Additionally, Tesseract was consuming too much RAM on our VPS and wasn't delivering the high level of accuracy we needed.

Iteration 2: LlamaParse for Better OCR

To solve the weaknesses of Tesseract, we replaced it with a cloud service called LlamaParse.

For context, LlamaParse is a specialized tool created by LlamaIndex. It is designed specifically to "read" and parse complex documents (like PDFs) so AI models can understand them better.

Switching to LlamaParse was a great decision. It allowed us to process any CV format—scanned or digital—and obtain excellent results from the LLM. We ran this setup for a few months until we hit a new problem. This time, it wasn't technical; it was financial. ChatGPT was becoming too expensive.

Iteration 3: The DeepSeek Experiment

My employer started noticing that we were burning too much money on the ChatGPT API. At the same time, DeepSeek was the new arrival in town, taking the internet by storm.

We evaluated DeepSeek for a while. It was actually very good. We migrated from ChatGPT to DeepSeek, and the results were immediate: the budget that lasted one week on ChatGPT now lasted a whole month on DeepSeek, with even better results.

Unfortunately, we used DeepSeek for only two months before hitting a legal wall: GDPR Compliance.

DeepSeek was not compliant with European data protection laws (GDPR/RGPD). Since we were processing the personal data of French citizens, we simply could not continue using it.

The Winning Setup: Google Gemini

We conducted a new migration, this time to Google Gemini, looking for a balance of affordability, efficiency, and compliance.

The result was better than expected. Gemini is so capable that we were able to drop LlamaParse entirely. We now use Gemini for both the Vision/OCR part and the data extraction. The process is very simple: we send the prompt along with the PDF attachment directly to Gemini.

We haven't touched the code for this microservice in over six months because it just works. Everything runs smoothly, and we are fully compliant with GDPR.

Conclusion

This journey taught us that software development is about iteration. We started with a basic open-source OCR, moved to specialized parsing tools, optimized for cost, and finally settled on a solution that offered the best mix of performance and compliance.

Today, the client's recruiters no longer waste time on data entry. They focus on what they do best: finding the right job for the right student.

How to hide username and password fields in the WordPress login form

DERICK TEMFACK — Sat, 20 Aug 2022 12:42:00 +0000

Sometimes on your WordPress site, you don’t want to have the default login form anymore. You might want your users to log in with social login or an external identity provider. In that case, you need to remove the username and password fields.

To achieve that, we’ll use CSS to hide those fields. We’ll only work in the functions.php file through the WordPress admin dashboard. So, you don’t need to be a specialist in WordPress to accomplish this manipulation. Our version of WordPress in this tutorial is 6.0.

Step 1: Log in to your WordPress admin dashboard

After logging in to your WordPress dashboard, navigate to Tools>Theme File Editor.

Step 2: Open the functions.php file

When you are on the theme editor page, localize and open the functions.php file.

Step 3: Insert the code and save

Finally, we’ll insert the following piece of code at the end of the functions.php file and save it.

add_action( 'login_head', 'wpse_121687_hide_login' );
function wpse_121687_hide_login() {
    $style = '';
     $style .= '<style type="text/css">';
     $style .= '.login form .user-pass-wrap{ display: none }';
     $style .= '.login form .submit { display: none }';
     $style .= '.login form .forgetmenot { display: none }';
     $style .= '.login form .input { display: none }';
     $style .= '.login form label { display: none }';
     $style .= '.login  #nav { display: none }';
     $style .= '.login  #mo_saml_button b { display: none }';
    $style .= '#login {margin-top: 150px}';
    $style .= '</style>';

     echo $style; 
}

And voila, we have the desired result.

Conclusion

The purpose of this tutorial was to show you how to hide the username and password fields from the WordPress login form in a proper way. Everyone has his reasons to hide them. If you have encountered a problem applying this tutorial, don’t hesitate to leave a comment. It would be a pleasure for me to help you.

How to deploy Owncloud on Linux Server with docker

DERICK TEMFACK — Tue, 17 May 2022 15:53:22 +0000

Owncloud is a set of collaboratory tools that allow users to store their files, share them and easily collaborate on the same data. It’s an open-source project, so you can download and deploy it on your server without paying anything. Owncloud is a very popular files sharing solution and is extremely used with around 200 million users around the world.

Owncloud has a rich ecosystem and is accessible through various platforms:web, desktop, android, and iOS. It is a suitable solution for all kinds of people, from individual people to big companies with solely the aim to increase productivity. It allows you to build your cloud infrastructure like dropbox to gain your data sovereignty from big tech companies offering cloud storage and file sharing services. You can deploy Owncloud to your server or choose Owncloud Saas to avoid caring about infrastructure.

There is an Owncloud package for all major Linux distributions such as Debian, Ubuntu, Fedora, RedHat Enterprise Linux, CentOS, and OpenSUSE. There is now a docker version of the Owncloud server provided and maintained by Owncloud Inc, the company behind Owncloud. For me, the easy way to deploy it in production is to use docker. So, in this blog post, we will deploy it with docker and perhaps we’ll cover another deployment method in other posts.

Pre-requisite for the deployment of Owncloud

As we choose to deploy Owncloud in production using docker and docker-compose, there are some prerequisites before starting.

A Linux Server with SSH and root access
Docker and docker-compose installed on that server
A domain name pointed to that server

There are too many Linux distributions out there, and everybody should ensure to properly install docker and docker-compose for his Linux distribution. After that, the remaining steps will remain the same for all of you.

Deployment of Owncloud

For Owncloud deployment with docker, we only need two files: a docker-compose file and a .env file. The docker-compose file will allow us to compose the Owncloud server container, MariaDB database, and Redis cached server.

OWNCLOUD_VERSION=latest
OWNCLOUD_DOMAIN=cloud.example.com
ADMIN_USERNAME=admin
ADMIN_PASSWORD=admin
HTTP_PORT=8080
LETSENCRYPT_EMAIL=example@gmail.com

.env file

version: "3.9"

volumes:
  files:
    driver: local
  mysql:
    driver: local
  redis:
    driver: local

services:
  owncloud:
    image: owncloud/server:${OWNCLOUD_VERSION}
    container_name: owncloud_server
    restart: always
    depends_on:
      - mariadb
      - redis
    environment:
      - OWNCLOUD_DOMAIN=${OWNCLOUD_DOMAIN}
      - OWNCLOUD_DB_TYPE=mysql
      - OWNCLOUD_DB_NAME=owncloud
      - OWNCLOUD_DB_USERNAME=owncloud
      - OWNCLOUD_DB_PASSWORD=owncloud
      - OWNCLOUD_DB_HOST=mariadb
      - OWNCLOUD_ADMIN_USERNAME=${ADMIN_USERNAME}
      - OWNCLOUD_ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - OWNCLOUD_MYSQL_UTF8MB4=true
      - OWNCLOUD_REDIS_ENABLED=true
      - OWNCLOUD_REDIS_HOST=redis
      - VIRTUAL_HOST=${OWNCLOUD_DOMAIN}
      - LETSENCRYPT_HOST=${OWNCLOUD_DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
      - VIRTUAL_PORT=${HTTP_PORT}
    healthcheck:
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5
    volumes:
      - files:/mnt/data

  mariadb:
    image: mariadb:10.5
    container_name: owncloud_mariadb
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=owncloud
      - MYSQL_USER=owncloud
      - MYSQL_PASSWORD=owncloud
      - MYSQL_DATABASE=owncloud
    command: ["--max-allowed-packet=128M", "--innodb-log-file-size=64M"]
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-u", "root", "--password=owncloud"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - mysql:/var/lib/mysql

  redis:
    image: redis:6
    container_name: owncloud_redis
    restart: always
    command: ["--databases", "1"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - redis:/data


#Use this configuration in production with nginx-proxy container
networks:
  default:
      name: nginx-proxy
      external: true

docker-compose.yml file

Those files are well configured for a production environment. First, log in to your Linux server with SSH and type the following command to create the directory for Owncloud.

mkdir owncloud && cd owncloud

Now, create a file called docker-compose.yml, copy the content shown in the above docker-compose.yml file and paste it into. Do the same for the .env file.

nano docker-compose.yml
nano .env

Note: if you are not familiar with nano editor, just type CTRL+SHIFT+V to paste content, CTRL+o to save and CTRL+x to quit.

Explanation of docker-compose file

Our docker-compose file is written following the docker compose version 3.9 specification. We have three volumes, three services, and one external network.

Owncloud service

It is the Owncloud container with the server code written in the Go programming language responsible for all the work performed by Owncloud. We use the latest version available in Docker Hub as we specified through the environment variable OWNCLOUD_VERSION.

This service depends on mariadb service and redis service means that it starts solely when mariadb and redis services start. We have many environments variable and we’ll just explain a couple of them.

OWNCLOUD_DB_TYPE=mysql specify the database connector. Owncloud support multiple database engines for production. We have Oracle 11 and 12, PostgreSQL 9, 10, 11, 12, 13 or 14 and MySQL 8+ or MariaDB 10.2, 10.3, 10.4 or 10.5 which is recommended. We use MariaDB 10.5 as recommended by the Owncloud official documentation in this blog post.
OWNCLOUD_DB_HOST=mariadb is the name of the service in the docker-compose file containing the database. In our file, the service is named mariadb and we put it here to let the Owncloud server know where to find the database.
OWNCLOUD_ADMIN_USERNAME=${ADMIN_USERNAME} and OWNCLOUD_ADMIN_PASSWORD=${ADMIN_PASSWORD} set the admin username (which can be an email address) and admin password. We keep those values in the .env file to keep them secure because Owncloud used them to create the admin user of our server and those credentials are used to login and manage the server. Make your password secure.
VIRTUAL_HOST=${OWNCLOUD_DOMAIN} is to tell our reverse proxy server to drive all traffic for OWNCLOUD_DOMAIN to this container.
LETSENCRYPT_HOST=${OWNCLOUD_DOMAIN} and LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL} are used by Let’s Encrypt to issue a free SSL certificate for our domain.
VIRTUAL_PORT=${HTTP_PORT} is to tell the reverse proxy server the port used by the container for the incoming traffic. This value can be ignored in case the default port is 80. Owncloud used port 8080, it’s why we have set this value.

mariadb service

In the mariadb service, we use four environment variables where MYSQL_USER must be the same as OWNCLOUD_DB_USERNAME; MYSQL_PASSWORD the same as OWNCLOUD_DB_PASSWORD, and finally MYSQL_DATABASE the same as OWNCLOUD_DB_NAME. Those variables must be the same to ensure Owncloud is capable to connect to the MariaDB server.

redis service

Redis is an excellent modern memory cache solution to use for distributed caching. It can be used for single and multi-server ownCloud installations, which provide file locking and can be set up in local or distributed environments. It’s used to improve the performance of an Owncloud server thanks to its faster access.

External network

We want our installation to be protected by an SSL certificate, so we connect our containers to an external network connected to a reverse proxy server. Also, this way of deployment allows us to have multiple applications on the same server with docker and protect all of them with a free SSL certificate.

Explanation of .env file

In the .env file, you must change OWNCLOUD_DOMAIN with your domain, ADMIN_USERNAME with the username or email you want to login to the server, ADMIN_PASSWORD with a strong password, and LETSENCRYPT_EMAIL with the email address to be used by let’s encrypt to issue the SSL certificate.

Let’s start our cloud server

We have explained to you all the configurations in the docker-compose file. These configurations are perfect for the production environment and you can easily adjust them according to your needs.

The external network we declare in the docker-compose file doesn’t exist yet. Let’s create it.

docker network create nginx-proxy

Then start your Owncloud instance

docker-compose up --build -d

Our Owncloud instance is now running but is not accessible from the internet. We will now configure Nginx-proxy to drive traffic to it.

Installation of Nginx-proxy and acme-compagnon

Nginx proxy is a container running Nginx and docker-gen which is a service that generates reverse proxy configs for Nginx and reloads Nginx when containers are started or stopped.

This container is mounted on a docker socket to capture all events created by docker to be able to proxied any container with an env variable VIRTUAL_HOST define. All containers that want to be proxied by Nginx-proxy must be connected to the same network with it. To know more about Nginx-proxy, visit the GitHub of the project.

ACME-compagnon is a compagnon for Nginx-proxy responsible to automate the creation, renewal, and use of SSL certificates for proxied Docker containers through ACME protocol. For more information about acme-compagnon, visit the GitHub of the project.

I have a ready-to-use template for Nginx-proxy in my Gitlab repository. You just need to clone and run it. This configuration is well-suited for a production environment. Just type the following command in your terminal to make it run in less than a minute.

cd ~
git clone https://gitlab.com/tderick/nginx-proxy-conf.git 
docker-compose up --build -d

Now, your Owncloud instance is running, and you can access it via your domain name.

After logging in with our credentials, we arrive at the dashboard.

Wrap up

In this tutorial, we have explained to you how to deploy Owncloud in production in your Linux server with docker-compose and secure it with a free SSL certificate issued by Let’s Encrypt. Another thing you can do now is to deploy a keycloak SSO solution next to this to centralize authentication among all your application. It’s pretty easy at this step and doesn’t affect the previous installation. If you are instead a considerable fan of NextCloud, check my other blog post about the deployment of Nextcloud on a Linux server with docker. If you have any questions, leave a comment.

If you like this tutorial, you can buy me coffee. In the upcoming tutorial, we will explore Owncloud and discover what it allows us to do, and also explain how to connect Owncloud and keycloak SSO.

How to deploy NextCloud in your Linux Server with docker and SSL

DERICK TEMFACK — Sat, 14 May 2022 10:51:19 +0000

When you create your account and store your documents, images, etc in Google drive or dropbox, you are not the master of your data. Generally, we say that we use Google or Microsoft one drive for free but it’s not free. We pay for those free spaces with the personal data they collected. It’s where NextCloud comes in. In simple words, Nextcloud is your cloud infrastructure under your control.

What is NextCloud ?

NextCloud is open-source software that allows you to run your personnel cloud service like dropbox. It gives you access to all your files wherever you are. It allows you to share and collaborate on documents, send and receive email, manage your calendar and have video chats. You can install the Nextcloud server software free on your Linux server and the client’s software on your Windows, OS X, or Linux machine, Android, and IOS mobile phone.

The main drawback here is you need to pay for your Linux server to your VPS provider and you will be responsible for your server maintenance unless your choose Nextcloud Enterprise which comes with the support. For example, if you choose the Contabo provider, you can have your fully functional cloud solution with 200GB SSD, 8GO of RAM, and 4vCPU for only $6.99 a month.

Pre-requisite before the installation of Nextcloud

As we will deploy our NextCloud instance with docker, you need to have:

A Linux Server with SSH and root access
Docker and docker-compose installed on that server
A domain name pointed to that server

Deployment of NextCloud

POSTGRES_PASSWORD=yourdbstrongpassword
POSTGRES_DB=nextcloud
POSTGRES_USER=nextcloud

db.env file

version: "3.9"

services:
  nextcloud_db:
    image: postgres:alpine
    restart: always
    volumes:
      - nextcloud_dbdata:/var/lib/postgresql/data
    env_file:
      - db.env

  redis:
    image: redis:alpine
    restart: always

  nextcloud_web:
    image: nextcloud:apache
    restart: always
    volumes:
      - nextcloud:/var/www/html
    environment:
      - VIRTUAL_HOST=cloud.yourdomain.com
      - LETSENCRYPT_HOST=cloud.yourdomain.com
      - LETSENCRYPT_EMAIL=yourmail # <===== For let's encrypt
      - POSTGRES_HOST=nextcloud_db
      - REDIS_HOST=redis
    env_file:
      - db.env
    depends_on:
      - nextcloud_db
      - redis

  cron:
    image: nextcloud:apache
    restart: always
    volumes:
      - nextcloud:/var/www/html
    entrypoint: /cron.sh
    depends_on:
      - nextcloud_db
      - redis

volumes:
  nextcloud_dbdata:
  nextcloud:

#Use this configuration in production with nginx-proxy container
networks:
  default:
    external:
      name: nginx-proxy

docker-compose.yml file

mkdir nextcloud && cd nextcloud
nano db.env

Copie the content of the db.env in the above GitHub gist and paste it into the newly created file. After this, create a docker-compose.yml file and copy the content of the docker-compose.yml in the above Github gist and paste it into.

Note: Don’t forget the change the environment variables VIRTUAL_HOST and LETSENCRYPT_HOST with your domain name and LETSENCRYPT_EMAIL with your email address.

Now, it’s time to create the docker network that would be used to drive secure traffic to our Nextcloud instance through our domain name.

docker network create nginx-proxy

Then let’s start our Nextcloud instance.

docker-compose up --build -d

Our Nextcloud instance is now running but is not accessible from the internet. We will now configure Nginx-proxy to drive traffic to our Nextcloud instance. We will explain our docker-compose file after making our instance fully functional.

Installation of Nginx-proxy and acme-compagnon

Nginx proxy is a container running Nginx and docker-gen which is a service that generates reverse proxy configs for Nginx and reloads Nginx when containers are started or stopped.

I have a ready-to-use template for Nginx-proxy in my repository. You just need to clone and run it. I also use this template in all my projects. With this configuration, it’s easy to make things work in less than a minute. Just use the following command.

cd ~
git clone https://gitlab.com/tderick/nginx-proxy-conf.git 
docker-compose up --build -d

Now, your Nextcloud instance is running, and you can access it via your domain name.

When you install Nextcloud, it doesn’t come with an admin account by default. You need to create it. Just fill in the form on the first page and hit the install button. Don’t put email as username. if you do, you have the following error:

After putting in a username and password, we will arrive at the following page listing the recommended apps to install in our instance.

We can see there are applications for:

Calendar
Contacts
Mail
Online edition and collaboration

We will install other applications later. Just hit the install recommended apps button.

Our nextcloud instance is now installed and ready to use. Now, we can explain our docker-compose file to understand the magic behind this.

Docker-compose file explanation

In this docker-compose file, we use version 3.9 and we expose three services, two volumes, and one default external network.

nextcloud_db service

Nextcloud support multiple DBMS: MySQL, MariaDB, Oracle, PostgresSQL. It’s up to you to choose your favorite DBMS. We choose to use Postgres as it is a very powerful solution.

redis service

Redis is an excellent modern memory cache solution to use for distributed caching. It’s used by Nextcloud to significantly improve the Nextcloud server performance with memory caching where frequently-requested objects are stored for faster retrieval.

nextcloud_web service

It’s the official Nextcloud container with all the features offered.

cron service

Cron is a simple time-based job scheduler that runs small tasks on its own without the intervention of the user or the administrator. Cron is also an important part for Nextcloud to be running efficiently.

Wrap up

In this tutorial, we explain to you how to deploy your Nextcloud instance in your Linux server with docker-compose and secure it with a free SSL certificate issued by Let’s Encrypt. Another thing you can do now is to deploy a keycloak SSO solution next to this to centralize authentication among all your application. It’s pretty easy at this step and doesn’t affect the previous installation. If you are instead a considerable fan of Owncloud, check my other blog post about the deployment of OwnCloud on a Linux server with docker. If you have any questions, leave a comment.

If you like this tutorial, you can buy me coffee. In the upcoming tutorial, we will more explore Nextcloud.

How to deploy SSO (keycloak) on Linux server with docker-compose and SSL in less than 10min

DERICK TEMFACK — Sun, 24 Apr 2022 16:21:12 +0000

This article is also available on my blog. Check it out to support me.

An SSO( Single Sign-On) is a system that allows users to access multiple services/platforms with the same credential. This system is very popular today and is used by the giants of the internet (Google, Facebook, etc). There are many platforms that sell this type of service among onelogin, okta, etc. In this story, we’ll set up our own SSO servers using keycloak.

Prerequisite

A Linux Server with SSH Access
Docker and docker-compose installed on this server
A domain name point to this server

What is KeyCloak?

KeyCloak is an open-source Identity and Access Management that allows us to add authentication in our application and secure service with minimum effort. It is a community project sponsored by Red Hat. Red Hat use it in their own products and also distribute it to their client as Red Hat SSO.

KeyCloak is a java project and is based on two popular protocols: SAML 2 and OpenID Connect. With keycloak, you can easily enable social login or use an existing LDAP/Active Directory as a user federation.

Keycloak is a very extensible tool and it gives you the possibility to customize it based on your need. It’s the best free SSO solution on the market and you can definitely choose it without being afraid if you want to set up your own SSO server. For further information, check their well-written documentation.

Installation of KeyCloak

I have already prepared a docker-compose file for you and it is the one that I use to deploy keycloak in my production environment.

version: "3.9"

services:
  postgres:
    image: postgres:13.2
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRESQL_DB}
      POSTGRES_USER: ${POSTGRESQL_USER}
      POSTGRES_PASSWORD: ${POSTGRESQL_PASS}
    volumes:
      - postgres_data:/var/lib/postgresql/data

  keycloak:
    depends_on:
      - postgres
    container_name: keycloak
    environment:
      DB_VENDOR: postgres
      DB_ADDR: postgres
      DB_DATABASE: ${POSTGRESQL_DB}
      DB_USER: ${POSTGRESQL_USER}
      DB_PASSWORD: ${POSTGRESQL_PASS}
      VIRTUAL_HOST: ${VIRTUAL_HOST}
      LETSENCRYPT_HOST: ${LETSENCRYPT_HOST}
      LETSENCRYPT_EMAIL: ${LETSENCRYPT_EMAIL}
      VIRTUAL_PORT: "8080"
      HTTPS_METHOD: redirect
      PROXY_ADDRESS_FORWARDING: "true" # <==== very important if you use reverse proxy
    image: jboss/keycloak:${KEYCLOAK_VERSION}
    restart: unless-stopped

volumes:
  postgres_data:

#Use this configuration in production with nginx-proxy container
networks:
  default:
    external:
      name: nginx-proxy

docker-compose.yml file

KEYCLOAK_VERSION=16.1.1
PORT_KEYCLOAK=8080
POSTGRESQL_USER=keycloak
POSTGRESQL_PASS=keycloak
POSTGRESQL_DB=keycloak
VIRTUAL_HOST=example.com
LETSENCRYPT_HOST=example.com
LETSENCRYPT_EMAIL=example@gmail.com

.env file

Our docker-compose file exposes two services, one volume, and one external network.

Postgres service
Keycloak supports many databases like Postgres, MySQL/MariaDB, Oracle, etc. We use in our case Postgres.

Keycloak service
This service depends on Postgres service. This means that the Postgres service will start or stop before the keycloak service. Keycloak has many different images in the Docker hub and we will use the one provided by the JBoss community. As we use Nginx-proxy as a reverse proxy and acme-compagnon for Let’s Encrypt certificate, we need to add three special environment variables in the keycloak service.

VIRTUAL_HOST indicate the domain name (or subdomain name) that keycloak will be accessible through (VIRTUAL_HOST=auth.example.com)
LETSENCRYPT_HOST contains the same value as VIRTUAL_HOST and indicates to acme-compagnon to ask for SSL certificate for this domain (or subdomain ) to Let’s encrypt
LETSENCRYPT_EMAIL contains a valid email address required by let’s encrypt servers to issue an SSL certificate for our domain and to send notifications when the SSL certificate will be expired.
PROXY_ADDRESS_FORWARDING is set to true when we run keycloak behind a reverse proxy. Without this variable set to true, we can’t log in to our keycloak server.

network

We use the Nginx-proxy container as a reverse proxy and it required all containers to be connected to a unique network so that it can easily handle traffic to them.

The .env file is the one that contains all environment variables we use in our docker-compose file. We place it in the same directory with the docker-compose file and it’s automatically discovered when we make a docker-compose up. You can modify it according to your need. If you don’t want to copy and paste the content of those files, you can clone the project with all this configuration from my repository.

If you want to copy and paste, let’s do it. First, create a directory in your Linux server for this project.

mkdir keycloak && cd keycloak

Secondly, copy the content of my docker-compose file and paste it into the docker-compose file you create in this directory.

nano docker-compose.yml

Do the same with the .env file.

nano .env

Start keycloak service
Before starting keycloak, we need to create the external network that we declare in our docker-compose file.

docker network create nginx-proxy

After that, we can run our container.

docker-compose up --build -d

When starting keycloak for the first time, there are no users in his database, we need to create an admin user to manage our keycloak instance. To do that, use the following command:

docker exec keycloak \
    /opt/jboss/keycloak/bin/add-user-keycloak.sh \
    -u admin \
    -p admin \
&& docker restart keycloak

This command will add a user in the keycloak database with username admin and password admin. Change the password to a more secure one. Now, our keycloak server is ready. We can now install Nginx-proxy to make it accessible.

Installation of Nginx-proxy and acme-compagnon

Nginx proxy is a container running Nginx and docker-gen which is a service that generates reverse proxy configs for Nginx and reloads Nginx when containers are started or stopped.

Again, I also have a prepared project in my repository to use without further configuration. You just need to clone and run it. I also use this template in all my projects. With this configuration, it’s easy to make things work in less than a minute. Just use the following command.

cd ~
git clone https://gitlab.com/tderick/nginx-proxy-conf.git 
docker-compose up --build -d

Check your domain name and you will see the following output.

Click on “Administration console” and log in with the credential we created early.

Congratulation, you have deployed an SSO system in your own server using docker and protected it with a free SSL certificate issued by Let’s Encrypt.If you encounter a problem during the process, leave a comment and I will help you.

In the upcoming stories, we will explore more keycloak. If you like this content, you can buy me a coffee.