标签：#DevOps

GitPython ships a guard against dangerous git options. If your code builds a clone command out of anything that arrived from outside, the library will not let --upload-pack or --config through by default, because both of them execute an arbitrary command. The guard is on out of the box and turns off only with an explicit allow_unsafe_options=True . I handed it --upload-pack=/srv/lab/helper.sh . It refused. I handed it the same thing written differently, -u/srv/lab/helper.sh , and it let it through. The script ran. This is CVE-2026-67324, published on 1 August 2026, scored 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0. Those numbers still come from the CNA that filed it: NVD has not run its own analysis yet, the record sits in status Received, so the score may move. Version 3.1.50 is vulnerable, 3.1.51 is fixed. Below, step by step: the lab, both attempts with real output, the code of the check and why it missed, and what the attack looks like from the outside. Plus the part I find more interesting than the hole itself. This is the third bypass of the same barrier within one year, and all three share a root cause. Why this deserves your attention Almost nobody installs GitPython on purpose. It gets 254 million downloads a month from PyPI against five thousand stars on GitHub, and a two-order gap like that means one thing: it arrives as a passenger. With MLflow, with DVC, with bandit, with semgrep, with half the homegrown scripts that touch repositories in CI. Let me draw the boundary right away, so nobody panics for nothing. Having it installed is harmless on its own. The hole fires only when two conditions hold at the same time: your code calls Repo.clone_from(..., multi_options=[...]) , something an outsider influences ends up inside multi_options . The second one happens more often than it sounds. A repository URL from a web form, build parameters from a config another team edits, a field in a CI job, arguments from a webhook. And if you are leaning on allow_unsafe_options=

Series: Platform engineering with Go | Topics: Go, Kubernetes, Cobra, client-go, metrics-server, Platform Engineering This is part of the Platform Engineering with Go series. This post builds on the Cobra CLI patterns from post 4 and client-go from post 3. Read post 4 first if you haven't yet. kubectl top tells you what's happening. It doesn't tell you how close to the edge you are. In post 3 and post 4 , we built a health reporter and learned how to structure a Go CLI with Cobra. Now we put both together into something with real operational value. kubectl top pods -n production NAME CPU ( cores ) MEMORY ( bytes ) go-api-7d6b9f8c4-xk2pq 240m 490Mi go-api-7d6b9f8c4-mn9rt 180m 210Mi go-api-7d6b9f8c4-p8wvz 200m 198Mi That first pod is using 490Mi of memory. Is that fine or is that a problem? Without knowing the limit, you can't tell. You'd have to run kubectl describe pod go-api-7d6b9f8c4-xk2pq , find the resources section, do the mental arithmetic, and repeat for every pod you care about. ferctl top does all of that in one command: ferctl top -n production NAMESPACE NAME CPU USE CPU REQ CPU LIM CPU% MEM USE MEM REQ MEM LIM MEM% STATUS production go-api-7d6b9f8c4-xk2pq 240m 250m 500m 48% 490Mi 256Mi 512Mi 95% !! CRITICAL production go-api-7d6b9f8c4-mn9rt 180m 250m 500m 36% 210Mi 256Mi 512Mi 41% OK production go-api-7d6b9f8c4-p8wvz 200m 250m 500m 40% 198Mi 256Mi 512Mi 38% OK One pod is at 95% of its memory limit. In production, that's a page waiting to happen. ferctl top catches it before it becomes an incident. What you'll learn How to extend the Cobra CLI structure from post 4 with a real subcommand How to query the metrics-server API using k8s.io/metrics How to correlate live metrics with pod specs to show usage vs limits How to implement configurable near-limit warnings How to format clean aligned output with tabwriter How to verify the tool against your real minikube cluster Prerequisites Posts 1–4 read; client-go patterns from post 3 , Cobra CLI structure from pos

