I Built a Free Cloudflare Worker to Block 2,000+ Weekly Bot Sessions (Open Source)

My site was getting hammered by bot traffic—over 2,000 sessions per week from China and Tencent's network, completely polluting my Google Analytics. I built a Cloudflare Worker to fix it, and it's been running in production for months with zero issues.

# The Problem

* 800+ sessions/week from Lanzhou, China
* 500+ from Tencent's network (ASN 13220/132203)
* AI scrapers ignoring robots.txt
* Analytics showing 60% bot traffic
* Impossible to see real user metrics

# The Solution

A multi-layer Cloudflare Worker that blocks bots at the edge before they hit your server:

**Layer 1: Geographic + ASN Blocking**
Block specific countries (e.g., China) and networks/hosting providers (e.g., Tencent).

**Layer 2: AI Scraper Blocking**
Blocks 14+ known AI training bots (GPTBot, Claude, CCBot, etc.) while still allowing legitimate search engines.

**Layer 3: Rate Limiting**
Prevents aggressive scraping with customizable limits per IP.

# Results After Deployment

* Blocked 2,000+ bot sessions/week
* Analytics pollution dropped 60%
* Server bandwidth reduced 40%
* Zero false positives
* Runs on Cloudflare free tier ($0/month)
* <1ms execution time (no performance impact)

# Open Source

I've cleaned up the code and open-sourced it: [**github.com/AbdusM/cloudflare-bot-blocker**](https://github.com/AbdusM/cloudflare-bot-blocker)

Includes production-ready worker code, three configurations (minimal, standard, strict), complete setup guide, monitoring instructions, real-world ASN/country lists, and MIT license.

# Quick Start

# Clone and deploy
git clone https://github.com/AbdusM/cloudflare-bot-blocker
cd cloudflare-bot-blocker

# Customize blocking rules in worker.js
# Edit BLOCKED_COUNTRIES, BLOCKED_ASNS, AI_SCRAPERS

# Deploy
wrangler deploy


# Who Should Use This

* Sites getting bot traffic from China/Tencent
* Anyone tired of AI scrapers ignoring robots.txt
* GA4 showing suspicious traffic patterns
* Sites wanting to protect bandwidth/server resources
* Anyone on Cloudflare (free tier works)

# Configuration Examples

|Mode|Use Case|What It Does|
|:-|:-|:-|
|**Minimal**|Global audience|Block China, Tencent networks, worst AI scrapers only|
|**Standard**|Most sites|Block specific countries, known bot networks, AI crawlers, balanced rate limits|
|**Strict**|Regional sites|Whitelist specific countries, block all AI scrapers, aggressive rate limiting|

# Monitoring

The worker logs all blocks as JSON:

{
"action": "BLOCKED",
"reason": "blocked_country",
"country": "CN",
"ip": "1.2.3.4",
"path": "/some-page",
"timestamp": "2025-11-29T12:00:00.000Z"
}


View live: `wrangler tail your-worker-name --format=json | grep "BLOCKED"`

# Important Notes

* Test before deploying to production
* Be careful blocking countries where you have real users
* Check your analytics to identify bad ASNs
* Monitor logs after deployment

# Contributing

PRs welcome—especially new AI scraper user agents (the landscape changes fast), common bot ASNs, and performance improvements.

https://redd.it/1pa3qyg
@r_devops

Python CLI for automating Advent of Code workflows (caching, safe submissions, leaderboards)

I built a small Python CLI called “elf” to automate Advent of Code tasks that usually require manual copy and paste. It is designed to be noscriptable and safe for repeated use.

Features:
• Fetch and cache puzzle inputs
• Guarded answer submissions with guess history
• Private leaderboard retrieval (JSON, table, or typed model)
• Typed Python API for integration or automation
• Cross-platform and dependency-light

GitHub: https://github.com/cak/elf
PyPI: https://pypi.org/project/elf

