Available for DevOps & platform roles
DevOps Engineer
I build the pipelines and infrastructure that put code in production safely.
whoami --verbose
01/About
I work on production cloud infrastructure for real client projects — CI/CD pipelines, container orchestration, secrets management, and the security scanning that stops bad builds from shipping.
Most of my day-to-day is AWS, Terraform and GitHub Actions: provisioning infrastructure as code, replacing static credentials with OIDC-based authentication, getting services onto ECS Fargate behind an ALB, and wiring Snyk and Trivy into pipelines so vulnerable images never reach a registry.
Outside client work I run a full Kubernetes stack — ArgoCD for GitOps, Vault and External Secrets Operator for secrets, kube-prometheus-stack with Loki for observability — because the fastest way to understand a tool is to operate it when nobody is on call but you.
I moved into DevOps from full-stack development, which turned out to be an advantage: I had already felt what a broken deploy does to a team from the application side before I was the one responsible for fixing it.
What I care about is the boring kind of reliability — credentials that expire on their own, pipelines that fail loudly before production does, and infrastructure that someone else can read six months later without calling me.
02/Skills
Grouped by what they do. The note under each is where it was used — if there is no note, treat it as working familiarity rather than production depth.
AWS
AWS EC2
Deployments, Auto Scaling Groups
AWS ECS Fargate
Production cluster, task definitions
AWS ECR
Image registry in CI
AWS S3 & CloudFront
Static hosting, CDN
AWS ALB
Path-based routing across services
AWS IAM
Task execution roles, OIDC trust policies
AWS Client VPN
Private network access to internal resources
VPC & Networking
Public/private subnets, NAT, route tables
Linux
CentOS, Ubuntu — server administration
Hetzner
Hetzner Cloud
Provisioning and managing cloud servers
Hetzner Object Storage
S3-compatible buckets
k3s on Hetzner
Self-managed Kubernetes on Hetzner servers
RunPod
RunPod
GPU infrastructure for model deployment
Terraform
Production infrastructure provisioning
Ansible
Playbooks, roles, multi-server inventories
Helm
Chart-based Kubernetes releases
Bash
Automation, backup and monitoring scripts
YAML / JSON
Manifests, task definitions, workflows
Supabase
Postgres, auth, storage
Row Level Security (RLS)
Postgres policy-based access control
PostgreSQL
Schema design and queries
AWS RDS
Automated backups, SG troubleshooting
MongoDB
Document modelling for Node applications
Docker
Image builds, multi-stage, registries
Docker Compose
Multi-service local environments
Kubernetes
k3s and Minikube clusters
ArgoCD
GitOps continuous delivery
k3s
Lightweight cluster on a Hetzner cloud server
GitHub Actions
OIDC auth, matrix builds, deploy workflows
Jenkins
Pipelines integrating GitHub and Docker
GitOps
Declarative delivery via ArgoCD
Git
Branching strategies, PR-based workflows
HashiCorp Vault
Kubernetes auth method
External Secrets Operator
Syncing secrets into clusters
AWS Secrets Manager
Injected into ECS task definitions
OIDC Authentication
Removed static AWS keys from CI
Snyk
Dependency and SAST scanning as a pipeline gate
Trivy
Container image vulnerability scanning
AWS WAF
Edge filtering in front of CloudFront
Prometheus
kube-prometheus-stack
Grafana
Dashboards and alerting
Loki & Promtail
Cluster-wide log aggregation
CloudWatch
AWS-native metrics and logs
JavaScript / TypeScript
Node.js & Express
REST API design
React
Including this site
Nginx
Reverse proxy, TLS termination
03/Experience
Mar 2026 – Present
Production infrastructure for client projects — cloud, CI/CD, security scanning and secrets management.
Dec 2025 – Feb 2026
CI/CD automation, containerization and AWS infrastructure for live projects.
2024 – 2025
Built and operated real infrastructure independently to develop depth across cloud, Kubernetes and automation.
2023 – 2024
Full-stack web applications with payments, authentication and cloud deployment.
04/Projects
Client work sits alongside self-directed builds. Where a repository is private, it says so rather than linking somewhere unhelpful.
Removed static AWS credentials from CI by moving to OIDC-based authentication. Pipelines now assume a short-lived role to build images, push to ECR and deploy to EC2, with Snyk and Trivy scanning as blocking gates before anything ships.
Client production setup on ECS Fargate: cluster creation, IAM task execution roles, task definitions pulling configuration from AWS Secrets Manager, and an Application Load Balancer doing path-based routing across two services.
A full GitOps cluster on k3s running on a Hetzner cloud server: ArgoCD for continuous delivery, HashiCorp Vault with the Kubernetes auth method, External Secrets Operator, Helm-managed releases, and kube-prometheus-stack with Loki and Promtail for metrics and logs.
A complete VPC built to standard practice: public and private subnets across availability zones, route tables, security groups, a NAT gateway for private egress, and an ALB fronting Auto Scaling Groups.
Automated provisioning and configuration across multiple servers using playbooks, roles, variables and conditionals, including EC2 automation via Ansible collections and passwordless SSH bootstrapping.
Full-stack rental marketplace with advanced search, Stripe payments, real-time availability and an admin panel for landlords to manage listings and reservations. Final year project, graded with distinction.
05/Certifications
Amazon Web Services
Amazon Web Services
Course — CentOS & Ubuntu administration, shell scripting, user and permission management
School of DevOps (Udemy) — playbooks, roles, loops, server automation
Course — MongoDB, Express, React, Node.js
06/FAQ
Direct answers to what recruiters and engineers ask most often.
EC2, ECS Fargate, ECR, RDS, S3, CloudFront, Application Load Balancer, IAM, Secrets Manager, VPC, Client VPN and WAF. The ECS Fargate work was a client production environment — cluster setup, task execution roles, task definitions reading from Secrets Manager, and an ALB routing by path across two services.
By not storing them where possible. In GitHub Actions he uses OIDC to assume a short-lived AWS role instead of holding static access keys in repository secrets. For application configuration, secrets come from AWS Secrets Manager at task startup, and in Kubernetes from HashiCorp Vault via the Kubernetes auth method, synced by External Secrets Operator.
He runs a full GitOps stack on k3s on a Hetzner cloud server, and has also worked with ArgoCD, Vault and External Secrets Operator in a client context. The stack includes Helm-managed releases and kube-prometheus-stack with Loki and Promtail for metrics and logs. This is operational experience on clusters he maintains himself rather than a managed-service-only background.
Terraform for provisioning infrastructure in production, Ansible for server provisioning and configuration management across multiple hosts, and Helm for Kubernetes releases. Pipeline and cluster configuration is version-controlled the same way application code is.
Yes. Alongside AWS he has worked with Hetzner Cloud — provisioning servers, running a self-managed k3s Kubernetes cluster on them, and using Hetzner S3-compatible object storage — and with RunPod for GPU infrastructure to deploy models. The tooling around them (Terraform, Ansible, containers, GitOps) transfers across providers.
Supabase and PostgreSQL, including Row Level Security policies for access control at the database layer rather than only in application code. Also AWS RDS in production, where he configured automated backups and resolved security group misconfigurations, and MongoDB for Node.js applications.
Scanning runs as a gate, not a report. Snyk covers dependencies and static analysis, Trivy scans container images, and both are configured to fail the build on critical findings so a vulnerable image never reaches the registry. On the access side, the priority is removing long-lived credentials — OIDC federation instead of stored keys, and scoped IAM roles instead of broad permissions.
AWS Certified Cloud Practitioner, with AWS Certified Solutions Architect – Associate (SAA-C03) currently in progress. He has also completed structured training in Linux administration, Ansible automation and full-stack development.
Yes. He is open to DevOps, platform and cloud infrastructure roles, and responds to email within a day. The fastest way to reach him is the email address in the contact section.
07/Contact
Open to DevOps, platform and cloud infrastructure roles. If you have a pipeline that keeps breaking or infrastructure that needs a second pair of eyes, send a note.