Release notes answer an important question: what changed? About this method: I build KPainter , a source-to-explainer video workspace. KPainter helps teams turn release notes, product briefs, docs, screenshots, and other source material into clear explainer videos. The workflow below keeps the maintained source—not the video—as the source of truth. They are not always enough to answer the next questions a customer, support teammate, or implementation partner has: Does this change affect my workflow? What should I do differently? What is deliberately unchanged? Where can I check the current details when the product evolves again? That difference matters when a team turns a changelog, launch note, or technical update into a walkthrough. A screen recording can show a new control. A useful explanation helps the viewer decide whether to care, what to try, and where the boundary is. Start with the viewer's decision Before opening a recorder or drawing a storyboard, write one sentence in this form: After this walkthrough, [viewer] should know whether [change] affects [their job] , and what to do next. For example: After this walkthrough, an existing workspace administrator should know whether a new approval step changes their release process, and where to configure it. This sentence prevents a common failure mode: putting every release-note bullet into a video. A list of features is complete, but it is rarely a clear path through a decision. Establish the source hierarchy Product details have different lifetimes. The launch note may be a useful summary, while the maintained documentation defines the exact configuration, permissions, availability, or limits. Use a small source hierarchy before drafting scenes: Current product documentation — the maintained source for setup, constraints, and terminology. The release note or change record — why the change happened and the scope of the release. A verified product view — the interface or workflow that a viewer should recognise.

HashiCorp has released a public beta of Vault Kubernetes key management, a KMS v2-compatible plugin that lets the Kubernetes API server delegate envelope encryption to Vault Enterprise, moving the key encryption keys that protect etcd data out of the cluster and into a separately governed trust domain. By Mark Silvester

More than a year ago, which is practically ancient history in the AI years, I wrote a blog about using AI to build new self-service capabilities. It felt like the future. We built a self-service action that could create new self-service actions, helping us move faster, reduce bottlenecks, and scale a small Platform Engineering team supporting hundreds of developers. One of the most interesting parts was using Amazon Bedrock to generate Terraform code dynamically at runtime, allowing the system to determine how a new cloud resource should be provisioned using our existing Terraform modules. It worked. It was impressive. And… we removed it. Looking back, abandoning that approach turned out to be one of the best engineering decisions we made. At the time, it felt like an isolated technical decision. It wasn’t. Recently, we faced a much smaller problem. We wanted to automate the creation of DNS records in Cloudflare through our self-service platform. The first proposal was exactly what you’d expect today: “Let’s build a Claude Skill.” Immediately, I had a strong sense of deja vu. But my hesitation wasn’t about whether AI could do it — it was about whether it should. We were simply asking the wrong question. The Industry Shift A lot of engineers today feel like everything they learned over the last decade suddenly became less relevant. We are DevOps engineers. We are Platform Engineers. We used to spend time designing systems, defining standards, reviewing architectures, and planning before writing a single line of code. Every automation started with the same question: “How should we automate this?” Today, that question has quietly changed. Now we ask: “How can AI do this?” At first glance, that sounds like progress. And sometimes it is. Large Language Models have fundamentally changed the way we build software. Tasks that used to take hours now take minutes, and entire prototypes appear from a single prompt. The temptation is obvious. If AI can do it… why not let AI do

Tuesday morning. Your SOC 2 auditor emails you. "Can you provide evidence of human review for all AI-assisted code changes in the last 90 days — which files were modified, what prompts were used, and whether any credentials were visible in context?" You open your IDE. Git log? Commits are there. PR history? Reviews too. But the AI session itself — the conversation, the code it proposed, whether it saw your .env file, which compliance controls it touched — gone. That gap is why I built Chron. What Chron is Chron is an MCP server that runs alongside your AI coding tool. Every message, every code change, every detected secret — locally timestamped, hash-chained, and stored in a SQLite database you own. No cloud. No data sharing. Works offline. # Install once npm install -g chron-mcp # Check setup chron doctor Works with Claude Code, Cursor, Windsurf, Continue.dev — any MCP-compatible tool. The last four releases: answers to questions auditors actually ask v0.1.39 — "Which sessions are worth reviewing first?" $ chron risk --since = 30d SESSION SCORE BAND SIGNALS a1b2c3d4 87 critical secrets·auth·infra e5f6g7h8 52 high auth·findings ( 2 ) i9j0k1l2 28 review code_changes The attention score: deterministic 0–100 per session. No ML, no API calls. Pure signal from what actually happened: secrets detected (+25), auth code changed (+15), infra modified (+12), open compliance findings (+8 each). A security lead can triage 90 days of AI sessions in under a minute. v0.1.40 — "Can I get a one-pager for this audit?" $ chron dashboard --since = 30d --output = q3-audit.html ✓ Written: q3-audit.html 8 sessions · 4 open findings · 1 critical · 2 high Coverage: 6 controls covered · 3 needs evidence Five sections in a single static HTML file — no server, no login, no port: executive summary, sessions ranked by risk score, findings grouped by framework (SOC 2 / ISO 27001 / EU AI Act / NIST AI RMF), a control coverage map, and contextual next actions. Open in a browser. Print to PDF. Attac