If anyone automates AoC for fun or as a warmup exercise each December, I’d appreciate feedback.https://github.com/cak/elf

https://redd.it/1pa4n8r
@r_devops

Excessive Data Exposure in APIs: Why Your Endpoints Return Too Much Information 📤

https://instatunnel.my/blog/excessive-data-exposure-in-apis-why-your-endpoints-return-too-much-information

https://redd.it/1pa8ghg
@r_devops

The momentum of Gitless GitOps (OCI Centric)

You think it’s just a buzz or a real solution that will be adopted?

Have you adopt it? Share some experience, since we considering going there

https://redd.it/1pa9hxr
@r_devops

Our sprint planning keeps blowing up bc of surprises every damn week… how do we stick to our agenda?

Every time we try to run a clean session, someone suddenly remembers a critical ticket, a hidden dependency or some last-minute scope change that nukes the whole plan. It’s like the agenda is just a suggestion at this point. Anyone figured out how to keep things structured without sounding like the process police?

https://redd.it/1pab2uc
@r_devops

Struggling to find a proper way to share private helm charts to clients

So we have some private helm charts that we want to distribute to our clients, our OCI images are private and are in dockerhub, ideally i would like to have one place to grant access to our helm charts and our docker images. that's why i pushed the charts also there.


Should i add the clients as members in the team in dockerhub with only read access? so that they can get both the images and the charts? what is your way of handling this.


ideally i wouldn't want to require my clients to sign in to docker, just an access token that i manage and distribute to the client would be enough, access tokens in docker however are user based. you need to specify the user to consume them.

https://redd.it/1paea9g
@r_devops

DevOps blogs

Hello!

Do you guys have good devops blogs to suggest me to keep me updated on latest trends?

Please not Medion

https://redd.it/1pafgwy
@r_devops

What are the signs of a good company to work for?

I see lots of posts about how their management has the unrealistic expectations because of not understanding their tech team's role or capabilities or wanting to cut corners. Or of management who doesn't care about security. Is this a problem at every workplace? Are there places who take their tech teams more seriously and are more enjoyable to work at?

https://redd.it/1pagcon
@r_devops

Progression to next role

Hi,

Recently been looking at progression as a senior devops engineer and moving to the next step. Whilst I want to remain technical I understand there will be an element of being hands off.

What roles should I be looking at?

https://redd.it/1pai5m2
@r_devops

How do you design CI/CD + evaluation tracking for Generative AI systems?

Hi everyone, my experience mainly on R&D AI Engineer. Now, I need to figure out or setup a CI/CD pipeline to save time and standardize development process for my team.

So I just successfully created a pipeline that run evaluation every time the evaluation dataset change. But there still a lot of messy things that I don't know what's the best practice like.

(1) How to consistently track history result: evaluation result + module version (inside each module version might have prompt version, llm config,...)

(2) How to export result to dashboard, which tool can be used for this.

Anyway, I might still miss something, so what do your team do?

