In the Swiss banking sector, modernizing IT infrastructure is not just a technical project. It is a balancing act between innovation, regulatory compliance, and security. When a Geneva-based private bank decided to rethink how it builds and distributes its applications, it called on Hidora to support this transformation.
This consulting mission, carried out over several months, illustrates how a small but motivated IT team can adopt DevOps practices in an environment as demanding as private banking.
The context: a small IT team with big technical ambitions
The bank had an IT team of four people. Despite its modest size, this team carried all technical responsibilities: application development, system maintenance, infrastructure management, and internal user support.
The existing infrastructure relied on traditional methods. Deployments were manual, testing environments did not formally exist, and each release to production carried significant risk. Internal applications, while functional, suffered from a lack of standardization in their lifecycle.
Thibault Fouache, Software Engineer at the bank, was the driving force behind this modernization project. Passionate about DevOps, he had identified the limitations of the existing approach and wanted to implement a more robust, automated, and professional infrastructure.
"I was passionate about DevOps and wanted to find a new way to build and distribute applications within the bank. Hidora supported us throughout the entire setup." -- Thibault Fouache, Software Engineer
Challenges specific to the banking sector
Modernizing a private bank's infrastructure is not simply about installing Kubernetes and deploying containers. Several specific constraints had to be considered from the outset.
Security and compliance
In the banking world, every technical component must meet strict security requirements. Sensitive client data, transactional flows, internal communications: everything must be encrypted, auditable, and compliant with current regulations. The target infrastructure had to integrate these constraints natively, without compromise.
Non-standard SSL certificates
One of the most significant technical challenges of this mission involved SSL certificate management. Unlike standard environments that use public certificate authorities (Let's Encrypt, DigiCert, etc.), the bank required the use of certificates issued by internal certificate authorities specific to the banking sector.
This constraint impacted the entire chain: the Kubernetes cluster, Docker image registries, CI/CD pipelines, and monitoring tools. Each component had to be configured to recognize and accept these non-standard certificates, which required meticulous configuration work on every building block of the architecture.
Isolated environment
The infrastructure had to operate within a partially isolated network, with restricted internet access and strict firewall policies. Downloading Docker images from the public Docker Hub or installing packages from external repositories was not straightforward. Everything had to go through internal mirrors or private registries.
The solution implemented
The mission ran from May to September, at a pace of two to three days per week on-site. This regular presence allowed close collaboration with the internal team, progressive training of the developers, and the ability to adapt technical choices based on real-world feedback.
Rancher on Kubernetes
The core of the new infrastructure was built on Rancher, a Kubernetes cluster management platform. Rancher was chosen for several reasons. First, its graphical interface allowed the team, which was new to Kubernetes, to visualize and understand container orchestration concepts without immediately mastering the full complexity of kubectl on the command line. Second, Rancher offered multi-cluster management and role-based access control (RBAC) features, essential in a banking context.
The Kubernetes cluster was deployed on-premise, on the bank's physical infrastructure. No public cloud here: data had to remain within the institution's walls.
GitLab CI/CD
To automate deployments, GitLab was set up with its integrated CI/CD pipelines. Each application now had a complete pipeline: compilation, unit tests, code quality analysis, Docker image building, publishing to the private registry, and deployment to the Kubernetes cluster.
This pipeline represented a fundamental change for the team. No more manual deployments via FTP or SSH. Every code change went through an automated, reproducible, and traceable process.
Nexus: private artifact registry
Nexus Repository Manager was deployed as the central registry for all infrastructure artifacts: Docker images, Java libraries, npm packages, and various dependencies. In a banking environment with restricted internet access, Nexus served as a proxy and cache for public repositories, while also acting as the private registry for internal artifacts.
SonarQube: code quality
SonarQube was integrated into the CI/CD pipelines to automatically analyze code quality on every commit. Bug detection, security vulnerabilities, technical debt, test coverage: the team now had objective metrics on the health of their code.
For a small team, this automated visibility into code quality was particularly valuable. It allowed them to identify issues before they reached production.
Monitoring: Centreon, Rudder, and Graylog
Infrastructure monitoring was built with three complementary tools.
Centreon handled infrastructure and service monitoring: server availability, CPU and memory usage, disk space, and critical service status. Alerts were configured to notify the team of degradation before users were impacted.
Rudder managed configuration management and server compliance. In a banking context, being able to prove that every server complies with defined security policies is not optional. Rudder allowed these policies to be applied and verified automatically.
Graylog centralized logs from the entire infrastructure. Applications, system services, Kubernetes components: all logs converged to Graylog to be indexed, searched, and correlated. In case of an incident, the team could precisely trace the chain of events.
Knowledge transfer
Beyond the technical implementation, a key part of the mission focused on knowledge transfer. The goal was not for Hidora to remain indefinitely: the bank's team needed to become autonomous on their new infrastructure.
Each installed component was documented. Each architectural decision was explained. The bank's developers actively participated in the configuration, asked questions, made mistakes, and learned. The regular working sessions, two to three times per week, enabled progressive, practice-based learning.
By the end of the mission, the four-person team was capable of managing their Kubernetes cluster via Rancher, creating and modifying CI/CD pipelines in GitLab, publishing Docker images to Nexus, monitoring their infrastructure, and responding to alerts.
Results
The infrastructure transformation produced concrete results for the bank.
Reliable deployments. Production releases, once a source of stress and risk, became routine operations. The CI/CD pipeline ensured that every deployed version had passed tests, quality analysis, and automated builds.
Increased visibility. The team had, for the first time, a complete view of the state of its infrastructure and applications. Centreon dashboards, SonarQube reports, Graylog logs: every aspect was covered.
Greater confidence. The IT team gained confidence in its ability to manage a modern infrastructure. The fear of deployment gave way to a methodical and controlled approach.
Professional application management. The transition to Docker containers orchestrated by Kubernetes, combined with Rancher as the management interface, enabled a much more professional management of the application lifecycle.
Lessons from this mission
This mission illustrates several important points for organizations considering a similar modernization.
First, team size is not a barrier. With four motivated people and good support, it is entirely possible to adopt professional DevOps tools and practices.
Second, the banking sector, despite its constraints, is not incompatible with Kubernetes and modern practices. It simply requires additional time for security-related configuration, particularly around non-standard SSL certificate management.
Third, knowledge transfer is as important as the technical implementation itself. A modern infrastructure without the skills to maintain it serves no purpose. Regular on-site presence, pair work, and documentation are essential.
Finally, good external support helps avoid common pitfalls and significantly accelerates adoption. Hidora's experience with Kubernetes projects in secure contexts saved valuable time resolving issues that could have blocked the team for weeks.
This mission remains one of the most rewarding projects Hidora has carried out. Watching a team go from manual deployments to a complete Kubernetes infrastructure with CI/CD, monitoring, and configuration management, all within a secure banking environment, is exactly the kind of transformation we love to support.