Building an AI agent locally is an exciting first step. Running that same agent reliably in production is a different challenge. Once real users and external services are involved, the application needs more than working code. It needs repeatable deployments, secure configuration, health checks, monitoring, controlled updates, and a clear recovery process. This article is part of my MCP series. If you are new to the topic, start with my first article: Model Context Protocol (MCP) Servers Explained: A Complete Beginner’s Guide . In this article, I will outline a practical architecture for taking a Model Context Protocol, or MCP-based, AI agent from a local development environment to Kubernetes. This is a production architecture blueprint. The exact implementation will depend on the AI provider, MCP servers, cloud platform, and security requirements used by the application. What Is an MCP-Based AI Agent? The Model Context Protocol provides a standardized way for AI applications to connect with external tools, services, and data sources. An MCP-based agent may interact with: Internal APIs Databases File systems Search services Monitoring platforms Business applications Custom automation tools A basic implementation might work well on a developer's machine. In production, however, every dependency introduces operational questions: How will the application be deployed? Where will credentials be stored? How will failed requests be detected? Can the service handle additional traffic? How can a broken release be rolled back? What happens when an MCP server becomes unavailable? These are familiar DevOps and Site Reliability Engineering problems applied to a new type of workload. Target Architecture A practical delivery flow could look like this: Developer ↓ GitHub Repository ↓ GitHub Actions ↓ Container Registry ↓ Kubernetes Cluster ↓ MCP Servers and External Services ↓ Logs, Metrics, Traces, and Alerts Each component has a clear responsibility: GitHub stores the application

Also Published On trever.cloud Medium LinkedIn Most of us who get into self-hosting start the same way: start with linux, throw a few apps into Docker, get them running and connectable outside the home network, and call it good for months, maybe even years. Nothing wrong with that approach. A compose file and a spare mini PC gets you further than you think, and if it works and you don't have to think about it, that's a perfectly fine place to stop. Then there's the rest of us. The people who get that first setup running, feel the little spark of "wait, I built this", and immediately start wondering what else is possible. More services. Less babysitting. A real answer to "what happens if this box dies at 2am". If any of that sounds familiar, this one's for you. If you keep going, you'll eventually run into the question every self-hosted setup faces sooner or later, whether you notice it happening or not, "how much should live together, and how much should be kept apart?". Put everything on one box and you quickly feel the fragility when one bad update takes everything down with it. Or when nightly backups put services on hold longer and longer. Split everything into its own isolated piece and you've gained resiliency but now manage a lot of moving parts. Most of the actual learning in running infrastructure happens in the space between those two answers. Where you draw that line is where most of the real infrastructure lessons live. Over the years, I've lived through a few different answers to that question in my own homelab, and each one taught me something the previous one couldn't. It started with a large VM, Docker installed, and every service I wanted to self-host running as a container inside. It was the fastest path to "it's actually working", and at the time that was the whole goal. I didn't know yet what I'd eventually want out of this thing, so keeping the infrastructure simple while I figured that out made sense. That setup carried me a long way, and I don

