What I use, and what I use it for
The tools, grouped the way the work is actually grouped. Each section links to the playbook where I argue for a particular way of using them.
Infrastructure as code
Provisioning and managing a large multi-account AWS environment, where every change is reviewable and reproducible rather than clicked into a console.
Terraform
My daily driver for infrastructure. The state file is the real product: it is the only record of what the infrastructure was meant to be, which is why it gets treated as production data rather than a build artifact.
Spacelift
The workflow layer around Terraform. Plans run in a controlled place, get reviewed, and get applied from that same place, so drift between what was approved and what shipped has nowhere to hide.
AWS
My primary cloud. ECS and Fargate for containerized services, RDS for databases, CloudWatch for telemetry, IAM for access. Also where I do cost optimization and right-sizing work.
RDS
Managed relational database infrastructure: provisioning, parameter and backup configuration, and the right-sizing that follows once you can see actual utilization instead of guessing at it.
IAM, secrets, and encryption
Credential management, secrets handling, and data encryption practices. The working rule is least privilege by default, and no long-lived access keys where a federated role will do the job.
Containers and runtime
Packaging services so the artifact behaves the same on a laptop, in a pipeline, and in production, and so a bad release can be backed out fast.
Docker
Containerized services for consistent, portable delivery. A container should receive its configuration from outside and should boot on a laptop with no cloud credentials, or it is not really portable.
ECS and Fargate
Where the containers actually run. Task definitions, service scaling, and the health-check and draining behavior that decides whether a deploy is invisible to users or not.
CodeDeploy
Blue/green releases, which are only worth the extra machinery if you genuinely keep the old version warm and can shift traffic back to it in minutes rather than in a rebuild.
ECR
Image registry, and the scanning gate in front of it. Image size is a delivery metric rather than a tidiness one: it is pull time on every deploy and every scale-out event.
CI/CD
The pipeline is the single source of truth for whether a change is safe to ship. I have built and maintained delivery pipelines across four CI systems, including migrating between them.
GitHub Actions
Including this site, which deploys itself on push using a federated OIDC role rather than stored access keys. The workflow only orchestrates: it calls the same deploy script that runs on a laptop, so a broken pipeline stays debuggable locally.
GitLab CI
I have led migrations of existing pipelines onto GitLab CI as part of a broader effort to consolidate delivery tooling, moving one repository at a time rather than attempting a single cutover.
Jenkins
Long-running build and deployment automation for production services. The lesson Jenkins teaches best is to keep the logic in version-controlled scripts rather than in job configuration nobody can review.
Bitbucket Pipelines
Source control and continuous delivery for a number of the repositories I support, and the starting point for most of the GitLab CI migration work.
Observability
Knowing what production is doing before a customer tells you. Logs, metrics, and traces answer genuinely different questions, and you need all three.
Datadog
Metrics, dashboards, and alerting for system health and incident response. Alerts get written against symptoms a user would notice rather than against causes, because the list of causes is never finished.
CloudWatch
The AWS-native layer: log groups, metrics, and alarms, and the place infrastructure-level signals surface first when something shifts underneath a service.
Elasticsearch and ELK
Indexing, searching, and correlating application and infrastructure logs. Structured logging is the prerequisite for all of it, and also for letting an agent anywhere near an incident.
Automation and AI
Most operational work is glue. The goal is glue that is safe to run twice, says plainly what it did, and can be handed to someone else.
Python
My primary automation language, from infrastructure tooling to data collection to the backend of this site. Idempotent by default, dry run by default, and output written for the person reading it at 2am.
Flask
The framework behind this site and several smaller internal tools. This one is frozen to static HTML at build time, so there is no running backend to operate or patch.
Claude Code
Used daily for incident triage, log correlation, and drafting automation. The leverage is in what you hand it up front, and in encoding a workflow once the model has proven the workflow works.
MCP
Model Context Protocol servers give an assistant real, scoped access to systems instead of pasted context. Scope the credentials to the minimum necessary and log every tool call.
Also worked with
Real experience, mostly from freelance work and earlier roles, that sits outside the infrastructure work I do now.
JavaScript, HTML, and CSS
Front-end work for client sites and custom web apps, built with utility-first CSS. This site included.
MySQL
Relational schema design and querying, mostly behind the applications I built and the data analysis work that came before infrastructure.
Apache
Web server and reverse proxy configuration from freelance and self-hosted projects where I owned the whole stack.
Serverless Framework
Used for static sites and Lambda-backed infrastructure. I have also moved projects off it and onto plain Terraform, this one included, where that made the deployment simpler to reason about.
The reasoning behind the choices
A tool list says what I have touched. The strategy says what I optimize for when two of these tools disagree, which is the part that actually transfers between jobs.