CI/CD Pipeline

A key focus of this development phase was establishing a reliable and highly automated CI/CD infrastructure. The goal was to simplify the entire deployment process, minimize potential sources of error, and deploy new versions with minimal manual effort.

Architecture

GitHub serves as the central source for all source code; all relevant repositories are managed and version-controlled there. GitHub acts as the "single source of truth," ensuring it is always clear which code is intended for production use.

Whenever new code is pushed to one of the frontend repositories, GitHub automatically triggers a webhook. This webhook is received by a custom FastAPI service running on our server.

The webhook service is responsible for initiating deployments in a controlled, automated manner. Each container has its own dedicated deployment script and API endpoint. When an endpoint is called with the correct API key, the corresponding deployment process begins.

The workflow proceeds as follows:

1. GitHub sends a webhook to the server.
2. The FastAPI service validates the request.
3. The corresponding deployment script is executed.
4. The latest source code is fetched from the repository.
5. A new Docker image is built.
6. The existing container is replaced by the new version.

This ensures that new frontend versions are automatically deployed following a successful push.

Backend Deployment

We use a slightly modified workflow for the backend.

Since the goal is for others to be able to self-host the project easily in the long run, we decided to build the Docker images centrally using GitHub Actions. This means future users do not need to compile the backend themselves; instead, they can use a pre-built image directly. Currently, the build pipeline is triggered by the following events:

• Creation of a new release
• Manual workflow initiation via GitHub Actions

Upon initiation, GitHub Actions automatically creates a new Docker image for the backend. The image is currently private but is intended to be made publicly available in the future, allowing other users to utilize it directly.

Once the build process completes successfully, an endpoint of our FastAPI webhook service is called. Unlike the frontend process, this step does not require downloading source code. Instead, only the newly created Docker image is pulled, and the existing container is recreated.

Optimizations

During the development of the deployment pipeline, special attention was paid to Docker image efficiency.

For the backend, we utilize a multi-stage Docker build. This separates build dependencies from the runtime dependencies actually required. Consequently, unnecessary files are excluded from the final image entirely.

This resulted in a significant reduction in image size—down to approximately one-third of the original size.

Smaller images offer several advantages:

• Faster build times
• Shorter download and deployment times
• Lower storage consumption
• Reduced attack surface due to fewer included components

Advantages of the Approach

The developed CI/CD pipeline offers several benefits:

• Fully traceable deployments
• Automated deployment of new versions
• Reduction of manual errors
• Ease of maintenance
• Good scalability for future extensions
• Simplified self-hosting via pre-built Docker images

This architecture enables the automated building and deployment of new versions within minutes, while maintaining a clear separation between source code, the build process, and the production system.