DEV Community: Iuri Covaliov

GitLab CI Caching Didn’t Speed Up My Pipeline — Here’s Why

Iuri Covaliov — Thu, 19 Mar 2026 14:33:36 +0000

Most DevOps guides say:

“Enable caching — it will speed up your CI pipelines.”

I’ve done that many times in my career. Here I'd like to share with you some of my thoughts on the topic illustrating it with a little experiment.

I built a small GitLab CI lab, added dependency caching. Are you expecting faster runs?

The result might surprise you:

My pipeline didn’t get faster at all.

In fact, in some cases, it was slightly slower.

Before jumping to conclusions — this is not a post against caching.

Caching worked exactly as expected.
It just didn’t translate into faster pipeline duration in this particular setup.

And that’s the part worth understanding.

This article is not about how to enable caching.
It’s about what actually happens after you enable it — and why the outcome might not match expectations.

What I Wanted to Test

I wanted to validate a simple assumption:

Does dependency caching really reduce pipeline duration?
Where does the improvement come from?
When is caching actually worth it?

So I built a small Python project with a multi-stage GitLab CI pipeline and measured the results.

The Setup

The pipeline has three stages:

prepare → install dependencies
quality → compile/lint
test → run tests

Each job installs dependencies independently — just like in many real-world pipelines.

To make the effect visible, I used slightly heavier dependencies:

pandas
scipy
scikit-learn
matplotlib

Baseline: No Cache

Each job runs:

time pip install -r requirements.txt

As expected:

dependencies are downloaded in every job
work is repeated across stages
every pipeline run starts from scratch

Results

Run	Duration
#1	~38s
#2	~34s

Adding Cache

I introduced GitLab cache:

.cache:
  cache:
    key:
      files:
        - requirements.txt
    paths:
      - .cache/pip
    policy: pull-push

And configured pip:

PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"

Now dependencies should be reused between jobs and runs.

The Result

Mode	Run	Duration
No cache	1	~38s
No cache	2	~34s
With cache	1	~40s
With cache	2	~38s

Almost no difference.

Why Didn’t It Get Faster?

1. Fast package source

If your runner uses a nearby mirror (for example, Hetzner), downloads are already fast.

2. pip is efficient

Modern Python packaging uses prebuilt wheels, making installs quick.

3. Cache has overhead

archive creation
upload/download
extraction

This overhead can cancel the benefit.

4. CI jobs spend time elsewhere

container startup
image pulling
repo checkout

The Real Takeaway

Dependency caching is not automatically a performance optimization.

Its impact depends on:

dependency size
network conditions
runner configuration
pipeline structure

When Caching Helps

large dependency trees
slow networks
distributed runners
frequent pipeline runs

When It Might Not Help

small projects
fast mirrors
short pipelines
high cache overhead

Not Just About Speed

Caching can still:

reduce outbound traffic
improve resilience
reduce dependency on external registries

What’s Next

Next step:

testing shared cache with S3-compatible storage

Repo

You can find the full lab here:
👉 https://github.com/ic-devops-lab/devops-labs/tree/main/GitLabCIPipelinesWithDependencyCaching

Final Thought

Not every best practice gives a measurable improvement — but understanding why is where real DevOps begins.

GitLab SE behind Cloudflare Zero Trust: Private CI Runner

Iuri Covaliov — Thu, 12 Mar 2026 18:08:13 +0000

Introduction

In the previous labs, we deployed a self‑hosted GitLab instance behind Cloudflare Zero Trust to protect access to the web interface and repositories. That setup works well for human users, but CI systems introduce a different kind of traffic.

GitLab runners interact with GitLab non‑interactively: they fetch repositories, call APIs, and upload job results automatically. When the public GitLab domain is protected by Cloudflare Access, these interactions can be redirected to authentication flows that CI jobs cannot complete.

This lab explores a practical solution: running CI jobs on a GitLab Runner inside the private network, allowing CI traffic to bypass the Zero Trust authentication layer entirely.

The core idea is simple:

Humans access GitLab through Cloudflare Zero Trust. CI jobs interact with GitLab entirely inside the private network.

Goal

Extend the existing GitLab deployment by introducing a private GitLab Runner VM that executes CI jobs without relying on the public Cloudflare‑protected endpoint.

