Cloud Native 6 min read

Using a Monorepo with GitLab CI/CD and Docker for Multi‑Service Applications

This article explains the benefits of a monorepo for multi‑service web apps and demonstrates how to build, test, and deploy backend and frontend services using Docker, docker‑compose, and GitLab CI/CD pipelines that run only for changed components.

DevOps Cloud Academy
DevOps Cloud Academy
DevOps Cloud Academy
Using a Monorepo with GitLab CI/CD and Docker for Multi‑Service Applications

Modern web applications often consist of multiple services such as a backend API and a frontend client, and large projects may further split these into micro‑services. A monorepo stores all source code in a single repository, simplifying code reuse and dependency management, though versioning and deployment become more complex.

The article uses a simple two‑service example (backend and frontend) to illustrate the monorepo concept. The repository layout is shown below:

monorepo/
    backend/
        src/
        Dockerfile
    frontend/
        src/
        Dockerfile
    .git/
    .gitignore
    .gitlab-ci.yaml
    docker-compose.yaml

Each service has its own Dockerfile , and a docker-compose.yaml file is used for local development. The same approach can be applied in production, optionally with orchestration tools like Kubernetes.

The CI/CD pipeline aims to automatically build, test, and deploy the application whenever new code is pushed to GitLab. GitLab CI/CD provides stages such as build , test , and deploy . To avoid rebuilding unchanged services, the pipeline uses the only/changes clause with path‑based regular expressions.

For example, the backend build job is defined as:

backend_build:
  stage: build
  only:
    changes:
      - "backend/**/*"
  ...

The corresponding script, which runs in the job, consists of four commands:

docker login -u $DOCKER_USER -p $ACCESS_TOKEN $CI_REGISTRY
cd backend
docker build -f Dockerfile --tag latest .
docker push latest

These steps log in to the GitLab Docker Registry, navigate to the backend directory, build the Docker image, and push it to the registry.

Testing is performed in a separate job (e.g., backend_test ) using the same scripts as in the local development environment, and more complex tests such as integration or end‑to‑end can also be added.

After successful build and test, deployment jobs log into the target server and pull the newly built images from the GitLab Docker Registry, completing the automated delivery process.

In summary, a monorepo can effectively organize the source code of multi‑service applications, and although deployment becomes more involved, a single tool like GitLab—combining repository management, powerful CI/CD pipelines, and a private Docker registry—can handle the entire workflow.

cloud nativedockerCI/CDDevOpsMonorepoGitLab CI
DevOps Cloud Academy
Written by

DevOps Cloud Academy

Exploring industry DevOps practices and technical expertise.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.