<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://blog.biggie.be/</id><title>BiGGie's Place</title><subtitle>A minimal, responsive and feature-rich Jekyll theme for technical writing.</subtitle> <updated>2026-10-07T01:51:49+02:00</updated> <author> <name>Gilberto Torres</name> <uri>https://blog.biggie.be/</uri> </author><link rel="self" type="application/atom+xml" href="https://blog.biggie.be/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://blog.biggie.be/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Gilberto Torres </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>One Worker, Four Databases: Building an Edge Status Monitor on Cloudflare</title><link href="https://blog.biggie.be/posts/edge-status-monitor-cloudflare-workers/" rel="alternate" type="text/html" title="One Worker, Four Databases: Building an Edge Status Monitor on Cloudflare" /><published>2026-07-19T10:00:00+02:00</published> <updated>2026-07-19T10:00:00+02:00</updated> <id>https://blog.biggie.be/posts/edge-status-monitor-cloudflare-workers/</id> <content type="text/html" src="https://blog.biggie.be/posts/edge-status-monitor-cloudflare-workers/" /> <author> <name>Gilberto Torres</name> </author> <category term="homelab" /> <summary>Everyone who runs a homelab eventually learns the same lesson: the worst place to host your status page is your homelab. When the hypervisor is down, so is the page that’s supposed to tell you the hypervisor is down. I’ve had monitoring inside the lab for a long time - Wazuh watches security events, Home Assistant pings things, PBS mails me about backups - but all of it lives inside the walls i...</summary> </entry> <entry><title>Ansible for Homelab Configuration Management</title><link href="https://blog.biggie.be/posts/ansible-homelab-config-management/" rel="alternate" type="text/html" title="Ansible for Homelab Configuration Management" /><published>2026-03-29T19:20:00+02:00</published> <updated>2026-03-29T19:20:00+02:00</updated> <id>https://blog.biggie.be/posts/ansible-homelab-config-management/</id> <content type="text/html" src="https://blog.biggie.be/posts/ansible-homelab-config-management/" /> <author> <name>Gilberto Torres</name> </author> <category term="setup" /> <summary>Terraform provisions the infrastructure. Ansible configures what runs inside it. This post covers how I use Ansible for configuration management across all DC guests - from Wazuh agent deployment to base system hardening - and how it fits into the broader GitLab CI pipeline. The Division of Labor The boundary between Terraform and Ansible is deliberate and strict: Layer ...</summary> </entry> <entry><title>Managing Proxmox with Terraform</title><link href="https://blog.biggie.be/posts/terraform-proxmox-provisioning/" rel="alternate" type="text/html" title="Managing Proxmox with Terraform" /><published>2026-03-29T19:10:00+02:00</published> <updated>2026-03-29T19:10:00+02:00</updated> <id>https://blog.biggie.be/posts/terraform-proxmox-provisioning/</id> <content type="text/html" src="https://blog.biggie.be/posts/terraform-proxmox-provisioning/" /> <author> <name>Gilberto Torres</name> </author> <category term="setup" /> <summary>Every VM and LXC in my homelab is defined in Terraform. If a resource isn’t in the Terraform state, it either doesn’t exist or it’s a documented exception. This post walks through how I use Terraform with the bpg/proxmox provider to manage all Proxmox resources, the CI/CD pipeline that executes it, and the patterns I’ve developed for a reliable provisioning workflow. Why Terraform for Proxmox?...</summary> </entry> <entry><title>Self-Hosting GitLab CE as an IaC Control Plane</title><link href="https://blog.biggie.be/posts/gitlab-ce-iac-control-plane/" rel="alternate" type="text/html" title="Self-Hosting GitLab CE as an IaC Control Plane" /><published>2026-03-29T19:00:00+02:00</published> <updated>2026-03-29T19:00:00+02:00</updated> <id>https://blog.biggie.be/posts/gitlab-ce-iac-control-plane/</id> <content type="text/html" src="https://blog.biggie.be/posts/gitlab-ce-iac-control-plane/" /> <author> <name>Gilberto Torres</name> </author> <category term="setup" /> <summary>Every infrastructure-as-code workflow needs a control plane - a single source of truth for code, state, and execution. This post covers why I chose self-hosted GitLab CE for that role, how it’s configured, and the lessons learned running it as the backbone of my homelab IaC stack. Why GitLab CE? I evaluated several options before settling on GitLab CE: GitHub (hosted), Gitea, Forgejo, and sel...</summary> </entry> <entry><title>Passbolt - Self-Hosted Password Manager</title><link href="https://blog.biggie.be/posts/passbolt-password-manager/" rel="alternate" type="text/html" title="Passbolt - Self-Hosted Password Manager" /><published>2026-03-29T18:50:00+02:00</published> <updated>2026-03-29T18:50:00+02:00</updated> <id>https://blog.biggie.be/posts/passbolt-password-manager/</id> <content type="text/html" src="https://blog.biggie.be/posts/passbolt-password-manager/" /> <author> <name>Gilberto Torres</name> </author> <category term="setup" /> <summary>Every infrastructure credential in my homelab lives in Passbolt. SMTP passwords, API tokens, encryption keys, tunnel secrets, cloud provider credentials - all of it. Passbolt is a self-hosted, open-source password manager designed for teams, and it’s the single most critical service in my entire setup. Lose access to Passbolt, and I lose access to everything. Why Passbolt? I evaluated several...</summary> </entry> </feed>
