Ray Evelyn | AI Infrastructure, Platform & SRE

My journey into engineering started with curiosity about how systems connect. Self-taught networking and my work at Air Networks, a fiber and wireless ISP, gave that curiosity a practical direction: packets still need a route, services still need names, and someone needs a way back in when a change goes wrong.

That foundation followed me into observability and automation at Magic Leap, SRE work at Chewy, and platform and cloud engineering. The tools changed, but the questions stayed familiar. Can I explain how this works? Can someone else operate it? What happens when a dependency fails?

I began studying at Full Sail in March 2023 and completed my B.S. in Computer Science in November 2025. My thank-you to Full Sail reflects on what that meant to me. VoiceRAG brought several parts of my journey together: SIP and PBX systems, speech-to-text, text-to-speech, inference, context, and Kubernetes. It helped connect the networking work I already understood with the software and AI infrastructure I want to keep building.

I am pursuing AI infrastructure, platform, SRE, and forward deployed engineering roles. For me, that direction includes the unglamorous foundations: DNS, identity, delivery, storage, telemetry, and recovery. An inference service needs those foundations just as much as any other service.

Why I am sharing the code

I want to give people an approachable way to work through those foundations. A diagram can explain a design, but a small repository lets you inspect the configuration, change an input, and see where responsibility moves from one layer to the next.

This series publishes learning examples, not a claim that every lab is running as a production service. Each repository has its own prerequisites, boundaries, and validation notes. Some deliberately use one replica or a single control plane so the design stays understandable. Those tradeoffs should be visible before anyone tries to build on them.

My preference is to bootstrap a local GitLab independently, then use it to hold and deliver the rest of the lab. That is my journey, not a prerequisite for yours. You can choose GitHub with GitHub Actions and your own runner, or GitLab with GitLab CI and your own runner. Keep source and execution on the path you choose. A runner executing infrastructure changes needs network access to Proxmox and the target machines; a hosted syntax-check job is not that runner.

Start with the hardware you have

I know not everyone has a rack of spare machines or the budget to build one. The entry point should be a useful question and the hardware you already have, rather than an obligation to run the entire stack. You can clone a repository, read its scripts, and work through one component before adding another. CPU, RAM, storage, and network capacity still need to match that choice; a GPU is optional for this infrastructure series, not an admission requirement.

The guide is the practical entry point for selecting a path, checking inputs and network access, and understanding capacity. Start small, keep your administrative access working, and leave room for the host and the tools you need to recover it. Validation of example code is not evidence that your particular hardware or Proxmox environment has passed those checks.

Start with the dependencies

The first step is a working administrative path, networking, time, and bootstrap DNS. Then establish your chosen source and delivery platform. Only after that should the rest of the lab depend on it. Otherwise, you can end up needing a broken GitLab service to run the pipeline that repairs GitLab.

The GitOps start guide connects the sequence and explains the platform choices. GitOps means more than checking YAML into Git: desired state is declarative, versioned, pulled, and continuously reconciled. CI can validate and deploy a change, but a pipeline that runs once does not continuously correct drift. A Kubernetes agent is not automatically a GitOps controller either. The OpenGitOps principles provide the distinction I want this series to preserve.

What you can explore

The series covers GitLab delivery, Vault, kubeadm, Rancher, Cloudflare and a DMZ, and bare metal. It continues with authoritative DNS, recursive DNS, Flyway and delivery boundaries, and LGTM observability.

The public code lives in ten repositories:

You do not need to install everything at once. Pick one question, read the corresponding code, and understand its recovery path before adding another dependency. That is the kind of learning resource I would have appreciated earlier in my own journey, and the kind I want to give back now.