Thank you a lot :(



https://redd.it/1pal8o3
@r_devops

Microservices Dependency Maintenance Hell: Which Bot gives Maximum Value for Minimum Noise?

We're drowning.
Our team maintains dozens of microservices, and we’re stuck in a reactive loop: a new high-severity CVE drops, and we scramble to manually check, validate, and patch every single affected repo. We need to automate this, but we desperately want to avoid the Pull Request Tsunami.

The dream bot is one that delivers maximum fixes with minimum noise.

I’m looking around at the usual suspects:

1. Dependabot: Simple to set up, but notorious for flooding the queue with single, non-aggregated PRs, often for minor updates that aren't security critical. Noise levels are generally high.
2. Renovatebot: We know it’s highly configurable. Its grouping and scheduling are fantastic for general version bumps, but for security, it still tends to alert on every dependency with a CVE, even if the vulnerable function isn't used by our code. It reduces version noise but not necessarily security noise.
3. Frogbot: This is the one that's looking genuinely interesting, especially since we already use JFrog Xray. Frogbot claims to use Contextual Analysis—meaning it should only create a fix PR if the vulnerability is actually reachable and exploitable in our code. If this is true, it's the silver bullet for low-noise, high-impact security automation.

How are you managing this at scale?

Has anyone truly leveraged Frogbot's Contextual Analysis across a large fleet of microservices? Did it deliver on the promise of significantly reducing the noise to only the actionable security fixes?
For users sticking with Renovatebot, what are your best, most aggressive configuration secrets for turning off the noise? Do you use auto-merge for patches only, or do you have a specific grouping strategy that targets security fixes over everything else?

We're trying to move our dependency effort from manual fire-fighting to confident, autonomous security patching. What is your best tool for the job?

https://redd.it/1pam23g
@r_devops

From SaaS Black Boxes to OpenTelemetry

> **TL;DR:** We needed metrics and logs from SaaS (Workday etc.) and internal APIs in the same observability stack as app/infra, but existing tools (Infinity, json_exporter, Telegraf) always broke for some part of the use-case. So I built [otel-api-scraper](https://github.com/aakashh242/otel-api-scraper) - an async, config-driven service that turns arbitrary HTTP APIs into OpenTelemetry metrics and logs (with auth, range scrapes, filtering, dedupe, and JSON→metric mappings). If "just one more cron noscript" is your current observability strategy for SaaS APIs, this is meant to replace that. [Docs](https://aakashh242.github.io/otel-api-scraper/)

I’ve been lurking on tech communities in reddit for a while thinking, “One day I’ll post something.”
Then every day I’d open the feed, read cool stuff, and close the tab like a responsible procrastinator.
That changed during an observability project that got...interesting. Recently I ran into an observability problem that was simple on paper but got annoying the more you dug deeper into it. This is a story of how we tackled the challenge.

---

So... hi. I’m a developer of ~9 years, heavy open-source consumer and an occasional contributor.

**The pain:** Business cares about signals you can’t see yet and the observability gap nobody markets to you

Picture this:

- The business wants data from SaaS systems (our case Workday, but it could be anything: ServiceNow, Jira, GitHub...) in the same, centralized Grafana where they watch app metrics.
- Support and maintenance teams want connected views: app metrics and logs, infra metrics and logs, and "business signals" (jobs, approvals, integrations) from SaaS and internal tools, all on one screen.
- Most of those systems don’t give you a database, don’t give you Prometheus, don’t give you anything except REST APIs with varying auth schemes.

The requirement is simple to say and annoying to solve:
> We want to move away from disconnected dashboards in 5 SaaS products and see everything as connected, contextual dashboards in one place.
Sounds reasonable.

Until you look at what the SaaS actually gives you.

**The reality**

What we actually had:

- No direct access to underlying data.
- No DB, no warehouse, nothing. Just REST APIs.
- APIs with weird semantics.
- Some endpoints require a time range (start/end) or “give me last N hours”. If you don’t pass it, you get either no data or cryptic errors. Different APIs, different conventions.
- Disparate auth strategies.
Basic auth here, API key there, sometimes OAuth, sometimes Azure AD service principals.

We also looked at what exists in the opensource space but could not find a single tool to cover the entire range of our use-cases - they would fall short for some use-case or the other.

- You can configure Grafana’s [Infinity data source](https://github.com/grafana/grafana-infinity-datasource) to hit HTTP APIs... but it doesn’t persist. It just runs live queries. You can’t easily look back at historical trends for those APIs unless you like screenshots or CSVs.
- Prometheus has [json_exporter](https://github.com/catawiki/json_exporter), which is nice until you want anything beyond simple header-based auth and you realize you’ve basically locked yourself into a Prometheus-centric stack.
- Telegraf has an [HTTP input plugin](https://docs.influxdata.com/telegraf/v1/input-plugins/http/) and it seemed best suited for most of our use-cases but it lacks the ability to scrape APIs that require time ranges.
- Neither of them emit log - one of the prime use-cases: capture logs of jobs that ran in a SaaS system

**Harsh truth:** For our use-case, nothing fit the full range of needs without either duct-taping noscripts around them or accepting “half observability” and pretending it’s fine.

---

**The "let’s not maintain 15 random noscripts" moment**

The obvious quick fix was:

> "Just write some Python noscripts, curl the APIs, transform the data, push metrics somewhere. Cron it. Done."

We did that in the past. It works... until:

- Nobody remembers how each

noscript works.
- One noscript silently breaks on an auth change and nobody notices until business asks “Where did our metrics go?”
- You try to onboard another system and end up copy-pasting a half-broken noscript and adding hack after hack.

At some point I realized we were about to recreate the same mess again: a partial mix of existing tools (json_exporter / Telegraf / Infinity) + homegrown noscripts to fill the gaps. Dual stack, dual pain. So instead of gluing half-solutions together and pretending it was "good enough", I decided to build one generic, config-driven bridge:

> Any API → configurable scrape → OpenTelemetry metrics & logs.

We called the internal prototype `api-scraper`.

The idea was pretty simple:

- Treat HTTP APIs as just another telemetry source.
- Make the thing config-driven, not hardcoded per SaaS.
- Support multiple auth types properly (basic, API key, OAuth, Azure AD).
- Handle range scrapes, time formats, and historical backfills.
- Convert responses into OTEL metrics and logs, so we can stay stack-agnostic.
- Emit logs if users choose

It's not revolutionary. It’s a boring async Python process that does the plumbing work nobody wants to hand-roll for the nth time.

---

**Why open-source a rewrite?**

Fast-forward a bit: I also started contributing to open source more seriously. At some point the thought was:

> We clearly aren’t the only ones suffering from 'SaaS API but no metrics' syndrome. Why keep this idea locked in?

So I decided to build a clean-room, enhanced, open-source rewrite of the concept - a general-purpose otel-api-scraper that:

- Runs as an async Python service.
- Reads a YAML config describing:
- Sources (APIs),
- Auth,
- Time windows (range/instant),
- How to turn records into metrics/logs.
- Emits OTLP metrics and logs to your existing OTEL collector - you keep your collector; this just feeds it.

I’ve added things that our internal version either didn’t have:

- A proper configuration model instead of “config-by-accident”.
- Flexible mapping from JSON → gauges/counters/histograms.
- Filtering and deduping so you keep only what you want.
- Delta detection via fingerprints so overlapping data between scrapes don’t spam duplicates.
- A focus on keeping it stack-agnostic: OTEL out, it can plug in to your existing stack if you use OTEL.

And since I’ve used open source heavily for 9 years, it seemed fair to finally ship something that might be useful back to the community instead of just complaining about tools in private chats.

---

I enjoy daily.dev, but most of my daily work is hidden inside company VPNs and internal repos. This project finally felt like something worth talking about:

- It came from an actual, annoying real-world problem.
- Existing tools got us close, but not all the way.
- The solution itself felt general enough that other teams could benefit.

So:

- If you’ve ever been asked “Can we get that SaaS’ data into Grafana?” and your first thought was to write yet another noscript… this is for you.
- If you’re moving towards OpenTelemetry and want business/process metrics next to infra metrics and traces, not on some separate island, this is for you.
- If you live in an environment where "just give us metrics from SaaS X into Y" is a weekly request: same story.

The repo and documentation links:
👉 [API2OTEL(otel-api-scraper)](https://github.com/aakashH242/otel-api-scraper)
📜 [Documentation](https://aakashh242.github.io/otel-api-scraper/)

It’s early, but I’ll be actively maintaining it and shaping it based on feedback. Try it against one of your APIs. Open issues if something feels off (missing auth type, weird edge case, missing features). And yes, if it saves you a night of "just one more noscript", a ⭐ would genuinely be very motivating.

This is my first post on reddit, so I’m also curious: if you’ve solved similar "API → telemetry" problems in other ways, I’d love to hear how you approached it.

https://redd.it/1panyv6
@r_devops

Getting started with devops/devsecops

I have been a pentester for 7 years but my current role demands more from me. I am thinking of learning devops and devsecops but I need a roadmap to get started. Would really appreciate if someone can recommend some places to get started. I am thinking of buying of kodekloud subnoscription.

https://redd.it/1papm97
@r_devops

An entire sprint got stuck because of one obvious detail my ADHD brain just ignored

I don’t know if anyone else here deals with this, but yesterday I lost almost 5 hours on a bug that made absolutely no sense.
Everything was correct. Logic fine. Structures fine. Tests failing for no explainable reason.

I was already in that panic mode like:

> “How have I been working in this field for years and still fall for stuff like this?”

After running in circles, getting up, coming back, opening 20 tabs, closing 19, focusing for 15 minutes and losing focus for the next 45… I found out the issue was literally a configuration setting I forgot to disable

It wasn’t the code.
It wasn’t the logic.
It wasn’t the test.
It was just my brain deciding to ignore the one detail that would’ve solved everything in 30 seconds.

I like to think developers with ADHD don’t have an intelligence problem — they have an organization problem.
We see 50 things at once, except the thing that actually matters.

The “good” part is that once I solved it, I jumped into hyperfocus and finished the rest of the ticket in record time.
The bad part is that the mental energy cost feels like it’s doubled.

If any of you work as a dev with ADHD, how do you deal with those “blind spots” that only show up hours later?
Seriously, I’d love to know if this is just me or if it comes with the package.


https://redd.it/1pavs9d
@r_devops

From SaaS Black Boxes to OpenTelemetry

> **TL;DR:** We needed metrics and logs from SaaS (Workday etc.) and internal APIs in the same observability stack as app/infra, but existing tools (Infinity, json_exporter, Telegraf) always broke for some part of the use-case. So I built [otel-api-scraper](https://github.com/aakashh242/otel-api-scraper) - an async, config-driven service that turns arbitrary HTTP APIs into OpenTelemetry metrics and logs (with auth, range scrapes, filtering, dedupe, and JSON→metric mappings). If "just one more cron noscript" is your current observability strategy for SaaS APIs, this is meant to replace that. [Docs](https://aakashh242.github.io/otel-api-scraper/)

I’ve been lurking on tech communities in reddit for a while thinking, “One day I’ll post something.”
Then every day I’d open the feed, read cool stuff, and close the tab like a responsible procrastinator.
That changed during an observability project that got...interesting. Recently I ran into an observability problem that was simple on paper but got annoying the more you dug deeper into it. This is a story of how we tackled the challenge.

---

So... hi. I’m a developer of ~9 years, heavy open-source consumer and an occasional contributor.

**The pain:** Business cares about signals you can’t see yet and the observability gap nobody markets to you

Picture this:

- The business wants data from SaaS systems (our case Workday, but it could be anything: ServiceNow, Jira, GitHub...) in the same, centralized Grafana where they watch app metrics.
- Support and maintenance teams want connected views: app metrics and logs, infra metrics and logs, and "business signals" (jobs, approvals, integrations) from SaaS and internal tools, all on one screen.
- Most of those systems don’t give you a database, don’t give you Prometheus, don’t give you anything except REST APIs with varying auth schemes.

The requirement is simple to say and annoying to solve:
> We want to move away from disconnected dashboards in 5 SaaS products and see everything as connected, contextual dashboards in one place.
Sounds reasonable.

Until you look at what the SaaS actually gives you.

**The reality**

What we actually had:

- No direct access to underlying data.
- No DB, no warehouse, nothing. Just REST APIs.
- APIs with weird semantics.
- Some endpoints require a time range (start/end) or “give me last N hours”. If you don’t pass it, you get either no data or cryptic errors. Different APIs, different conventions.
- Disparate auth strategies.
Basic auth here, API key there, sometimes OAuth, sometimes Azure AD service principals.

We also looked at what exists in the opensource space but could not find a single tool to cover the entire range of our use-cases - they would fall short for some use-case or the other.

- You can configure Grafana’s [Infinity data source](https://github.com/grafana/grafana-infinity-datasource) to hit HTTP APIs... but it doesn’t persist. It just runs live queries. You can’t easily look back at historical trends for those APIs unless you like screenshots or CSVs.
- Prometheus has [json_exporter](https://github.com/catawiki/json_exporter), which is nice until you want anything beyond simple header-based auth and you realize you’ve basically locked yourself into a Prometheus-centric stack.
- Telegraf has an [HTTP input plugin](https://docs.influxdata.com/telegraf/v1/input-plugins/http/) and it seemed best suited for most of our use-cases but it lacks the ability to scrape APIs that require time ranges.
- Neither of them emit log - one of the prime use-cases: capture logs of jobs that ran in a SaaS system

**Harsh truth:** For our use-case, nothing fit the full range of needs without either duct-taping noscripts around them or accepting “half observability” and pretending it’s fine.

---

**The "let’s not maintain 15 random noscripts" moment**

The obvious quick fix was:

> "Just write some Python noscripts, curl the APIs, transform the data, push metrics somewhere. Cron it. Done."

We did that in the past. It works... until:

- Nobody remembers how each

noscript works.
- One noscript silently breaks on an auth change and nobody notices until business asks “Where did our metrics go?”
- You try to onboard another system and end up copy-pasting a half-broken noscript and adding hack after hack.

At some point I realized we were about to recreate the same mess again: a partial mix of existing tools (json_exporter / Telegraf / Infinity) + homegrown noscripts to fill the gaps. Dual stack, dual pain. So instead of gluing half-solutions together and pretending it was "good enough", I decided to build one generic, config-driven bridge:

> Any API → configurable scrape → OpenTelemetry metrics & logs.

We called the internal prototype `api-scraper`.

The idea was pretty simple:

- Treat HTTP APIs as just another telemetry source.
- Make the thing config-driven, not hardcoded per SaaS.
- Support multiple auth types properly (basic, API key, OAuth, Azure AD).
- Handle range scrapes, time formats, and historical backfills.
- Convert responses into OTEL metrics and logs, so we can stay stack-agnostic.
- Emit logs if users choose

It's not revolutionary. It’s a boring async Python process that does the plumbing work nobody wants to hand-roll for the nth time.

---

**Why open-source a rewrite?**

Fast-forward a bit: I also started contributing to open source more seriously. At some point the thought was:

> We clearly aren’t the only ones suffering from 'SaaS API but no metrics' syndrome. Why keep this idea locked in?

So I decided to build a clean-room, enhanced, open-source rewrite of the concept - a general-purpose otel-api-scraper that:

- Runs as an async Python service.
- Reads a YAML config describing:
- Sources (APIs),
- Auth,
- Time windows (range/instant),
- How to turn records into metrics/logs.
- Emits OTLP metrics and logs to your existing OTEL collector - you keep your collector; this just feeds it.

I’ve added things that our internal version either didn’t have:

- A proper configuration model instead of “config-by-accident”.
- Flexible mapping from JSON → gauges/counters/histograms.
- Filtering and deduping so you keep only what you want.
- Delta detection via fingerprints so overlapping data between scrapes don’t spam duplicates.
- A focus on keeping it stack-agnostic: OTEL out, it can plug in to your existing stack if you use OTEL.

And since I’ve used open source heavily for 9 years, it seemed fair to finally ship something that might be useful back to the community instead of just complaining about tools in private chats.

---

I enjoy daily.dev, but most of my daily work is hidden inside company VPNs and internal repos. This project finally felt like something worth talking about:

- It came from an actual, annoying real-world problem.
- Existing tools got us close, but not all the way.
- The solution itself felt general enough that other teams could benefit.

So:

- If you’ve ever been asked “Can we get that SaaS’ data into Grafana?” and your first thought was to write yet another noscript… this is for you.
- If you’re moving towards OpenTelemetry and want business/process metrics next to infra metrics and traces, not on some separate island, this is for you.
- If you live in an environment where "just give us metrics from SaaS X into Y" is a weekly request: same story.

The repo and documentation links:
👉 [API2OTEL(otel-api-scraper)](https://github.com/aakashH242/otel-api-scraper)
📜 [Documentation](https://aakashh242.github.io/otel-api-scraper/)

It’s early, but I’ll be actively maintaining it and shaping it based on feedback. Try it against one of your APIs. Open issues if something feels off (missing auth type, weird edge case, missing features). And yes, if it saves you a night of "just one more noscript", a ⭐ would genuinely be very motivating.

This is my first post on reddit, so I’m also curious: if you’ve solved similar "API → telemetry" problems in other ways, I’d love to hear how you approached it.

https://redd.it/1panxw9
@r_devops

QA Engineer looking to transition into DevOps — advice?

Hello there! :)

I’m currently a QA Engineer and I’m looking to transition into DevOps, both for the challenge and the better pay.

For those who’ve made this transition, what tools should I focus on learning, and what kind of self-projects would be valuable for building a portfolio? Any other tips are very welcome.

For context, I work with embedded systems and my stack is Python, Robot Framework, and Jenkins (as a user, not maintaining the pipelines).

https://redd.it/1pb06e6
@r_devops

I'm building a tool to simplify internal DNS and I need your feedback

Hello community!!

I'm a developer/devops engineer who's fed up with the complexity surrounding internal DNS for development and staging environments. As a side project, I'm building a multi-tenant private DNS service with an API.

The idea is for it to be as simple to use as /etc/hosts, but with access control, logging, and scalability for teams. It's not ready for launch yet, so I want to make sure I'm addressing the right issues.

Based on my experience, I think it would help with:
Avoiding reliance on public DNS servers or complex Consul configurations.
Having a clear audit trail of who resolved or modified what.
Isolating domains by project/team.

My question for you is: Does this resonate with any of your problems? What else drives you crazy about DNS management/service discovery that I should consider?

If the concept has potential, I'd love to keep you updated. Any feedback is welcome!

https://redd.it/1pb2neo
@r_devops

CKA certification Cybermonday deals

Linux foundation Is offering regular discount on Cyber Monday deals.

CKA original price: 445$
Discounted price: 223$

CKAD original price: 445$
Discounted price: 223$

Coupon code: CW25CC

https://training.linuxfoundation.org/cyber-week-2025/

https://redd.it/1pb54ir
@r_devops

Our developers are moving faster, maybe too fast for our release model

Lately our release pace went crazy.
We used to ship twice a day. Now it’s ten… before anyone finishes their first coffee.

And it’s not magic. It’s the copilots/cursor/windsurf doing quiet fixes, bumping versions, patching stuff in the background. Honestly, at this point I’m not sure whether to thank the dev… or their AI agent.
(Yeah, classic Monday thoughts. Ignore me.)

never mind... anyway...
The problem is figuring out what’s actually in each release.
We tag Docker images with timestamps, but honestly, with this speed, the tags tell me nothing.
Sometimes I look at two images from the same morning and I have no idea what changed or why.

Are you seeing this too?
How do you keep track when dev + AI ship faster than you can understand the lineage of a single binary?

Because right now, I feel like the releases make sense to everyone except… me.

https://redd.it/1pb7dxv
@r_devops