You published a DMARC record months ago. Every checker says it's valid. No reports have ever arrived, and at some point you stopped thinking about it and quietly concluded nobody's forging your domain. You don't know that. You just can't see. Two causes account for almost all of it, and both leave the DMARC record itself looking perfect. 1. Your reporting address never agreed to receive them This is in the spec and almost nobody knows about it. If your rua= address is on a different organisational domain from the domain publishing the record, RFC 7489 section 7.1 requires the destination to explicitly consent. The reason is obvious once you see it: otherwise anyone could point rua= at your mailbox and use the world's mail infrastructure as a free DDoS. Consent is a DNS record, published by the receiving domain: <your-domain>._report._dmarc.<their-domain>. TXT "v=DMARC1" So if example.com sends reports to dmarc@reports.vendor.com , then vendor.com has to publish: example.com._report._dmarc.reports.vendor.com. TXT "v=DMARC1" Without it, conforming reporters send nothing at all. That includes Google, which is most of your report volume. You can watch this working in production. PayPal sends aggregate reports to a third party, and the authorisation record exists: paypal.com._report._dmarc.rua.agari.com. TXT "v=DMARC1;" The practical consequence: not a Gmail address You cannot put a Gmail address in rua= . Google is not going to publish yourdomain.com._report._dmarc.gmail.com on your behalf, and you can't create records in their zone. Same for Outlook, Yahoo, or any address at a domain you don't control. This is a common first move — publish DMARC, point reports at your personal inbox, wait. Nothing arrives, and nothing is wrong with the record. If you use a commercial DMARC service they normally publish these records during onboarding, often via a wildcard. If reports never start after you sign up, check this before anything else. When it doesn't apply: reporting to you

There's a failure mode in SPF that produces no error anywhere you'd think to look. Your record is syntactically valid. dig returns it. Your DNS provider is happy. Your own test mail arrives fine. And yet some of your mail is failing authentication at the receiver, and nothing in your infrastructure will tell you. The cause is usually that you've gone past ten DNS lookups. Ten is a hard ceiling, not a guideline RFC 7208 section 4.6.4 requires evaluators to cap DNS-querying terms at ten. Go past it and the result is PermError — a permanent failure. The important part: receivers don't degrade gracefully. They don't evaluate the first ten and shrug at the rest. They treat the entire record as unusable. You go from "SPF configured" to "SPF absent" in one step, and the only place that's visible is in DMARC aggregate reports, which most people aren't reading yet. Six terms cost a lookup. Four are free. Costs a lookup Free include: ip4: a ip6: mx all ptr exp= exists: redirect= The count isn't yours to control This is what catches people out. The limit applies to the whole resolution tree, not just your record. You publish four includes. One of those vendors publishes six includes of their own. You're at eleven, and your record lists four things. Nothing changed on your side. A vendor updated their record and broke yours. There is no notification for this, from anyone, ever. Counting it by hand You can walk the tree with dig if you want to see it directly: dig +short TXT example.com | grep spf1 Then for every include: you find, recurse: dig +short TXT _spf.vendor.com | grep spf1 Keep going until you bottom out, counting every include: , a , mx , ptr , exists: and redirect= along the way. It's tedious but instructive — you'll usually find one vendor accounting for half your budget. Three traps that make tools lie to you Doing this by hand or with a naive script, there are three places to go wrong. I've seen all three produce confidently incorrect output. 1. redirect= uses = ,