By the end of this lab:

GitLab remains accessible through Cloudflare Zero Trust
CI jobs run on a runner VM in the same private network
repository checkout uses an internal GitLab endpoint
pipelines run successfully without hitting Cloudflare authentication

Constraints / assumptions

This lab intentionally keeps the environment simple and reproducible.

GitLab is already running behind Cloudflare Zero Trust
GitLab and the runner VM share the same private network
infrastructure is provisioned using Vagrant
the runner uses the Docker executor
the goal is architecture clarity, not production‑grade scaling

The environment is intentionally local. The focus of the lab is network design and CI architecture, not cloud infrastructure configuration.

High‑level design

The architecture introduces two separate access paths to GitLab.

Human access

Developers reach GitLab through the public domain protected by Cloudflare Zero Trust.

Developer → Cloudflare Zero Trust → GitLab public domain

CI execution

GitLab communicates with the runner entirely inside the private network.

GitLab VM → internal NGINX listener → GitLab Runner VM

The runner registers using the internal endpoint and uses the same address for repository checkout through the clone_url setting.

This ensures CI jobs never follow the public access path and therefore never encounter Cloudflare authentication redirects.

Phase 1 --- Make it work

The first phase focuses on simply getting a pipeline to run on the private runner.

Two architectural adjustments are required.

Expose an internal GitLab entrypoint

The previous lab disabled GitLab's bundled NGINX because external traffic was handled by the Cloudflare tunnel and reverse proxy.

However, CI jobs require a stable HTTP endpoint that supports Git operations. Using Puma directly is unreliable for this purpose, and the public domain leads to Cloudflare authentication redirects.

To solve this, the GitLab VM exposes an internal NGINX listener bound to the private IP.

Example:

http://<GITLAB_PRIVATE_IP>{=html}:8081

This endpoint is used for:

runner registration
GitLab API calls
repository checkout

Provision a runner VM

A second VM is created inside the same private network and configured with:

Docker
GitLab Runner
a Docker executor
explicit runner tags

During registration, the runner configuration sets:

url → internal GitLab endpoint
clone_url → internal GitLab endpoint

The clone_url parameter ensures repository checkout uses the internal address instead of the public GitLab domain.

Validate with a smoke pipeline

A minimal CI project confirms that the runner works correctly by verifying:

runner identity
container execution
GitLab reachability
successful repository checkout

Once the pipeline succeeds, the private CI path is confirmed to work correctly.

Phase 2 --- Reduce trust / Harden access

Once the runner works, the next step is reducing permissions that are not actually required.

Disable privileged Docker mode

Privileged containers grant very broad capabilities to CI jobs, including access to host‑level resources.

The smoke pipeline only runs basic commands inside a container, so privileged mode is unnecessary.

Disabling it reduces the attack surface of the runner host.

Restrict job scheduling with tags

The runner is configured with explicit tags and untagged jobs are disabled.

Pipelines must explicitly reference these tags to run on the runner.

This prevents unrelated projects or misconfigured jobs from executing there accidentally.

Lessons learned

Running GitLab behind Cloudflare Zero Trust introduces an important architectural distinction.

Interactive users and automated CI jobs have very different requirements.

Human users can complete authentication flows through Cloudflare Access. CI systems cannot.

Instead of weakening the Zero Trust configuration, a better approach is introducing a dedicated internal access path for CI systems.

This lab demonstrates that pattern clearly:

public access remains protected
CI traffic stays inside the private network
repository checkout uses a stable internal endpoint

Another key lesson is that CI runners should start permissive enough to work, but once pipelines are validated, unnecessary privileges should be removed.

Where to go next

This lab opens the door to several useful extensions.

Possible follow‑up experiments include:

GitLab behind Cloudflare --- Runner VM (multiple runners and scheduling policies)
GitLab behind Cloudflare --- S3 storage VM for caches, artifacts, and pages
GitLab behind Cloudflare --- Automation with Ansible
GitLab behind Cloudflare --- Full CI/CD example\ (build → checks → unit tests → reports → packaging → containerization → deployment)

Each of these steps moves the lab environment closer to a realistic CI/CD platform while keeping the architecture transparent and reproducible.

Repository

