Your source code and build artefacts stay inside your walls
A complete self-hosted software delivery platform on GitLab — source control, CI/CD, private registry, static analysis and observability — replacing commercial SaaS and keeping every commit and artefact in your own infrastructure.
Five layers, one platform
Each layer is open source, self-hosted and integrated with the others. There is no component here that ships your code to somebody else’s cloud.
GitLab
Source control, merge request review and CI/CD automation. Branch protection, approval rules and pipeline gates set so a change cannot reach production without passing them.
Harbor private registry
Every container image built by the pipeline is stored in your own registry and scanned for known vulnerabilities before it can be promoted.
SonarQube
Static analysis on every merge request with security quality gates, so code that fails the standard is blocked rather than flagged and forgotten.
Prometheus and Grafana
Metrics, dashboards and alerting across the platform and the applications it delivers.
FreeIPA
Central identity and access management, so every action on the platform belongs to a named person with an audit trail.
Runners and environments
Build runners sized to your pipeline load, and separated development, staging and production environments with controlled promotion between them.
What this replaces, and why
Most clients arrive with commercial SaaS tooling and one of three problems.
Code leaving the building
Source and build artefacts sitting in a third-party cloud is a finding in a PCI DSS or ISO 27001 audit, and in some contracts it is a breach. Self-hosting closes it.
Per-seat cost that scales badly
SaaS delivery tooling is priced per developer. At a certain team size, running the same capability on your own infrastructure is materially cheaper and the cost stops growing with headcount.
No evidence for the auditor
“We do code review” is not evidence. Enforced approval rules, blocking quality gates and scan results are. The platform produces them as a by-product of working normally.
Design, build, migrate, operate
1. Design
Repository and branching model, pipeline stages, environments, approval rules and who can promote to production. Decided with your team, written down.
2. Build
Platform stood up on your infrastructure or your cloud tenancy, hardened, with identity and backup in place before a single repository is migrated.
3. Migrate
Repositories, history, CI configuration and artefacts moved project by project. The old platform stays live until each project is proven.
4. Operate
Upgrades, runner capacity, certificate rotation, scan findings triaged and the platform documented for audit, under a written service agreement.
Proven in production
Client names stay private. The environment does not.
- Built for an enterprise outsourcing group in Egypt, replacing commercial SaaS delivery tooling.
- In production across eight projects, not a pilot.
- All source code and build artefacts held inside the client’s own infrastructure.
- Documented as evidence for ISO 27001, PCI DSS and SOC audits.
- Related work: DevOps and system administration on a national e-payment platform, operated with a 24/7 SOC.
Common questions
Can this run on our own servers?
Yes, that is the point of it. It runs on your hardware, in your data centre, or inside your own AWS or Azure tenancy.
We already use GitLab SaaS. Is moving worth it?
Sometimes. It depends on team size, on whether your contracts or your auditor require the code to stay in your control, and on what you are paying per seat. We will model it rather than assert it.
Do you write the pipelines, or just install it?
We build the pipelines with your developers, including the quality gates and the promotion rules. A platform nobody has configured is shelfware.
Does this satisfy an auditor?
The controls an auditor asks about — enforced review, access by named account, vulnerability scanning, segregation of environments — are enforced by the platform and evidenced automatically. Our compliance team packages that evidence in the format the auditor expects.
What if our developers resist it?
A fair concern, and usually the real risk. We migrate project by project and keep the old tooling live until each team is working comfortably on the new platform.
Tell us how many developers and how many repositories.
That is enough for us to size the platform, model the cost against what you pay today, and show you what the audit evidence looks like.
02 3537 5791