Originally published at wostal.eu . TL;DR : I handed a CI re-platform — GitHub Actions → Argo Workflows, GitHub → Codeberg — to an AI agent. The rewrite looked correct and passed lint, but it didn't account for one thing: the runtime environment had changed completely. The old runner was an external VM; the new one is a pod inside the cluster, where Tailscale IPs aren't routable. Nobody ran the pipeline end-to-end, so every difference stayed as a landmine — six of them. The worst part wasn't the AI's mistake. It was that I spent hours blaming the network when the real culprit was a single missing newline in an SSH key. This is the companion to a different incident. While I was migrating my homelab k3s control plane from SQLite to etcd , the pipeline that ran that migration turned out to be broken in ways that taught me more than the migration itself. In this post I'll cover: Where the mess came from — an AI-assisted CI re-platform that nobody validated end-to-end The phantom CNI bug — hours of chasing MTU, Tailscale, firewall, and conntrack The real culprit — a single missing newline in an SSH key Why early failures hide later ones — six latent bugs, surfaced one at a time The lesson about delegating migrations — to a human or an AI Where the mess came from The entire CI had just been migrated from GitHub Actions to Argo Workflows , and from GitHub to Codeberg — and that migration was handed to an AI agent 🙂. The re-platforming rewrote the logic roughly 1:1, but it didn't catch that the runtime environment had changed fundamentally . The old runner (GitHub Actions / ARC) behaved one way; the new one is a pod in the cluster — from which Tailscale IPs aren't routable, but private IPs are. Nobody (human or AI) ran the pipeline end-to-end, so all of those differences stayed as landmines. That's why there were six latent bugs and the hang I'm about to describe — not random faults, but traces of a GHA→Argo translation that was never validated in the new environment. The p

On Windows I kept launching background servers from a task runner and watching them die the instant the launching step finished — no error, no log, just gone. The task runner was wrapping everything in a job object, and job-object teardown kills every child process on return. Nothing I did inside the child mattered; its death warrant was signed by how it was born. The workaround was to have the process created by something that outlives the runner — the OS scheduler, a WMI process-create call — instead of spawning it as a doomed descendant. When a process keeps dying without a trace, look at its lineage before its code — some parents kill their children on the way out, and no amount of hardening inside the child fixes how it was spawned.

I'm halfway through the MLH Production Engineering Fellowship, and while I've learned a lot technically—from Linux fundamentals, Docker, NGINX, automated testing, and contributing to open source, the thing that has stood out to me most is how well the program is structured. Beyond the technical curriculum, there is a strong emphasis on interview preparation and career growth. We’ve had regular opportunities to practice technical interviews, receive feedback, and stay in close contact with our Meta mentors, who have been incredibly approachable throughout the program. Looking forward to seeing what the second half of the fellowship has in store. Thanks to the MLH team, mentors, and my podmates for making it such a rewarding experience so far!