The full lab --- including Vagrant configuration, provisioning scripts, diagrams, and the reproducible runbook --- is available in the repository linked below.

👉 https://github.com/ic-devops-lab/devops-labs/tree/main/GitLabSEBehindCloudflare03Runner

Published Labs in This Series

Each lab explores a boundary in infrastructure design and gradually shifts trust from network assumptions toward identity and workload isolation.

GitLab Behind Cloudflare Tunnel --- Removing Inbound SSH Exposure

Iuri Covaliov — Wed, 04 Mar 2026 14:02:20 +0000

Introduction

In the previous lab, GitLab was placed behind Cloudflare Access and
protected by identity. HTTPS traffic passed through Nginx, and access to
the web interface required authentication at the edge.

But one part of the system still relied on a traditional assumption: SSH
was reachable via an open port.

This lab continues the evolution. The goal is not to add another
security layer for its own sake, but to change the exposure model
itself. Instead of accepting inbound SSH connections, the host
establishes an outbound tunnel to Cloudflare. Both HTTPS and SSH access
are then mediated through identity.

The trust boundary moves from ports to people.

Goal

Rework a self-hosted GitLab setup so that:

HTTPS traffic flows through Cloudflare Tunnel.
SSH access is gated by Cloudflare Access.
No direct inbound SSH exposure is required.
The GitLab VM remains disposable and isolated.

This is not about eliminating SSH. It is about changing who gets to
initiate it.

Constraints / Assumptions

The environment remains intentionally simple:

GitLab CE runs inside a VM.
The host runs Nginx.
The domain is managed in Cloudflare.
Cloudflare Access is already configured (from the previous lab).
Firewall rules are left unchanged.
Only free-tier Cloudflare features are used.

The lab focuses on architecture and exposure patterns, not
cloud-provider specifics.

High-Level Design

In the original setup, identity protected HTTP, but SSH still depended
on a reachable port:

User
→ Cloudflare (DNS + Access)
→ Host Nginx (443)
→ GitLab VM

SSH:
User → Host 22 → VM 22

Identity was enforced for the web interface, but the transport layer
still trusted network reachability.

After introducing Cloudflare Tunnel, the model shifts:

User
→ Cloudflare Access
→ Cloudflare Tunnel (outbound from host)
→ Nginx (HTTP)
→ GitLab VM

SSH:
User → Cloudflare Access
→ Cloudflare Tunnel
→ VM (SSH)

The host now initiates and maintains the connection to Cloudflare.
Nothing waits for unsolicited inbound traffic. Access is mediated by
identity first, transport second.

The firewall is no longer the primary boundary. It becomes a fallback.

Phase 1 --- Make It Work

The first objective is straightforward: establish functional
connectivity through the tunnel.

Cloudflared is installed on the host and authenticated. A named tunnel
is created and bound to the domain. DNS records are routed through the
tunnel. Ingress rules are defined so that the main domain forwards to
Nginx locally, and a dedicated SSH subdomain forwards to the VM's SSH
port.

Once the tunnel runs as a systemd service, the web interface loads
through Cloudflare exactly as before. The difference is subtle but
important: the traffic now enters through an outbound tunnel rather than
a directly reachable service.

SSH follows the same pattern. The client uses:

ProxyCommand cloudflared access ssh --hostname ssh-<domain>

Before any SSH handshake reaches the VM, Cloudflare Access enforces
authentication in the browser and issues a short-lived token. Only then
does the SSH session proceed.

From the user's perspective, nothing changes.\
From the architecture's perspective, everything does.

Phase 2 --- Reduce Trust / Harden Access

With the system working, the focus shifts from connectivity to trust
boundaries.

Identity Before Transport

Previously, SSH relied on an open port. Now, it depends on identity
validation at the edge. If authentication fails, transport never begins.

This is a meaningful shift. The system no longer assumes that network
reachability implies legitimacy.

Outbound-Only Connectivity

The host no longer listens passively for SSH. Instead, it maintains an
outbound connection to Cloudflare. Even if inbound port 22 remains open
for the sake of the lab, the architecture no longer depends on it.

The design supports full inbound closure without structural change.

Disposable Infrastructure

Recreating the VM regenerates SSH host keys. Clients detect this change
and require reconciliation via known_hosts. This is not an
inconvenience; it is a reminder that trust in SSH is explicit and
stateful.

