I build production-style cloud infrastructure (provisioning, deployment, security, and observability) as complete, independently designed systems rather than isolated exercises.

Cloud Infrastructure → Infrastructure as Code → Containers → Kubernetes → CI/CD → Observability → DevSecOps

Every project here answers one question: not "can I use this tool," but "what does it take to run this safely, repeatably, and without me in the room."

• Automation is a trust exercise. If a deployment only works when I'm watching it, it isn't finished.
• Security is a design constraint, not a checklist item added at the end.
• Infrastructure should be disposable. If I can't destroy and rebuild an environment from code alone, it isn't really "as code" yet.
• Observability comes before scale. I'd rather know a system is struggling than assume it isn't.

flowchart LR
    A[Linux & Networking] --> B[Git & GitHub]
    B --> C[Docker]
    C --> D[CI/CD]
    D --> E[AWS]
    E --> F[Terraform]
    F --> G[Kubernetes & Helm]
    G --> H[Observability]
    H --> I[DevSecOps]
    I --> J[Platform Engineering]

Operating loop: Learn → Build → Break → Troubleshoot → Automate → Document → Improve

Currently pursuing: AWS Certified Solutions Architect Associate and CKA.

I approach infrastructure with a security-by-design philosophy: security is engineered in from the start, not layered on afterward.

flowchart LR
    A[Identity] --> B[Least Privilege]
    B --> C[Secure Configuration]
    C --> D[Secret Management]
    D --> E[Image/Code Scanning]
    E --> F[Secure CI/CD]
    F --> G[Monitoring]
    G --> H[Auditability]

Build systems that are difficult to misuse, easy to observe, and repeatable to operate.

Tooling is the easy part. What I actually optimize for:

• Cost is a design input, not an afterthought. Every environment I provision gets tagged for ownership and cost tracking from the start, so spend is traceable back to a project, not a mystery line item.
• Guardrails over reviews. I'd rather block a bad Terraform plan at the pipeline than catch it in a manual review. Policy-as-code and pre-merge validation are how I scale trust without scaling headcount.
• Every system needs a failure story. Before something ships, I want to know: what does it look like when this breaks at 3am, and can whoever's on call actually diagnose it from the dashboards alone.
• Documentation is part of the deliverable. A runbook that only I understand isn't done. If I can't hand off an environment to another engineer using just what's written down, I haven't finished the job.

Moving from isolated tool demonstrations toward larger, integrated, production-minded systems that combine AWS, Terraform, Docker, Kubernetes, CI/CD, security, and observability into a single operating model.

The trajectory: "I know this tool" → "I can design and operate a system using this tool."

I want to work somewhere the infrastructure I build actually gets used under real load, where a bad deploy has consequences, so a good deploy has to be boring by design. My next step is trading solo projects for a team, real production stakes, and systems other people depend on.

If you're building something worth being obsessive about the infrastructure for, I'd like to hear about it.

📍 Nigeria. Open to global, remote and relocation opportunities

Cloud Engineering → DevOps → DevSecOps → Platform Engineering → SRE → Cloud Architecture