Hi, I’m Reza 👋

As part of my infrastructure hardening and automation efforts, I built a CIS-hardened Debian 12 AMI using Packer and the ansible-lockdown/DEBIAN12-CIS Ansible role. For reference or reuse, I’ve made the AMI publicly available: AMI ID: ami-0ded45c1c47569084 Region: us-east-1 This post documents how I did it from scratch. 🛠️ Tools Used Packer Ansible Ansible Lockdown Role AWS EC2 Debian 12 (Official AMI) 📁 Project Structure cis-debian-ami/ ├── packer.pkr.hcl ├── ansible/ │ ├── playbook.yml │ └── roles/ │ └── DEBIAN12-CIS/ # added via git submodule To add the Ansible role: ...

A Clean Naming Convention for Docker Build & Push Workflows In my development projects, I often need to build and push Docker images automatically using CI workflows. Depending on the project, the architecture, and the target registry, the workflows can vary quite a bit. Sometimes I use Gitea Actions, sometimes GitHub Actions, and in some projects, even both. As the number of workflows grew, I realized that my workflow file names were getting messy and inconsistent. So, I decided to come up with a simple, scalable naming convention — one that would work cleanly whether I’m using GitHub, Gitea, or any other CI platform. ...

When working with large language models (LLMs), it’s often useful to feed them the source code of a project for analysis, refactoring, or documentation assistance. However, simply copying folders is messy — you usually only want the text files that are tracked by Git, displayed cleanly, without non-text files or noise. To streamline this, I wrote a Bash script that: Ensures you are inside a Git repository. Lists all Git-tracked files. Filters out non-text files. Skips empty or unreadable files. Prints the content of each file, with a clean header showing the relative path. Perfect for quickly preparing a project snapshot to paste into an LLM. ...

Hello, World! 👋 Welcome to my corner of the internet. I’ve been meaning to set up a personal website for a long time — a place to collect my thoughts, document experiments, share the things I’m building (or breaking), and simply keep track of what I’m learning along the way. This site is not just a blog. It’s also a vault where I’ll archive useful notes, procedures, configs, and ideas — things that I often end up writing down in scattered files or losing inside forgotten notebooks. Now, I’ll try to keep them organized here, both for myself and for anyone else who might find them useful. ...