Disposable infrastructure surfaces operational truths that static
systems tend to hide.

Lessons Learned

The most important shift in this lab is conceptual.

In the first iteration, identity wrapped around services that were still
network-exposed. In this one, identity becomes the gateway to transport
itself.

When access decisions happen before packets reach the host, the
firewall's role changes. It is no longer the primary defense but a
secondary containment layer.

The tunnel model also simplifies reasoning about exposure. The host
initiates connectivity; it does not advertise it. That inversion removes
an entire class of assumptions about scanning, probing, and open ports.

Finally, rebuilding the VM highlights something often overlooked:
security models must account for operational behavior. SSH host key
changes are not edge cases --- they are part of lifecycle management. A
secure design must remain understandable and manageable under change.

Where to Go Next

A natural extension of this lab is introducing private GitLab Runner
VMs.

These runners would:

Exist only inside the private network.
Register with GitLab over internal addresses.
Execute CI jobs without any public exposure.

This would extend the pattern beyond secure access and into secure
execution. Identity gates entry; isolation protects workload processing.

Repository

The full lab --- including runbook, configuration examples, and tunnel
setup --- is available here:

👉 https://github.com/ic-devops-lab/devops-labs/tree/main/GitLabSEBehindCloudflare02Tunnels

Published Labs in This Series

Each lab explores a boundary in infrastructure design and gradually
shifts trust from network assumptions toward identity and workload
isolation.

Owning Your GitHub Actions CI: Moving to Self-Hosted Runners

Iuri Covaliov — Thu, 26 Feb 2026 09:39:18 +0000

Moving to self-hosted runners isn’t just about saving CI minutes.
It’s about shifting from using infrastructure to operating it.

For a long time, GitHub-hosted runners were simply the default. You push code. A workflow runs somewhere. Artifacts appear. Clean. Abstracted. Convenient.

I had experimented with self-hosted runners before — mostly while learning GitHub Actions. It worked, but I didn’t see a compelling reason to keep it.

Then two things changed.

First, I once had to build a macOS executable for a small utility. The binary produced by the default runner didn’t work on two developers’ laptops. We ended up building it directly on one of their machines. That was the first time I clearly felt that CI environments are not neutral. They are specific systems with specific assumptions.

Second — more recently — GitHub runner minutes stopped being effectively free.

That’s when experimentation turned into architecture.

Not Just Installing a Runner

Installing a runner is easy.

Designing a small, intentional self-hosted CI layout is different.

I structured the lab around:

A Linux server (Ubuntu 24.04 in my case)
Separate runners for:
- Personal repositories
- Organization repositories
A clear directory structure:

/opt/gh-actions-runners/
  personal-runner-1/
  organization-runner-1/

Explicit labels for routing jobs
Docker-based build workflows

The goal wasn’t to recreate GitHub’s infrastructure.

It was to remove invisible layers and understand the system I was relying on.

That difference matters.

Reality Check #1: Organizational Boundaries Are Part of Runtime

At one point everything looked correct:

Runner online
Labels matching
Workflow targeting self-hosted, Linux, X64, ci

And yet the job remained stuck:

Waiting for a runner to pick up this job...

No obvious error. No crash. Just silence.

The issue wasn’t YAML.
It wasn’t the runner service.

It was a runner group setting: public repositories were not allowed to use that runner.

Once enabled, the job started immediately.

It was a small issue — but revealing.

Self-hosted CI expands the surface area of configuration. Policy, permissions, and organizational settings become part of runtime behavior.

When you host it yourself, abstraction doesn’t disappear. It just moves.

Reality Check #2: Docker Isn’t Just Docker

In another project outside the lab, I ran a simple workflow:

docker build
docker push

Nothing complex.

Everything in the runner workspace looked correct.
ls showed the Dockerfile.
Permissions were fine.
The runner service was healthy.

And still, builds failed with:

lstat /var/lib/snapd/void/... no such file or directory

The problem wasn’t the workflow.

Docker had been installed via Snap.
The runner workspace lived under /opt.
Snap confinement prevented Docker from accessing that path.

From the shell, everything looked fine.
From Docker’s perspective, the directory simply did not exist.

