Welcome back. In one of my recent videos, I talked about building a CI/CD pipeline from the ground up. That idea hasn’t changed. What has become clear, though, is that before I start building anything, there’s something more important to talk about first.
One of the biggest issues I see in a lot of DevOps content is how scattered everything feels. Tools get introduced randomly. Decisions are made without context. And most of the time, you never really get a clear picture of how all the pieces fit together. The result is that people end up copying steps without understanding why they’re doing them. I don’t want this series to be that.
So instead of jumping straight into pipelines, this part of the journey is about stepping back and looking at the big picture. What core systems need to exist first? What role does each one play? And how do they come together to support the CI side of the pipeline?
This isn’t the build phase yet. This is the groundwork. Some of the tools I talk about here may change as the build evolves. I might replace things. I might remove things.
I might add entirely new tools as I learn more. That’s part of the process. But what matters is having a clear starting point, a foundation that makes everything else cleaner, more predictable, and easier to automate later. Think of this as the architectural blueprint before any concrete gets poured.
Scope Comes First (And It Matters)
Before diving into any tools, there’s one thing I want to be very clear about: Scope. This build is happening in phases, and I’m intentionally staying in scope for each phase. Everything here, and in the next few videos is focused on laying the groundwork for Continuous Integration, not Continuous Deployment.
That distinction matters. Some of the systems I set up now will absolutely carry over into the CD phase later. But right now, my focus is CI. I want a solid CI foundation first. Once that’s stable and working, then I’ll move on to building out the CD side. That separation keeps things intentional instead of chaotic.
Compute / Execution Platform (Where Everything Runs)
This is the “cloud layer,” except it’s local. This is where all compute lives. VMs, containers, and the services that make the pipeline work.
Tool: Proxmox
This is the execution platform. It’s the place where the infrastructure lives and runs. What I want from this layer is simple: I need a stable platform that can host everything, and I need it to be easy to automate later.
Proxmox becomes the source of truth for “what exists” in the environment. What VMs exist, what containers exist, what resources they have, and how they’re structured. I’m keeping this first build local because cloud can get expensive fast, and I want to understand the full stack before I start adding cloud complexity on top.
Storage + Backup (My “I Can Recover” Layer)
Before I build anything serious, I want recovery in place. Because building from scratch means breaking things. That’s the reality.Tool: TrueNAS SCALE (Storage + Central Data Layer)
TrueNAS gives me the ability to manage storage properly and build redundancy into the setup. But more importantly for this series, it becomes the central place where “important stuff” lives. Data, backups, configs, and anything I don’t want to lose when I’m experimenting. This layer is here so that when I mess something up, and I will. I’m not starting from scratch. I’m rolling back. It’s peace of mind from day one.
Version Control (Source of Truth for Code + Config)
Next comes the local Git repository, and this is a big one. This repository isn’t just for application code. It’s the source of truth for:
- Code
- Configuration
- Documentation
- Automation workflows
Anything that can be versioned should be versioned.
Tools I’m considering: GitLab (self-hosted) or Gitea
I’m still deciding between GitLab and Gitea.
- GitLab is widely used and I already work with it in school, so it makes sense for learning and real-world relevance.
- Gitea is lighter, simpler, and still gives me everything I need for a local Git source of truth.
Either way, the role is the same: this repo becomes the source of truth for code, configs, documentation, and later on, automation workflows.
The big idea is that I want everything versioned. Not just app code. Config files too. Notes too. If I change something, I want a history of it. If I mess it up, I want to roll it back.
Documentation (My Memory Outside My Head)
I document everything, because I don’t trust my memory like that. lol Documentation is the source of truth for what I’ve learned, why I made certain decisions, and what went wrong along the way. Reading official docs is important, but your own documentation hits different. It reflects your mistakes, your thought process, and your evolution.
Tool: Obsidian (primary)
I’ve used Obsidian for years. It’s my go-to because it’s fast, flexible, and it works the way my brain works. I also like BookStack, but I keep coming back to Obsidian.
And I’m planning to integrate documentation with the repo so it’s versioned too. That way my notes evolve with the build, and I always have a timeline of decisions. Documentation is the difference between “I built something once” and “I can rebuild it whenever I want.”
Networking: Making Automation Possible
This layer is what makes automation possible. If naming, routing, and service access are messy, everything above it becomes pain. Once systems start talking to each other, networking becomes critical.
I’m looking at networking through three core lenses:
- DNS
- DHCP
- Reverse proxy / access layer
Tools I’m considering for DNDS: CoreDNS vs BIND9. I’ve used BIND9 before, and it works. But I’m leaning toward CoreDNS because it feels more automation-friendly and modern for the kind of environment I’m trying to build. DNS becomes the source of truth for hostnames and service names. If services can’t be reached consistently, CI automation becomes miserable.
Tool: Firewall DHCP (keeping it simple) For DHCP I’m not trying to get fancy. I’ll likely stick with DHCP on the firewall because it’s already doing the job and I don’t want to over complicate something that doesn’t need extra moving parts.
Tools I’m considering for reverse proxy: Traefik vs Nginx vs Caddy. I’ve used Nginx before. Caddy is clean. Traefik is popular in container-heavy setups. I haven’t locked this in yet, but the requirement is the same: whatever I choose must work well with automation, because this build is automation-first. This layer becomes the source of truth for how services are accessed internally and through a UI.
Infrastructure as Code + Configuration Management
This is where “no click ops” becomes real. From the very beginning, I want to avoid manual setup as much as possible.
Infrastructure as Code becomes the source of truth for how systems are built, configured, and destroyed. I want to stand up infrastructure with code, not clicks. If something exists, it should be reproducible.
Tools: Terraform or OpenTofu (IaC)
I’m leaning toward starting with Terraform because it’s widely used and I want that exposure. Later I may transition to OpenTofu so I understand the ecosystem shift firsthand.
Tool: Ansible (configuration)
Terraform/OpenTofu will define infrastructure, but Ansible is where configuration becomes repeatable. This is how I stop manually setting up servers every time.
The goal here is: I can stand up infrastructure, configure it, and tear it down using code. Not clicks. Not memory. Not “I think I did it like this last time.” Code becomes the source of truth for how infrastructure is built.
Security (Infrastructure-Level Security, Not App Security Yet)
Security isn’t something I want to sprinkle on later. Secrets, certificates, users, and service access should not be scattered across systems. Each security-related tool should be authoritative for its domain. At this stage, I’m focused on infrastructure-level security, not application scanning or deployment security. That comes later with CD.
The idea is simple: when infrastructure gets created, security practices should already be part of that process. Not an afterthought.
Security evolves, and this setup will evolve too. What matters is starting with a clear structure and improving it over time.
Right now this is infrastructure security: secrets, certs, identity, monitoring. Tools I plan to use:
- HashiCorp Vault (secrets + internal PKI)
- Wazuh (security monitoring / visibility)
- Authentik (identity / user management)
The goal is simple: security can’t be scattered. I want each tool to be authoritative for its job. I want visibility and control from the foundation up. And ideally, I want security baked into provisioning, not bolted on afterward.
Monitoring + Dashboards (So I Know What’s Breaking)
Finally, I need visibility. I want to know when systems are down, misbehaving, or need attention. I want dashboards that give me a high-level view of the environment without hunting through logs all day. I’m still deciding on the exact monitoring stack, but the goal is straightforward: a reliable source of truth for system health and alerts.
I’m leaning toward tools that are widely used in real-world environments, because learning what’s common in practice matters just as much as learning what’s interesting on paper.
Finally, I need visibility. I want to know when systems are down, misbehaving, or need attention. I want dashboards that give me a high-level view of the environment without hunting through logs all day.
Tools I’m considering:
- Prometheus (metrics)
- Grafana (dashboards)
- Uptime Kuma (uptime checks / alerting)
- Dashy (single dashboard / launcher, maybe)
I haven’t finalized this layer yet, but the goal is consistent: one place to see health, alerts, and system status without guessing.
The Whole Point of This Foundation
So that’s the foundation. This is the set of core systems I want in place before I build the CI pipeline itself. Some tools might change as I go. That’s expected. This whole series is learning/building in public, and I’m not pretending I know everything upfront.
But the non-negotiable requirement stays the same:
Everything I choose needs to support automation. If a tool fights automation, it’s gone. I’ll replace it. And I’ll show that process too. I’m not skipping the messy parts. In the next post/video, we start building for real, and I’m starting with DNS, because once DNS is solid, everything else gets easier to automate and easier to scale. Stay curious. Stay building. I’ll see you in the next one. Peace.