Your cron expression can be valid and still never run A cron parser can answer one question— does this have five fields and legal tokens? —while your scheduler needs a different answer: will this job ever run, and will it run when I intended? That gap is where silent cron failures live. A schedule can be syntactically valid, return no parser error, and still be impossible, surprisingly broad, or operationally noisy. Here is a small semantic checklist you can run before deploying a schedule. 1. Check the calendar, not only the grammar Consider: 0 0 30 2 * This has the right five-field shape: minute, hour, day of month, month, day of week. But February has no day 30. A syntax-only validator can label it valid, while a calendar-aware validator should tell you that its approximate frequency is never. That distinction is important in CI: treat a parse error as a broken input, but treat an impossible calendar match as a review failure. Both deserve attention, but they need different messages. The same idea applies to leap days. 0 0 29 2 * is meaningful, but it does not fire in non-leap years. Whether that is correct depends on the job; the validator should surface the edge case instead of silently deciding for you. 2. Be explicit about day-of-month/day-of-week semantics This expression is a classic source of surprises: 0 0 1,15 * 1 Many traditional cron implementations treat a restricted day-of-month and a restricted day-of-week as an OR , not an AND. In that model, the job runs on the 1st, the 15th, or Monday. Someone reading the expression as “the 1st or 15th when it is Monday” will get a different schedule. This is not a universal rule across every scheduler, so check the documentation for the runtime that will execute the job. The useful validation behavior is to warn whenever both fields are restricted and force the author to choose the intended semantics. For example, a lightweight pre-deployment check can start like this: function semanticWarnings ( expression ) {

Cloudflare recently introduced Meerkat, an internal globally consistent control-plane service based on the QuePaxa consensus algorithm. Unlike Raft, it allows leaderless writes while preserving strong consistency, improving availability across Cloudflare's global network. By Renato Losio

Yesterday I announced I'm blogging daily on AWS & DevOps. Here's Day 1 — the fundamentals everything else builds on. ## What is Cloud Computing? Instead of setting up and maintaining infrastructure on-premises, you now access computing resources remotely over the internet — this is Cloud Computing. "Cloud" refers to a network that provides resources over the internet, accessible whenever needed. It evolved from grid computing, virtualization, and distributed computing. All you need to use it is a web browser. As per NIST , cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort. Key characteristics: uses virtualization, enables on-demand access, and offers "pay-as-you-use" pricing. Traditional companies had to spend heavily on infrastructure, hardware, and operations. With cloud computing, providers manage all of this — handling troubleshooting, recording activity, and sending analytics data to users. Service Models — IaaS, PaaS, SaaS IaaS : Providers offer databases, servers, storage, and networking as a service, and you pay per use. Examples: AWS, Azure, GCP. PaaS : Gives you an on-demand environment for developing, testing, and delivering apps, with ready dev tools already set up. Examples: Heroku, Google App Engine. SaaS : Delivers ready-to-use software over the internet, usually via subscription, with the provider managing everything underneath. - Examples: Gmail, Microsoft 365, Google Drive. The layered view: moving from On-Premise to IaaS to PaaS to SaaS, each model hands you a bigger pre-managed slice. On-premise means you manage everything yourself. IaaS shifts virtualization, servers, storage, and networking to the vendor. PaaS additionally hands over OS, middleware, and runtime. SaaS means the vendor manages everything — you just use the app. The biryani a

Two usage-based cloud platforms with different defaults — a CLI-and-primitives approach versus a repo-first, visual-canvas workflow. Here is how they line up as of 2026-07-29. Fly.io and Railway both let you deploy apps and services and pay for what you use, but they start from different defaults. Railway centers on connecting a Git repository and letting the platform read your code and configure the deploy, all viewed on a visual canvas. Fly.io centers on the flyctl command line and a documented catalog of infrastructure primitives, from machines to managed databases and GPUs. This comparison walks through how each platform handles deployment, pricing, databases, networking, and scaling, using each vendor page as of 2026-07-29. Plan details and prices change often, so treat the figures here as a snapshot and confirm the current terms on each site before you commit. At a glance In short Both are usage-based platforms for shipping apps. Pick Railway to connect a repo and let the platform configure, preview, and roll back deployments from a visual canvas. Pick Fly.io for CLI-driven control plus a documented catalog of Managed Postgres, GPUs, Kubernetes, and HIPAA-ready hosting. Pricing and features noted here are as of 2026-07-29. Head to head Key differences side by side. Feature Fly.io Railway Billing model Usage-based, pay-as-you-go for micro VMs and storage; pricing calculator (as of 2026-07-29) Usage-based, billed per second (as of 2026-07-29) Plan tiers No named consumer tiers; usage plus paid add-ons (as of 2026-07-29) Free $0, Hobby $5/mo min, Pro $20/mo min, Enterprise custom (as of 2026-07-29) Deploy & configuration flyctl CLI and fly launch; config in fly.toml (as of 2026-07-29) Connect repo, auto-config from your code, visual canvas, YAML optional (as of 2026-07-29) Global footprint 18+ regions, sub-second machine boot, 99.9% uptime SLA (as of 2026-07-29) Global deployment, run closer to users; homepage listed no region count (as of 2026-07-29) Managed dat

When a chatbot hallucinates, a person reads the answer and catches it. When an agent hallucinates, it may have already run the query, sent the email, or changed the config before anyone looks. That single difference is why agent safety is its own discipline rather than a subsection of application security, and it is why OWASP shipped a dedicated Top 10 for Agentic Applications in December 2025 instead of folding the problem into the existing LLM list. Most teams I talk to are not missing this because they disagree. They are missing it because the safety work never got a line in the plan. The agent shipped, it worked, and the access model that came with it on day one is still the access model on day ninety. Permission Creep Is The Real Attack Surface The incidents that actually happen are boring. An agent gets built to summarize documents. Two sprints later somebody needs it to write a summary file, so it gets write access. Then it needs to post the summary, so it gets an API token. Nobody sat down and approved a document summarizer with filesystem and network write access, but that is what exists now, and the access model was never revisited because nothing broke. Least privilege is easy to agree with and boring to maintain, which is exactly why it fails. The useful version is a rule rather than a principle: every agent starts at zero permissions, and every capability you add triggers a re-read of the whole permission set rather than an append to it. Indirect Prompt Injection Turns Data Into Instructions Prompt injection is still OWASP's number one risk for LLM applications, and it gets meaningfully worse in an agentic context because the payoff is no longer a misleading answer, it is a real action. The direct version, where a user types something that overrides the system prompt, is the one everybody tests for. The version that gets people is indirect: the malicious instruction sits inside a web page, a support ticket, a PDF, or a database row that the agent was to

We've all done it. You spin up an RDS instance to test something on a Friday afternoon. You attach an EBS volume to a t3.micro that you kill three days later — but the volume just... stays. You allocate a static IP for a load test, and the load test ends, but the IP doesn't know that. None of this shows up as an error. Nothing crashes. There's no red banner in the console screaming at you. It just quietly sits there, accruing charges, until you open your AWS bill a month later and go "wait, why are we paying for that ?" I call these zombie resources — infrastructure that's technically alive (and billing you) but functionally dead. It's happened to me enough times on side projects and client work that I've started designing a small tool to stop it: CloudZombie . Heads up: this is early. There's no working product yet — I'm validating the idea and building in the open, starting with a waitlist. If that's not your thing, no hard feelings, but if you've felt this exact pain before, I'd love your take. The problem, more specifically Cloud waste isn't usually one big dramatic mistake. It's death by a thousand cuts: Orphaned EBS volumes — you terminate an EC2 instance, but the attached volume doesn't get deleted with it, so it just sits in an "available" state forever. Idle databases — that staging or QA RDS instance nobody remembers spinning up, quietly running at under 1.5% CPU for weeks. Abandoned static IPs and load balancers — cloud providers actually charge more for an Elastic IP that isn't attached to anything, which feels like a small act of cruelty. Individually, each one is a few dollars a month. Collectively, across a handful of side projects or a growing team's sprawl of staging environments, it adds up to real money leaking out of your runway — with zero warning. What CloudZombie is meant to do The plan is for CloudZombie to connect (read-only) to your AWS account and scan specifically for these patterns: Unattached EBS volumes sitting idle Databases with sust

After setting up Jenkins and creating my first Declarative Pipeline, the next step was preparing my machine to build Docker images. Since my pipeline will eventually clone code from GitHub, build a Docker image, and push it to a container registry, Jenkins needs access to Docker. Without Docker installed, the docker build stage would fail because Jenkins wouldn't be able to execute Docker commands. Installing Docker On my Ubuntu machine, I installed Docker using: sudo apt update sudo apt install docker.io -y Once the installation completed, I verified it using: docker --version This confirmed that Docker was successfully installed and ready to use. Verifying Docker Installation Installing Docker is only half the job. The next step is to check whether your current user has permission to use Docker. Run: docker ps Expected Output If everything is configured correctly, you should see something similar to: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES Even if no containers are running, getting an empty table like the one above means Docker is working correctly. What If You Get a Permission Error? If you see an error like: permission denied while trying to connect to the Docker daemon socket it means your current user doesn't have permission to access the Docker daemon. First, check which user you're currently logged in as: whoami Example output: nishant Now add your user to the docker group: sudo usermod -aG docker $USER What does this command do? usermod modifies a user account. -aG means append the user to a supplementary group without removing existing groups. docker is the group that has permission to communicate with the Docker daemon. $USER automatically refers to your currently logged-in username. Apply the Changes The group membership won't take effect immediately. You have two options: Option 1 (Recommended): Log out of your Ubuntu session and log back in. This refreshes your user groups and is the most reliable method. Option 2: Simply restart your ter