GitLab CE Git forge
Your code is often your most sensitive asset. GitHub (Microsoft), Bitbucket (Atlassian) and Azure DevOps host it outside Europe, under US law (CLOUD Act). Bunker hosts GitLab Community Edition, the open-source software forge, on your own domain and in Europe: Git repositories, continuous integration, image registry and issue tracking in one place.
Access: your own domain (for example gitlab.yourcompany.com)
The service deploys GitLab Community Edition (CE), under the free MIT licence. It is not affiliated with GitLab Inc. or its Enterprise editions; "GitLab" is a trademark of GitLab Inc.
Why GitLab CE?
GitLab CE brings into a single tool what usually needs several services: Git repository hosting, code review through merge requests, built-in CI/CD pipelines, a Container Registry for your Docker images, and issue tracking. GitLab CE is that platform deployed, maintained and backed up by Bunker, on your domain.
Your repositories and build artifacts stay on Bunker servers, in Europe.
Comparison with alternatives
| Criterion | Bunker | GitHub | Bitbucket | Azure DevOps |
|---|---|---|---|---|
| Open source | Yes (MIT) | No | No | No |
| Sovereign hosting | Yes (Europe) | No (USA) | No (USA) | No (USA) |
| Own domain | Yes | Paid | Paid | No |
| Built-in CI/CD | Included | Included | Included | Included |
| Container Registry | Included | Included | Paid | Included |
| Full reversibility | Yes (git, pg_dump) | Partial | Partial | Partial |
| High availability | Guaranteed | Yes | Yes | Yes |
| Automatic backups | Yes | Plan-dependent | Plan-dependent | Plan-dependent |
| Ops cost | Zero | Zero | Zero | Zero |
In practice
The GitLab CE source code is auditable by anyone. Under the MIT licence, no black box and no dependency on a US vendor.
Your repositories belong to you. You can leave Bunker tomorrow and reinstall GitLab CE on your own server with all of your data.
Your code and project history stay in Europe, under European law. No CLOUD Act, no access by foreign authorities.
Git repositories and merge requests
The heart of the forge hosts your Git repositories with all the collaboration around them:
- Merge requests with code review, line-by-line discussions and approvals
- Branch protection (push rules, required reviews before merge)
- Web IDE to edit a file without cloning the repository
- Code search across all your projects
- Wikis and snippets per project
Gitaly handles repository access with good performance, even on large histories.
Continuous integration (CI/CD)
Pipelines are defined in a .gitlab-ci.yml file at the root of your repository:
stages:
- test
- build
test:
stage: test
image: node:22
script:
- npm ci
- npm test
build:
stage: build
image: docker:27
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
Runners execute your jobs on every push. Runner sizing adapts to your needs (see also our managed GitLab Runner service for runners on Kubernetes, without privileged mode).
Container Registry
Every project has a built-in Docker image registry:
- Push and pull your images from pipelines or locally
- Layers stored on S3 object storage hosted in Europe
- Automatic cleanup of old tags (retention policies)
# Log in to the project registry
docker login registry.gitlab.yourcompany.com
# Push an image
docker push registry.gitlab.yourcompany.com/my-group/my-project:latest
Issue tracking and project management
- Issues with labels, milestones, assignment and discussion threads
- Boards to visualise the workflow
- Epics and roadmaps at group level
- Automatic links between commits, merge requests and issues
API and webhooks
GitLab CE exposes a full REST API and real-time webhooks to automate your processes:
| Webhook event | Description |
|---|---|
push | Code has been pushed to a branch |
merge_request | A merge request was opened, updated or merged |
pipeline | A pipeline changed state |
issue | An issue was created or updated |
# Example: list projects via the API
curl -H "PRIVATE-TOKEN: YOUR_TOKEN" \
https://gitlab.yourcompany.com/api/v4/projects
Bunker vs self-hosting
You could install GitLab CE on your own server. But:
| Aspect | Self-hosting | Bunker |
|---|---|---|
| High availability | Your responsibility | Guaranteed |
| Backups | To configure | Automatic |
| Security updates | To monitor | Applied |
| SSL certificates | To renew | Managed |
| 24/7 monitoring | To set up | Included |
| HA database | PostgreSQL to manage | CNPG PostgreSQL (replicated) |
A forge that is down blocks all your development teams. With Bunker, availability and backups are guaranteed. The database is managed by CNPG (CloudNativePG) with replication for high availability.
Quick start
1. Activate the service
- Go to console.getbunker.net
- Create your Bunker account or sign in
- Activate the GitLab CE service and set the desired domain (e.g.
gitlab.yourcompany.com)
2. Create a project
- Click New project
- Choose a name and a visibility (private, internal, public)
- Copy the repository clone URL
3. Push your first repository
git remote add origin [email protected]:my-group/my-project.git
git push -u origin main
4. Run a pipeline
Add a .gitlab-ci.yml file at the root, push, and the pipeline starts automatically. Follow its run under CI/CD → Pipelines.
Portability
The forge hosts your teams' code assets. With GitLab CE:
- Your repositories are standard Git repositories, cloneable and movable as they are
- Metadata (issues, merge requests, users) exports via
pg_dumpfrom the PostgreSQL database - Registry artifacts, packages and images are S3 objects you can download again
- MIT licence guaranteeing the longevity of the software
If Bunker disappears tomorrow, you export your data and reinstall GitLab CE on your own instance. Try doing that with Azure DevOps.
References
- GitLab documentation to go further
- Managed GitLab Runner for CI runners on Kubernetes
- Externalised backups for complete protection