The best way to understand infrastructure is to build it incrementally, observing how each decision shapes security, operability, and trust.
This project started as a simple question: How can I expose a self-hosted GitLab instance safely without jumping straight into enterprise tooling? The answer turned into a small but realistic DevOps lab.
The Goal
The goal was to deploy GitLab Community Edition in a way that mirrors real-world infrastructure decisions, while remaining safe, observable, and reversible.
This lab focuses on:
- hosting GitLab on a private virtual machine
- exposing it to the internet in controlled stages
- progressively reducing implicit trust
- using only free or community-tier tooling
The Scenario
Hosting GitLab yourself is not difficult.
Hosting it responsibly is.
Exposing GitLab directly to the internet invites scanners, brute-force attempts, and unnecessary risk. Instead of starting with a fully locked-down design, this lab explores how to expose GitLab progressively, adding security layers only when they are understood and justified.
The Initial Idea
Instead of exposing GitLab directly to the internet, the system is built in layers:
- GitLab lives in a private VM
- A reverse proxy handles public traffic
- Cloudflare eventually becomes the gatekeeper
Each layer adds responsibility — and reduces risk.
Phase 1 — Make It Work
At first, the goal is simple: make GitLab reachable.
GitLab runs inside a VM with no public IP. The host server owns the public address and forwards requests using Nginx.
This already provides:
- isolation
- easy rebuilds
- clean separation of concerns
But it is still trust-based access.
Phase 2 — Stop Trusting the Network
Once GitLab works, security becomes the focus.
Instead of asking "Is this request coming from the right IP?", the system asks:
Who is this user, and should they be here?
Cloudflare Zero Trust sits in front of GitLab and enforces identity-based access.
Why This Matters
Even though this is a lab:
- the architecture mirrors real enterprise setups
- Zero Trust concepts are applied correctly
- no infrastructure redesign was required mid-way
Most importantly, the system evolved incrementally.
Lessons Learned
- Reverse proxies are foundational
- Identity beats IP-based security
- Free tiers are enough to learn real concepts
- Phased designs reduce mistakes
Where to Go Next
This lab can be extended in many directions:
- Cloudflare Tunnel instead of exposed ports
- HTTPS-only Git operations
- GitLab runners
- Infrastructure as Code
- Migration to KVM or Proxmox
Repository
The full lab — including Vagrant configuration, provisioning scripts, and step‑by‑step documentation — is available here:
👉 https://github.com/iuri-covaliov/devops-labs/tree/main/GitLabSE-behind-CloudFlare
This repository is intended to be read alongside the article: the article explains why each layer exists, while the repository shows how it is implemented.
Final Thoughts
This project demonstrates that Zero Trust is not a product — it is a design approach.
By starting simple and layering security intentionally, even a small home lab can teach patterns that scale to real-world systems.
Top comments (0)