Lead DevOps Engineer
About
Most of my work happens where software meets the machine: Linux hosts, cloud accounts, container runtimes and the pipelines that move changes between them.
I build and operate platforms — the provisioning, the cluster, the delivery path, the dashboards someone opens at 03:00 when something is off. The goal is never tooling for its own sake: it is infrastructure that other engineers can reason about without needing me in the room.
Day to day that means writing Terraform instead of clicking consoles, designing CI/CD that gives fast and honest feedback, hardening Kubernetes, and automating the operational work that would otherwise be done by hand at the wrong moment. I program in Python and Go, mostly to delete repetition.
I work across Linux, cloud infrastructure, containers, Kubernetes, automation and programming. I care about the unglamorous parts: idempotency, least privilege, cost visibility, and knowing exactly what happens when a node disappears.
Engineering philosophy
Reduce manual work and make systems reproducible. If a task needs to be done twice, it belongs in code.
Design infrastructure that is observable, scalable and resilient — and assume the failure will happen during the worst possible change window.
Prefer understandable systems over unnecessary complexity. Boring infrastructure that everyone can read beats clever infrastructure only one person understands.
Currently
Leading cloud infrastructure and DevOps practice at Niuro
Kubernetes platforms, Infrastructure as Code and delivery pipelines
Observability, security hardening and cost awareness
Local AI infrastructure and production-oriented MLOps
Experience
Ten years ago I was fixing workstations. Today I lead the infrastructure other engineers ship on. The through-line is the same: understand the system, then remove the parts that hurt.
2025 — Present
CurrentLead DevOps Engineer
Leading the design, implementation and operation of scalable cloud infrastructure and DevOps practice — Kubernetes platforms, Infrastructure as Code, delivery pipelines, observability, security and engineering enablement.
Focus areas
2024 — 2026
DevOps Engineer
Linux infrastructure and production operations, including streaming infrastructure — packaging, networking and monitoring of live media pipelines running on Linux hosts.
Focus areas
2024
DevOps Engineer
DevOps engineering in a regulated environment: containerized workloads, cluster operations and infrastructure automation for internal platforms.
Focus areas
2022 — 2024
DevOps Engineer
AWS and Linux administration, cloud infrastructure build-out with Infrastructure as Code, and automation of routine operational work.
Focus areas
2019
IT Support
IT support and systems administration — the starting point where I learned how machines actually fail in the hands of the people using them.
Focus areas
Guatemala · remote-friendly · Open to interesting engineering problems
Skills
Where each technology sits in the systems I build. Grouped by engineering domain, not by logo count.
AWS
The cloud I reach for most: compute, networking, managed data services and IAM treated as code rather than as a console session.
Azure
Cloud infrastructure for teams already standardized on the Microsoft ecosystem, wired into the same pipeline and IaC conventions.
GCP
Workloads where GKE and the data tooling justify the platform — provisioned declaratively like everything else.
Kubernetes
Cluster design and day-two operations: workloads, networking, storage, upgrades, RBAC and the guardrails that keep a shared cluster safe.
Docker
Container images as a build artifact: minimal bases, reproducible builds, non-root by default, small enough to pull quickly.
Linux
The foundation everything else sits on — systemd, networking, storage, processes, permissions, and reading logs properly under pressure.
Terraform
My default for provisioning: reviewed plans, small modules with real interfaces, remote state and a clear story for drift.
CloudFormation
Where a stack belongs inside AWS: native change sets, stack policies and no extra state to manage.
Python
The language I automate with: operators, API clients, data pipelines, tooling, and the glue around AI/ML workloads.
Go
For the things that should be one static binary: CLI tools, small services and controllers that do not need a runtime.
C++
Foundational systems programming knowledge that makes performance and memory behaviour legible instead of magical.
GitHub Actions
Delivery pipelines as code: reusable workflows, caching, least-privilege tokens and OIDC instead of long-lived cloud keys.
CI/CD
Designed so a broken change fails fast and honestly, and a good one reaches production without a human babysitting it.
Automation
The whole point. Anything done by hand twice becomes a script, then a pipeline, then something nobody has to think about.
Monitoring
Metrics that answer a question, with alerts tied to user-visible symptoms instead of to every CPU spike.
Logging
Structured logs, retained on purpose, cheap enough to keep and searchable during the ten minutes that matter.
Reliability Engineering
SLO thinking, blast-radius reduction, capacity headroom and post-incident work that actually changes the system.
SQL
Relational modelling, indexing and the query plans behind a slow endpoint — plus backups and restores that have been tested.
NoSQL
Document and key-value stores where access patterns matter more than normalization, operated as managed infrastructure.
Mental model
These are not skills, they are constraints I design against. Each one changes the others — that tension is what makes infrastructure work.
What it changes
If it is not in the repository it does not exist. That single rule makes everything else auditable, reviewable and rebuildable after a bad day.
Pulls on
What it changes
Automation removes the human from the path where humans are least reliable: repeated steps under time pressure.
Pulls on
What it changes
You cannot operate what you cannot see. Instrumentation is part of the build, not a follow-up ticket.
Pulls on
What it changes
Least privilege, short-lived credentials and a small attack surface. Defaults matter more than intentions.
Pulls on
What it changes
Designed for the failure, not for the demo: bounded blast radius, tested restores and capacity headroom for the worst day.
Pulls on
What it changes
Every architectural decision has a monthly price. Visibility turns cost from a surprise into a design input.
Pulls on
What it changes
Platforms are products. Fast, honest feedback and self-service paths are what make good practices actually get adopted.
Pulls on
Open source
Pull live from the GitHub API at build time — no invented contribution numbers. Pinned repositories are real, unmodified projects.
86
contributions in the last year
44
public repositories
14
followers
20
following
2021
on GitHub since
Live data
86 · contributions in the last year
Public contribution calendar for the last year.
Sorted by last push. Descriptions as written by their author.
HashiCorp Vault for secrets and tokens, deployed on AWS with Terraform. Configurable security and scalability, usable from any service.
Docker builds for FFmpeg targeting Ubuntu, Alpine, CentOS, Scratch, NVIDIA and VAAPI images.
Running MongoDB on Kubernetes.
Container build and delivery practice in Docker.
Google Cloud infrastructure described with Terraform.
Personal technical blog, built with Hugo.
Writing about Linux, Kubernetes and automation.
Contact
I'm interested in building reliable platforms, automating complex systems and solving difficult infrastructure problems.
Built with Next.js, deployed like infrastructure.