The fix was straightforward:

Remove Snap Docker
Install Docker via apt
Restart the runner service

But the lesson wasn’t about Docker.

It was about environmental assumptions.

When you move to self-hosted CI, packaging decisions become architectural decisions.

Reality Check #3: Ephemeral Is a Luxury

GitHub-hosted runners are ephemeral.
They clean themselves after every job.

Self-hosted runners do not.

After a handful of Docker builds, disk usage starts to grow:

Images
Layers
Build cache
Stopped containers

Nothing breaks immediately.
But entropy accumulates quietly.

So the lab gained maintenance scripts:

A recommended cleanup routine
An aggressive recovery option
Optional cron automation

Owning CI means owning lifecycle — not just pipelines.

What Actually Changes

Moving to self-hosted runners isn’t primarily about saving money.

It’s about shifting responsibility.

You gain:

Predictable environments
Full control over toolchain versions
No external minute limits
Transparency in how jobs are executed

You also gain:

Infrastructure maintenance
Disk management
Docker lifecycle awareness
Organizational configuration complexity
Security considerations (your runner executes arbitrary code)

It’s not better or worse.

It’s simply more explicit.

Lab Repository

The full lab setup — including:

Runner installation runbook
Architecture notes
Example workflows
Docker cleanup scripts

is available in the accompanying repository:

👉 https://github.com/ic-devops-lab/devops-labs/tree/main/GitHubSelfHostedRunners

There’s a difference between using CI and operating CI.

Even at small scale, that difference is meaningful.

Replacing Static AWS Credentials in CI/CD with GitHub OIDC (A Practical DevOps Lab)

Iuri Covaliov — Wed, 18 Feb 2026 15:30:49 +0000

Storing long‑lived AWS access keys inside CI/CD pipelines is common. It
works. It is simple. And it usually stays that way for years.

But static credentials expand the trust boundary more than we often
realize. They live in repository settings, they require manual rotation,
and if exposed, they remain valid until explicitly revoked.

In this lab, I built a minimal deployment pipeline from GitHub Actions
to Amazon S3 and then deliberately refactored it. The goal was not to
deploy a website. The goal was to observe how the trust model changes
when static credentials are replaced with short‑lived role assumption.

The structure is simple: the deployment remains the same, the trust boundary changes.

Goal

Demonstrate a practical migration:

Phase 1 --- deploy to S3 using static AWS credentials stored in GitHub Secrets
Phase 2 --- remove static credentials and use GitHub OIDC (OpenID Connect) federation with IAM role assumption
Keep the deployment behavior identical while improving the authentication model

The target (S3 static site) is intentionally minimal so that
authentication and identity flow stay in focus.

Constraints / Assumptions

Single AWS account
Manual setup (no Terraform for clarity)
S3 static website enabled (lab shortcut)
GitHub Actions used as CI/CD engine

Public S3 access is used only to simplify validation. In a production
setup, CloudFront and stricter bucket policies would replace it.

High-Level Design

The central question of this lab:

Can we change how CI/CD authenticates to AWS without changing how it
deploys?

Phase 1 --- Make it work

Architecture:

GitHub Actions → GitHub Secrets → IAM User → S3

An IAM user is created.
Access keys are generated.
Keys are stored as repository secrets.
The workflow uploads files using aws s3 sync.

The system works exactly as expected.

However:

Credentials are long‑lived.
Rotation is manual.
Any secret leakage provides direct AWS access.

Nothing is broken --- but trust is broad.

Phase 2 --- Reduce Trust / Harden Access

In the second phase, the IAM user is removed from the deployment path.

Architecture becomes:

GitHub Actions → OIDC Token → IAM OIDC Provider → Security Token Service (STS) → IAM Role → S3

Three architectural changes occur.

1. Introduce an IAM OIDC Provider

AWS is configured to trust tokens issued by:

https://token.actions.githubusercontent.com

This creates a formal trust anchor between GitHub and AWS.

2. Define a Scoped Trust Policy

The IAM role trust policy restricts access to:

repo:<OWNER>/<REPO>:ref:refs/heads/main

This means:

Only this repository
Only this branch
Only through OIDC
Only via STS

Trust becomes explicit and narrow.

3. Replace Static Credentials with Role Assumption

The GitHub workflow:

Requests an ID token
Calls AssumeRoleWithWebIdentity
Receives short‑lived credentials
Deploys using the same aws s3 sync command

The deployment logic remains unchanged.

But no static AWS keys exist in GitHub anymore.

What Actually Changed

Operationally, nothing changed:

Same repository
Same workflow structure
Same deployment command
Same S3 bucket

From a trust perspective, everything changed:

Credentials are now short‑lived
No manual rotation is required
Access is scoped to one repository and branch
AWS access depends on a validated identity token

The system now grants access based on verified identity rather than
stored secrets.

Observations from Implementation

A few practical lessons emerged during the lab:

Incorrect S3 ARNs in role policies immediately cause AccessDenied errors.
Missing id-token: write permission prevents OIDC role assumption.
Trust policy sub mismatches block access cleanly and predictably.
aws sts get-caller-identity is the most useful debugging command in this flow.

Federated identity setups are less forgiving than static keys --- but
that strictness is the point.

Lessons Learned

Replacing static credentials does not require changing deployment logic.
Trust policy design is the most sensitive part of the setup.
Short‑lived credentials reduce operational overhead and risk.
CI/CD hardening is primarily about narrowing trust boundaries.
Security improvements can be incremental and observable.

The lab reinforces a simple pattern: Make it work. Then deliberately reduce trust.

Where to Go Next

This setup can be extended in several directions:

Build and push Docker images to ECR using the same OIDC role\
Deploy to ECS instead of S3\
Provision IAM and OIDC provider via Terraform\
Add GitHub Environments and environment‑scoped trust conditions\
Remove public S3 access and introduce CloudFront

Each extension builds on the same identity model.

Repository

Full reproducible runbook and workflows:

👉 https://github.com/ic-devops-lab/devops-labs/tree/main/GitHubActionswithAWSOIDC

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.

Securing a Remote Linux Host with firewalld and OpenVPN

Iuri Covaliov — Fri, 13 Feb 2026 21:42:48 +0000

For my experiments I'm renting a remote Linux server. As soon as it was
online, it became clear that the first real problem wasn't installing
software, but reducing how much of the server was exposed to the
internet by default. Services like SSH are continuously scanned and
probed, and a freshly provisioned host is immediately visible.

This lab documents how I secured that host step by step: first by
establishing a strict firewall baseline, then by introducing a private
administrative VPN, and finally by removing public SSH exposure
entirely.

Goal

The goal of this lab is to secure a rented Linux host that acts as the
entry point to a private network.

In this setup, the public host fronts several internal virtual machines.
External HTTP(S) traffic is terminated on the host and routed to
internal services via a reverse proxy, while internal systems are not
directly exposed to the internet.

Although built as a homelab, this mirrors real-world infrastructure
patterns where a single edge node provides controlled access to private
services.

This lab focuses on:

Reducing the exposed attack surface
Replacing unrestricted public SSH with controlled access
Establishing a reusable hardening pattern for future hosts

Constraints / Assumptions

The host is publicly reachable.
SSH is initially exposed.
Out-of-band recovery access is available from the provider.
A non-root admin user with sudo is used.
Temporary SSH disruption is acceptable during hardening.

High-Level Design

The host serves two roles:

Public entry point (reverse proxy, VPN)
Gateway to a private internal network

Traffic model:

Internet → Public host (only required ports open)
Public host → Private VMs
Administrative access via VPN only (Phase 2)

The final state minimizes public exposure and separates management
traffic from application traffic.

Phase 1 --- Make it work

The objective is to regain control.

Using firewalld with a deny-by-default policy, inbound traffic is
restricted to explicitly allowed services. SSH remains publicly
accessible temporarily to avoid lockout during baseline setup.

Phase 1 ensures:

Explicitly defined inbound access
Persistent firewall rules
Stable administrative connectivity

ICMP remains enabled for diagnostics.

Phase 2 --- Reduce trust / Harden access

With a stable firewall in place, administrative access is redesigned.

Introduce a Private Administrative Network

OpenVPN is deployed to create a private management plane. SSH is no
longer treated as a public service but as a capability granted to
authenticated VPN members.

Split-tunnel mode is intentionally used. Administrative traffic routes
through the VPN, while general internet traffic remains local.

Restrict SSH to VPN + Controlled IP

Once VPN access is validated:

Public SSH is removed.
SSH is allowed only from:
- The VPN subnet
- A specific home IP address (fallback)

This eliminates global SSH exposure.

Disable Root SSH Login

Root login is disabled. Administrative access occurs through a dedicated
non-root user with sudo.

Automating Client Profile Generation

Instead of manually assembling the .ovpn file, the repository includes
a helper script:

make-ovpn.sh

The script:

Reads the server configuration
Embeds the correct CA and tls-crypt key
Extracts the correct certificate block
Generates a ready-to-import profile

Example:

./make-ovpn.sh client1

This prevents formatting mistakes and ensures server/client consistency.

Final Validation Checklist

SSH not publicly reachable
SSH reachable via VPN
Root login disabled
VPN stable after reboot
Firewall rules persist

Lessons Learned

Firewall first, VPN second.
Separate access plane from data plane.
tls-crypt keys must match exactly.
Split-tunnel DNS requires careful handling.
Root access should be deliberate.

Where to Go Next

Replace OpenVPN with WireGuard
Mirror firewall rules at provider level
Convert the host into a bastion/jump host pattern
Automate via Ansible

Repository

The full and step‑by‑step documentation — is available here:

👉 https://github.com/ic-devops-lab/devops-labs/tree/main/ProtectRemoteHostWithFirewallAndVPN

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.

Published Labs in This Series

GitLab Behind Cloudflare Zero Trust

Self-hosting GitLab Behind Cloudflare Zero Trust (A Practical DevOps Lab)

Iuri Covaliov — Fri, 06 Feb 2026 16:31:33 +0000

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/ic-devops-lab/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.

Published Labs in This Series

Each lab explores a boundary in infrastructure design and gradually
shifts trust from network assumptions toward identity and workload
isolation.

DEV Community: Iuri Covaliov

GitLab CI Caching Didn’t Speed Up My Pipeline — Here’s Why

What I Wanted to Test

The Setup

Baseline: No Cache

Results

Adding Cache

The Result

Why Didn’t It Get Faster?

1. Fast package source

2. pip is efficient

3. Cache has overhead

4. CI jobs spend time elsewhere

The Real Takeaway

When Caching Helps

When It Might Not Help

Not Just About Speed

What’s Next

Repo

Final Thought

Related Articles

GitLab SE behind Cloudflare Zero Trust: Private CI Runner

Introduction

Goal

Constraints / assumptions

High‑level design

Human access

CI execution

Phase 1 --- Make it work

Expose an internal GitLab entrypoint

Provision a runner VM

Validate with a smoke pipeline

Phase 2 --- Reduce trust / Harden access

Disable privileged Docker mode

Restrict job scheduling with tags

Lessons learned

Where to go next

Repository

Published Labs in This Series

GitLab Behind Cloudflare Tunnel --- Removing Inbound SSH Exposure

Introduction

Goal

Constraints / Assumptions

High-Level Design

Phase 1 --- Make It Work

Phase 2 --- Reduce Trust / Harden Access

Identity Before Transport

Outbound-Only Connectivity

Disposable Infrastructure

Lessons Learned

Where to Go Next

Repository

Published Labs in This Series

Owning Your GitHub Actions CI: Moving to Self-Hosted Runners

Not Just Installing a Runner

Reality Check #1: Organizational Boundaries Are Part of Runtime

Reality Check #2: Docker Isn’t Just Docker

Reality Check #3: Ephemeral Is a Luxury

What Actually Changes

Lab Repository

Replacing Static AWS Credentials in CI/CD with GitHub OIDC (A Practical DevOps Lab)

Goal

Constraints / Assumptions

High-Level Design

Phase 1 --- Make it work

Phase 2 --- Reduce Trust / Harden Access

1. Introduce an IAM OIDC Provider

2. Define a Scoped Trust Policy

3. Replace Static Credentials with Role Assumption

What Actually Changed

Observations from Implementation

Lessons Learned

Where to Go Next

Repository

Securing a Remote Linux Host with firewalld and OpenVPN

Goal

Constraints / Assumptions

High-Level Design

Phase 1 --- Make it work

Phase 2 --- Reduce trust / Harden access