Forem

Better Loading Buttons in Angular Material v22

Brian Treese — Fri, 22 May 2026 07:00:00 +0000

Angular Material v22 adds a small but surprisingly useful improvement to buttons: built-in progress indicator support. Instead of manually swapping button text with a spinner and dealing with layout jumpiness, we can let the Material button directive manage the loading UI for us. In this post, I'll show you the old manual approach, why it creates a small UX issue, and how Angular Material v22 cleans it up.

A Simple Example

Let's start with a simple reports page:

We have a list of reports, and each report has a "Download" button using the matButton directive:

<section>
  <ul class="report-list">
    @for (report of reports(); track report.id) {
      <li class="report-row">
        <div class="report-info">
          <span class="report-name">{% raw %}{{ report.name }}{% endraw %}</span>
          <span class="report-meta">{% raw %}{{ report.date }} · {{ report.size }}{% endraw %}</span>
        </div>

        <button
          matButton="outlined"
          [disabled]="downloadingId() !== null"
          (click)="download(report)">
          Download
        </button>
      </li>
    }
  </ul>
</section>

Nothing unusual here.

But the loading UI is where this usually gets a little clunky.

The Old Way: Swap the Label for a Spinner

Before this new Angular Material v22 feature, a common approach was to conditionally replace the button label with a spinner.

First, we need to import the progress spinner in our component:

import { MatProgressSpinner } from '@angular/material/progress-spinner';

@Component({
  selector: 'app-report-list',
  templateUrl: './report-list.component.html',
  styleUrl: './report-list.component.scss',
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [MatButton, MatProgressSpinner],
})
export class ReportListComponent {
  // ...
}

Then we can update the button template to include the progress spinner conditionally when the report is downloading and the label when it isn't:

<button
  matButton="outlined"
  [disabled]="downloadingId() !== null"
  (click)="download(report)">
  @if (downloadingId() === report.id) {
    <mat-progress-spinner
      mode="indeterminate"
      [diameter]="20"
      aria-label="Downloading"
    />
  } @else {
    Download
  }
</button>

Since this download doesn't expose a real percentage, mode="indeterminate" is the right fit here.

The diameter keeps the spinner small enough to fit inside the button, and the aria-label gives assistive technologies meaningful loading-state text since the visible label is being replaced.

And this works fine:

When the report is downloading, we show a spinner.

When it isn't, we show the label.

But there's still a UX issue.

The button shrinks when the label disappears and only the spinner remains.

That's because we're swapping the button's content entirely.

The text has one width, the spinner has another, and the button resizes to fit whatever is currently rendered.

It's not broken, but it feels a little janky.

And we had to write the conditional content logic ourselves.

If you're serious about leveling up your Angular skills, there's now an official certification path worth exploring.

Built with input from Google Developer Experts, it focuses on real-world Angular knowledge.

👉 Details here: https://bit.ly/4tfqleD

The Angular Material v22 Way: Use `showProgress` and `progressIndicator`

Angular Material v22 gives us another option.

Instead of swapping the label and spinner manually, both can live inside the button at the same time:

<button
  matButton="outlined"
  [showProgress]="downloadingId() === report.id"
  [disabled]="downloadingId() !== null"
  (click)="download(report)">
  <mat-progress-spinner
    progressIndicator
    mode="indeterminate"
    [diameter]="20"
    aria-label="Downloading"
  />
  Download
</button>

There are two important pieces here.

First, the button gets the showProgress input, which is new in Angular Material v22:

[showProgress]="downloadingId() === report.id"

This tells the matButton directive when the progress UI should be shown.

In this case, we only want progress on the button for the report currently being downloaded.

Then, the spinner gets the progressIndicator attribute:

<mat-progress-spinner progressIndicator />

This marks the spinner as the button's projected progress indicator.

So instead of us writing an @if block to decide what appears, Angular Material controls that progress indicator slot for us.

Why This Feels Better

The important detail is that the normal button content stays in the layout, even when the progress indicator is visible.

So the button still knows how wide the "Download" label is, even while the spinner is being displayed.

That means we avoid the width jump caused by replacing the content completely.

The end result is a loading button that feels stable instead of jumpy.

This Does Not Have to Be a Material Spinner

One nice part of this API is that progressIndicator is a projection slot.

That means the projected content doesn't have to be mat-progress-spinner specifically.

You could use a custom loading element if that fits your design system better.

The main thing is to make sure the progress indicator still communicates meaningful loading-state information, especially when the visible button label is hidden or visually replaced.

Cleaner Loading Buttons in Angular Material

This is one of those Angular Material updates that isn't huge, but it's immediately useful.

The old approach works, but it usually means manually swapping content and accepting small layout issues.

With showProgress and progressIndicator, Angular Material gives us a built-in pattern for loading buttons that feels more polished with less template logic.

Want to Go Deeper With Modern Angular?

Angular's newest APIs are changing the way we build.

If you're ready to go deeper with one of the biggest shifts in modern Angular, my Signal Forms course will help you get comfortable with the new forms model.

You can access it either directly or through YouTube membership, whichever works best for you:

👉 Buy the course

👉 Get it with YouTube membership

Additional Resources

DevOps on AWS: Accelerating Software Delivery Through Automation

Marvelous Olaoluwa — Fri, 22 May 2026 06:56:54 +0000

Modern software development requires speed, reliability, and continuous improvement. DevOps has emerged as one of the most important methodologies helping organizations automate development, testing, deployment, and monitoring processes.

AWS provides a complete ecosystem of DevOps tools that help engineering teams build CI/CD pipelines and automate cloud infrastructure efficiently.

What Is DevOps?

DevOps combines software development and IT operations to improve collaboration and accelerate software delivery.

Goals include:
Faster releases
Automated deployments
Improved reliability
Continuous testing
Infrastructure automation

DevOps reduces manual processes while improving software quality.

AWS DevOps Services

AWS CodePipeline

CodePipeline automates software release workflows.

Benefits:
Faster deployments
Automated testing
Continuous integration
Reduced human errors

AWS CodeBuild

CodeBuild compiles source code and executes automated tests.

Common uses:
Application builds
Automated testing
Package generation

AWS CloudFormation

CloudFormation allows infrastructure to be managed as code.

Advantages:
Repeatable infrastructure deployments
Version-controlled configurations
Faster environment setup

Infrastructure automation improves operational consistency.

Benefits of DevOps on AWS
Faster Time-to-Market

Teams can release updates more frequently.

Improved Collaboration

Development and operations teams work more efficiently together.

Better Reliability

Automation reduces deployment failures and downtime.

Scalability

Cloud-native DevOps workflows support growing applications easily.

Final Thoughts

DevOps practices combined with AWS cloud services enable organizations to build faster, deploy smarter, and scale more efficiently.

As digital transformation accelerates globally, DevOps skills and cloud automation will continue becoming essential for modern technology teams

📚 The Book Pattern: Progressive Disclosure for AI Agents

idavidov13 — Fri, 22 May 2026 06:56:08 +0000

You are standing in a bookshop holding a technical book you might buy. You have about thirty seconds before you decide. So you do three things.

You read the back cover to see what the book promises. You flip to the introduction to check the author's rules and how they think. You scan the table of contents to see if the parts you actually care about are in there.

If those three pass the test, you pay for it.

Later, when you sit down to read, you study the chapter that matches the problem you're solving. And later still, when you are deep in your own work, you flip back to the appendix to grab the exact example you need.

Your AI agent should read your project the exact same way.

In the previous article we sketched the three-layer model that the scaffold runs on. This article gives you the mental model that makes it stick, and the industry name for the architecture you are quietly already using - progressive disclosure.

📚 The Anatomy of a Technical Book

Open any well-written Packt, Manning, O'Reilly, or Pragmatic Bookshelf title and you will find the same three parts, every single time.

The back cover is the promise. Two paragraphs that tell you who the book is for, what it covers, and what you will be able to do after reading it. It exists so a reader can decide in thirty seconds whether the book belongs in their hands.

The preface is the author's constitution. It states the assumptions, the prerequisites, the conventions, the things you will be expected to know, and the things the book explicitly refuses to cover. It is what makes the author's voice consistent across two hundred pages.

The table of contents is the map. A flat list of chapter titles, ordered, scannable, with page numbers. It exists so that a reader who already trusts the book can find the exact part they need without re-reading everything that came before.

Three parts. Each loaded into the reader's mind at a different moment. Each designed for a different decision.

🤖 The Orchestrator File Is the Cover, Preface, and Table of Contents

Now look at the CLAUDE.md file at the root of the Playwright scaffold. It has the same three parts.

The Role section is the back cover.

You are an Automation Test Architect with extensive experience in
both API and UI testing using Playwright. Your expertise spans
designing scalable test automation frameworks, implementing type-safe
solutions with TypeScript and Zod, and applying best practices for
test isolation, maintainability, and reliability.

In about fifty words the agent learns who it is, what kind of project this is, and what it is expected to be good at. The agent reads this once, at the start of every session.

The Constitution is the preface. The scaffold splits it into three tiers borrowed from how legal systems work:

### MUST (Mandatory)

| Dependency Injection | Use fixtures, never `new PageObject(page)` |
| Selectors | getByRole > getByLabel > getByPlaceholder > getByText > getByTestId |
| Type Safety | Use Zod schemas, no `any` type |
| Strict Schemas | Always `z.strictObject()`, never `z.object()` |

### SHOULD (Recommended)

| Data Generation | Use Faker via factories for happy-path data |
| Test Isolation | Independent tests, use beforeEach not shared state |

### WON'T (Forbidden)

| No XPath | Never use XPath selectors |
| No Hard Waits | Never use page.waitForTimeout() |
| No `any` | Never use TypeScript's any type |

If you covered the CLAUDE.md article earlier in this series, this should look familiar. What's new here is the framing. These three tiers are the author's voice. Every time the agent hesitates, it consults this preface to know what kind of book it is reading.

The Skills Index is the table of contents.

| Skill         | Read When Working On         |
| ------------- | ---------------------------- |
| selectors     | pages/\*\*                   |
| page-objects  | pages/\*\*                   |
| fixtures      | fixtures/**, tests/**        |
| api-testing   | fixtures/api/\*\*, tests/api |
| data-strategy | test-data/\*\*               |
| debugging     | When a test fails            |

The agent does not read every skill on startup. It reads the index, and only the index. When a task lands, it looks at the table of contents and decides which chapter to open.

That is exactly the bookshop scan. Promise, constitution, map. Thirty seconds of reading and the agent knows whether your project belongs in its hands.

📖 Every Skill Is a Chapter

A great chapter does three things. It tells you why the rule exists, how to apply it step by step, and what the right and wrong code looks like. Take the selectors skill from the scaffold as a worked example.

It opens with a frontmatter description that acts as a chapter abstract:

---
name: selectors
description: Selector strategy, exploration-first workflow, locator
  priority order (getByRole > getByLabel > getByPlaceholder > getByText
  > getByTestId), and feedback/validation-message selector rules for
  Playwright page objects. Use when creating page objects, writing or
  updating locators, generating UI tests...
---

The description is what the agent reads first, before it commits to opening the chapter at all. The body opens with a WHY section called "Critical" that names the principles:

- Selector priority order is mandatory: getByRole > getByLabel > ...
- NEVER use XPath
- Exploration with playwright-cli is mandatory before writing selectors
- Every page object covering forms or CRUD must include feedback selectors

Then a HOW section breaks the work into phases:

### Phase 1: Open and authenticate

### Phase 2: Explore like a user

### Phase 3: Plan test coverage

### Phase 4: Generate selectors

Then a WHAT section shows the actual code, correct and forbidden side by side:

// ✅ Correct
page.getByRole("button", { name: "Submit" });
page.getByLabel("Email");
page.getByText(Messages.LOGIN_ERROR);

// ❌ Forbidden
page.locator('//div[@id="test"]');
page.locator('xpath=//button[text()="Submit"]');
page.locator(".btn-primary");

And finally a See Also section that links to the appendix and to sibling chapters:

## See Also

- `page-objects` skill - POM class structure
- `playwright-cli` skill - the exploration tool
- `references/feedback-selectors-example.md` - full code pattern
- `references/troubleshooting.md` - common pitfalls

That is a chapter. Self-contained, focused on one topic, structured the way a reader's brain actually wants to consume it. The Skills article covered the what of skill files. The book pattern explains the why of the structure inside them.

📎 The References Folder Is the Appendix

Look at the selectors/ folder on disk and you find more than just SKILL.md.

.claude/skills/selectors/
├── SKILL.md                                      ← the chapter
└── references/
    ├── examples.md                               ← worked code examples
    ├── feedback-selectors-example.md             ← deep page-object pattern
    └── troubleshooting.md                        ← common pitfalls and fixes

The chapter mentions these files but does not contain them. They are the appendix. A reader uses them only when they are deep in the actual work, the same way you flip to the back of a textbook to grab a worked example or a lookup table.

Some skills carry heavier appendices. The skill-creator skill, for example, ships with executables alongside its references:

.claude/skills/skill-creator/
├── SKILL.md
├── agents/                  ← subagent definitions
├── scripts/                 ← runnable Python tools
├── eval-viewer/             ← HTML report generator
└── references/              ← schemas and Anthropic resources

The crucial property of the appendix is that the agent does not pay for it until it asks for it. The chapter says "for the full code pattern, see references/feedback-selectors-example.md". The agent only reads that file if the current task requires it. The token cost is zero until the moment of need.

🏷️ The Industry Name: Progressive Disclosure

The pre-purchase scan, the chapter, and the appendix are not just an analogy. They are the three levels of an architecture pattern that the AI tooling industry has now formally converged on.

Anthropic released the SKILL.md format in December 2025, calling it progressive disclosure. OpenAI, Google, GitHub, and Cursor adopted variants of it within weeks. By early 2026 it was the default architecture for any production agent that needs to scale beyond a handful of rules. The State of Context Engineering 2026 write-up captures the shift in one sentence: "discovery first, activation when relevant, execution only during the task."

The three levels map cleanly onto the bookshop journey.

Level	What loads	When	Token cost	Reader's moment
L1	Skill `name` and `description` from YAML frontmatter	At session start, for every skill	~100 tokens per skill	The thirty-second pre-purchase scan
L2	The full `SKILL.md` body	When the agent decides the skill is relevant	Under 5,000 tokens	Sitting down to study one chapter
L3	Files in `references/`, `scripts/`, `assets/`	When the chapter explicitly points to them	Unlimited	Flipping to the appendix mid-task

The Anthropic Claude Code documentation is the canonical reference. The four-mode Diátaxis framework is the closest cousin in the technical writing world and is worth reading if you are designing your own skills from scratch.

⚖️ Why It Beats the All-in-One Prompt

A reasonable question at this point is: why not stuff every rule and every example into one giant system prompt? The three loading strategies look like this side by side.

Strategy	Upfront cost	Discoverability	Capacity
Eager loading	Massive. Tens of thousands of tokens before the user types a word	Perfect. The agent knows everything	Capped by the context window
Lazy loading	Zero. Nothing is loaded	Poor. The agent does not know what exists	Theoretically unlimited, practically unusable
Progressive disclosure	Small. Only metadata is loaded	Good. Semantic index drives discovery	Effectively unlimited

Eager loading is the binder you hand a new hire on day one. They might be impressed. They will not actually read it. By the time they reach page two hundred they will have forgotten page two.

AI agents behave the same way. Long instruction files cause context rot, the documented phenomenon where rules near the bottom of a prompt get applied less consistently than rules near the top.

Lazy loading is the opposite failure mode. Nothing is loaded, so the agent has no idea your project has rules at all. It defaults to its own habits, which are not yours.

Progressive disclosure is the bookshop. Cheap on day one, deep when you need it, infinite on the shelf. This is the property that lets the scaffold ship sixteen skills today and another forty next year without the agent slowing down or losing accuracy.

✍️ Writing Your Orchestration Like an Author

Here is how to apply the pattern to your own project. Treat it as a writing brief, not a coding task.

For the orchestrator file (CLAUDE.md, .cursor/rules/, .github/copilot-instructions.md):

The back cover. One short paragraph naming the agent's role and the project's domain. Resist the urge to over-explain.
The preface. A three-tier constitution. MUST for non-negotiables, SHOULD for recommended defaults, WON'T for hard refusals. Write each rule in one line.
The table of contents. A single table listing every skill, when to read it, and what it covers. Nothing else lives in this file. Detail goes downstream.

For each skill chapter (.claude/skills/{name}/SKILL.md):

The frontmatter description. Two to three sentences that name the topic, list the triggering keywords, and pre-empt the wrong skill from loading. This is the part the agent reads first.
WHY. A short "Critical" or "Principles" section that names the rules and explains the reasoning behind them.
HOW. Numbered phases or steps. Each phase ends with a concrete outcome.
WHAT. Code examples, labelled with ✅ and ❌. Tables for decision trees. A "See Also" section pointing to the appendix.

For each appendix (references/, scripts/, assets/):

Things the chapter would suffer from including inline. Long worked examples, troubleshooting tables, runnable scripts, deep edge cases.
Always referenced by name from the chapter. An appendix the chapter never mentions might as well not exist.

If you are starting from scratch, the Playwright scaffold's `CLAUDE.md` is a working template. Strip out the parts that do not apply to your stack and replace them with your own rules.

🧭 The Bookshelf Mental Model

If a colleague asked you "where in this book does the rule about X live?", you should be able to answer in under five seconds. If you cannot, the book is poorly organized, not your colleague.

Apply the same test to your agent. If your agent struggles to find which rule applies to a piece of code, the failure is almost never the agent. It is the bookshelf.

Progressive disclosure works because it respects how readers actually read. A good orchestration respects how agents actually load.

The structure you choose tomorrow is the structure your agent will live with on every task next month. Write it like an author, not like a checklist.

🙏🏻 Thank you for reading! The book pattern is the spine of every well-behaved AI agent. The agent reads the cover, opens the chapter, flips to the appendix. Your job is to make those three moments easy. In the next article we will look at how to add a new chapter to your agent's bookshelf without breaking the ones already on it.

You can find the Public README.md file for the scaffold on GitHub: Playwright Scaffold

You can get access to the private GitHub repository here: Get Access

Learn MERN Stack by Building and Deploying a Real FullStack Application — Live 2-Day Webinar

Yogesh Chavan — Fri, 22 May 2026 06:55:52 +0000

If you've been putting off learning fullstack development, this weekend is your chance to finally make it happen.

I'm hosting a live, hands-on 2-Day MERN Stack Webinar where we'll build and deploy a complete fullstack application from scratch — no slides, no fluff, just real code.

📅 Dates & Timings

Day	Date	Time
Day 1	23rd May (Friday)	6:00 PM – 9:00 PM IST
Day 2	24th May (Saturday)	6:00 PM – 9:00 PM IST

Platform: Zoom (Live)
Recording: Yes — all registered participants get access to the recording

What You'll Build

By the end of this 2-day webinar, you'll have a fully deployed fullstack application — built with the MERN stack (MongoDB, Express.js, React, Node.js) — running live on the internet.

📌 Day-by-Day Breakdown

🔥 Day 1 — React Fundamentals (Frontend)

We start from the very beginning and build up to a complete React frontend:

Understand the core concepts of React from scratch
Build UI components the right way
Manage state and structure your project effectively
Create a real, working frontend application

No prior React experience required. We'll cover every concept clearly.

🔥 Day 2 — Backend + Integration + Deployment

Once the frontend is ready, we build the backend and connect everything:

Learn Node.js and Express.js fundamentals
Build REST APIs from scratch
Connect your React frontend to the backend
Deploy the fullstack application to production

By the end of Day 2, your app will be live and accessible to anyone on the internet.

🎯 Who Is This For?

This webinar is designed for:

Beginners who want to get started with React
Beginners who are just starting with MERN stack development
Developers who want hands-on, practical experience over theory
Students preparing for real-world projects or job interviews
Anyone who wants to understand how frontend and backend connect in a real application

If you've only worked with one side of the stack — or haven't started at all — this is the right starting point.

✅ Why This Webinar Is Different

Most tutorials teach you concepts. This webinar teaches you by doing.

Hands-on coding throughout — no PowerPoint, no passive watching
Real project — something you can add to your portfolio
Live session — ask questions, get answers in real time
Recording included — can't attend live? You still get the full recording plus the complete application source code

⚠️ Limited Seats — Register Now

Seats are limited and it's first-come, first-served. If you can't make it live, register anyway — you'll get the recording and the full source code of the application we build.

👉 Register Here

If you've been postponing learning fullstack development, this is your sign to start. See you this weekend. 🚀

About Me

I'm a freelancer, mentor, and full-stack developer with 12+ years of experience, working primarily with React, Next.js, and Node.js.

Alongside building real-world web applications, I'm also an Industry/Corporate Trainer, training developers and teams in modern JavaScript, Next.js, and MERN stack technologies with a focus on practical, production-ready skills.

I've also created various courses with 3000+ students enrolled.

My Portfolio: https://yogeshchavan.dev/

The Most Concerning AI Risk of 2026

Sacha Greif — Fri, 22 May 2026 06:49:44 +0000

You might have seen the State of JavaScript survey before, but did you know there's now a State of Web Dev AI survey as well?

I just published the results, and the data revealed quite a few interesting trends.

The AI Takeover is Here

A few years ago, NFTs (remember them?) were all you'd hear about. But that technology had very little practical use, and once the hype wore out it wasn't long before the world more or less forgot about it.

It seemed at first like AI might follow the same path, with many dismissing LLMs as "fancy autocorrect" and predicting an eventual return to the statu quo.

But it should be clear by now that AI is anything but a flash in the pan, and the survey data confirms it.

For example, the proportion of code generated by AI tools has jumped from 28% in 2025 to 54% this year:

It's especially striking to see that the segment of respondents who use AI to produce nearly all of their code is now the single largest bucket–when it was the second smallest last year!

The frequency at which developers reach for AI tools has also increased drastically, with developers reporting they use AI “constantly” going from 11% to 21%.

All those signs point in the same direction: not only is AI usage increasing, but it's doing so at a speed rarely seen before when it comes to adopting new workflows.

The Claude Code Connection

So what's behind this shift? While it's impossible to prove any causal link with survey data alone, one factor worth considering is the growing impact of Claude Code, and agentic coding in general.

Claude Code is the most-loved coding assistant:

And in terms of raw usage, Claude Code is second behind GitHub Copilot with 62.9% of respondents having used it–while OpenAi Codex comes in a distant third with only 34.5%.

But more crucially, both Claude and Claude Code top the ranks of tools developers are actually paying for:

Anthropic likes to position itself as the underdog fighting against OpenAI's dominance, but these results indicate that when it comes to developers at least, OpenAI is the one fighting an uphill battle.

A Threat to Developers

So it looks like developers are embracing their new AI overlords en masse, and the few lone voices warning us about Skynet can probably be dismissed as delusional crackpots, right?

Well… not so fast. While it's true that developers tend to be more concerned with the next line of codes than with doomsday predictions, it doesn't mean they're blind to the very real issues created by this sudden AI surge.

For starters, developers are quite conscious of the fact that their jobs may now be threatened by the very machines they helped train, as is becoming apparent in the recent Meta layoffs:

And as a commenter astutely pointed out, even if AI can't do your job, all you need to be fired is that your boss thinks it can.

But while job loss tops the list of AI issues developers worry about, it isn't the only one by any means:

Military use of AI scored quite high as well, which makes sense since the survey was filled out at a time when the Pentagon's use of AI was in the news.

And of course, AI's environmental impact is another very real worry, with the construction and operation of new datacenters putting extra stress on an already-struggling planet.

Preparing for an AI Future

Taken together, these survey results point a nuanced picture: yes, developers have embraced AI and its productivity gains–but they're also quite aware of the risks and issues presented by AI adoption, and many of them aren't quite convinced that the juice is worth the squeeze.

Believe it or not, this is only a tiny fraction of the data collected, and I encourage you to check out the full survey results to get a broader picture of the AI developer ecosystem in 2026, as well as read the conclusion by the one and only Primeagen.

And hey–if you'd like to brush up on your CSS knowledge one last time before Claude Code takes your job, why not go fill out this year's State of CSS survey and see how many new CSS features you know?

Chatbots GPT et conformité au RGPD : comment les entreprises françaises abordent l’adoption de l’IA

Chloé Dubois — Fri, 22 May 2026 06:47:51 +0000

Lorsque les entreprises introduisent des chatbots basés sur l’IA, la conversation commence rarement par les capacités du produit. Elle commence par une question sur laquelle les équipes juridiques travaillent depuis 2018 : qui est responsable du traitement des données et quelles sont exactement ses obligations.
La plupart des déploiements commencent dans le support client. C’est là que le retour sur investissement est le plus évident et que le volume de demandes répétitives rend l’automatisation facile à justifier. Mais au moment où un chatbot se connecte à un CRM ou accède à l’historique des tickets, quelque chose change. Il cesse d’être une simple fonctionnalité produit pour devenir un processeur de données, et cette requalification fait intervenir un tout autre ensemble d’acteurs. Les achats veulent savoir ce que prévoit le contrat. Les équipes juridiques veulent savoir où vont les données. Le délégué à la protection des données veut des réponses précises sur ces deux sujets, par écrit, avant toute mise en production.
Aucune de ces équipes ne travaille rapidement, et c’est normal.
Comprendre pourquoi cela se produit, et ce que cela implique pour les délais de déploiement et les choix de plateformes, est précisément l’objectif de cet article.

Pourquoi les chatbots GPT sont considérés comme des systèmes opérationnels

L’hypothèse la plus répandue est qu’un chatbot est un outil frontal. Il répond aux questions, réduit le volume des tickets et reste à la périphérie de l’expérience client. En pratique, il ne reste presque jamais à cet endroit.
Dès qu’un chatbot se connecte à des données clients en direct, historiques de commandes, dossiers de comptes, interactions précédentes, il devient une partie intégrante de la couche opérationnelle. Il lit, traite et parfois réécrit des informations dans les mêmes systèmes que ceux sur lesquels le reste de l’entreprise fonctionne. À partir de ce moment, la question n’est plus de savoir si l’outil fonctionne. La question devient : à quelles données a-t-il accès, que conserve-t-il, et qui est responsable si quelque chose tourne mal.
C’est ce changement qui surprend de nombreux projets. Une preuve de concept fonctionnant avec des données fictives ressemble à une fonctionnalité produit. Le même système connecté à des données de production se comporte comme une infrastructure, et il est traité comme telle. Le processus de validation interne change, les parties prenantes changent, et les délais évoluent avec elles.

Comment le RGPD influence chaque décision autour du déploiement de l’IA

La CNIL (Commission Nationale de l’Informatique et des Libertés) est l’autorité qui donne au RGPD son poids concret en France. En 2024, elle a infligé 55 millions d’euros d’amendes. En 2025, ce chiffre a atteint 486 millions d’euros, soit environ neuf fois plus. Le volume des sanctions est resté relativement stable. Les conséquences financières, elles, ont radicalement changé.
Pour les équipes juridiques en entreprise, cette trajectoire modifie considérablement l’évaluation du risque. Un chatbot qui gère des échanges clients n’est plus seulement une décision produit. C’est une question de responsabilité qui apparaît directement sur un bilan financier.
En juillet 2025, la CNIL a publié des recommandations détaillées sur l’application du RGPD au développement des modèles d’IA, couvrant la gestion des données d’entraînement, les exigences de sécurité et les cas dans lesquels un modèle déployé constitue un traitement de données personnelles. Les entreprises qui menaient jusque-là des pilotes dans une zone réglementaire floue se sont soudainement retrouvées face à un cadre formel.
L’AI Act européen ajoute une couche supplémentaire. Il est entré en vigueur en août 2024, avec l’application des interdictions concernant les systèmes d’IA à risque inacceptable dès février 2025 et les obligations complètes pour les systèmes à haut risque attendues pour août 2026. Un chatbot qui gère des demandes standard dans le commerce de détail sera probablement considéré comme à faible risque. En revanche, un système utilisé pour des décisions de crédit, des évaluations d’assurance ou du triage médical entre dans une catégorie totalement différente, avec des exigences beaucoup plus strictes en matière de documentation, de supervision humaine et de conformité.
Pour les entreprises des secteurs financier ou de la santé, la conformité signifie désormais naviguer simultanément entre le RGPD, l’AI Act et les réglementations sectorielles propres à leur industrie.

Ce que signifie réellement la “conformité” lorsqu’une IA est utilisée en production

L’expression « chatbot conforme au RGPD » apparaît dans presque tous les discours commerciaux des fournisseurs. Dans les achats en entreprise, elle a une signification beaucoup plus précise, et quatre éléments comptent réellement lorsqu’on l’évalue sérieusement.
Le premier est un accord de traitement des données signé (Data Processing Agreement ou DPA). Tout fournisseur agissant comme sous-traitant doit en disposer avant que des données de production ne transitent dans le système. C’est un prérequis fondamental, pourtant encore absent chez certaines plateformes intermédiaires, ce qui suffit à les exclure des appels d’offres d’entreprise, indépendamment de la qualité du produit.
Le deuxième point concerne la clarté sur la conservation des données. Les entreprises doivent savoir si les conversations sont stockées, pendant combien de temps, sur quelle base légale et selon quel processus elles sont supprimées. Un chatbot qui conserve indéfiniment les journaux de conversation pour améliorer son modèle sous-jacent traite les données au-delà de leur finalité initiale. Ce n’est pas un détail technique. C’est un problème direct de conformité.
Le troisième point concerne l’utilisation des conversations clients pour l’entraînement des modèles. C’est l’une des questions auxquelles les fournisseurs répondent le plus difficilement de manière claire. La plupart des équipes juridiques et DPO des grandes entreprises l’interdisent totalement et exigent une confirmation écrite avant de valider un déploiement.
Le quatrième point concerne les contrôles d’accès et la visibilité des audits. Si un régulateur demande quelles données le chatbot a consultées et à quel moment, la réponse ne peut pas être reconstruite après coup. Les journaux d’audit doivent faire partie intégrante de l’architecture dès le départ, structurés autour des permissions déjà définies par les équipes juridiques et conformité.
La résidence des données dans l’Union européenne sous-tend l’ensemble de ces sujets. Pour les plateformes hébergées aux États-Unis, le cadre légal qui a remplacé le Privacy Shield invalidé fournit un mécanisme de transfert, mais il reste entouré d’incertitudes politiques et de préoccupations persistantes concernant l’accès potentiel des autorités américaines aux données détenues par des entreprises américaines, même lorsque les serveurs sont physiquement situés en Europe.
Les organisations bancaires, de santé et du secteur public ont largement réagi en considérant l’hébergement européen comme une exigence non négociable plutôt qu’une préférence. Les fournisseurs proposant des déploiements sur site ou des infrastructures privées européennes ont trouvé une réelle traction commerciale dans les secteurs réglementés, car ils suppriment entièrement une catégorie de risque juridique au lieu de simplement la gérer.

Meilleures plateformes de chatbots GPT

Les décisions de plateformes en entreprise se jouent rarement sur les fonctionnalités. Elles se jouent sur la solidité de la documentation de conformité et sur la capacité du système à s’intégrer dans des workflows déjà existants.

1. Intercom

Intercom est une plateforme de messagerie client conçue pour les équipes commerciales, marketing et support. Elle propose du chat en direct, de la messagerie automatisée et un support assisté par IA via son système Fin AI, permettant aux équipes de gérer les conversations sur le chat et les applications avec automatisation du routage et des résolutions.

Idéal pour

Les équipes qui disposent déjà d’opérations de support structurées y trouveront une intégration de l’IA qui s’ajoute à leur organisation existante plutôt que de les forcer à tout reconstruire autour du produit.

2. YourGPT

YourGPT est une plateforme orientée IA conçue pour créer et déployer des agents capables de gérer le support client, les ventes et les workflows opérationnels sur les sites web, applications et canaux de messagerie sans nécessiter une infrastructure d’ingénierie complète. Son constructeur no-code et son AI Studio permettent de créer des agents basés sur des workflows capables d’exécuter des tâches en plusieurs étapes, avec des intégrations vers Shopify, WordPress, Webflow, Crisp, Intercom, Stripe et Zapier. La plateforme prend en charge le texte, l’image et l’audio, ce qui la rend adaptée à des interactions plus complexes que de simples échanges textuels.

Idéal pour

Les équipes de taille moyenne à grande qui ont besoin d’automatisations structurées pour le support, la qualification commerciale ou les workflows internes, tout en souhaitant avancer rapidement sans équipe de développement dédiée.

3. Zendesk

Zendesk est une plateforme de service client construite autour de la gestion des tickets, des workflows de support et du suivi des interactions. Elle fournit des outils de gestion des dossiers, de routage automatisé, d’exploitation du support et d’analyse, avec des fonctionnalités IA couvrant la classification des tickets, les réponses suggérées et l’automatisation des processus.

Idéal pour

Sa valeur apparaît surtout dans les organisations où le support dispose de ses propres lignes hiérarchiques, procédures d’escalade et objectifs de performance. Les petites équipes y verront souvent une plateforme plus lourde que nécessaire.

4. Ada

Ada est une plateforme d’automatisation du service client basée sur l’IA, conçue pour résoudre les demandes via des workflows conversationnels. Elle interprète les requêtes des clients, génère des réponses et guide les utilisateurs vers des parcours de résolution, avec la capacité d’accéder à des informations clients provenant des systèmes backend pendant la conversation.

Idéal pour

Les environnements de support à très fort volume où une grande partie des interactions est répétitive et où l’objectif est une automatisation de bout en bout sans transférer chaque demande à un humain.

5. Crisp

Crisp est une plateforme de messagerie client qui combine chat en direct, email, automatisation chatbot et fonctionnalités CRM légères. Elle permet aux équipes de gérer les communications sur plusieurs canaux avec automatisation des questions fréquentes et routage des conversations.

Idéal pour

Les petites équipes qui souhaitent réunir chat en direct, email et automatisation dans un seul outil sans payer pour une infrastructure pensée pour des entreprises dix fois plus grandes.

6. Tidio

Tidio est une plateforme de communication client combinant chat en direct, automatisation chatbot et réponses pilotées par IA pour les sites web et boutiques en ligne. Elle inclut des workflows conversationnels automatisés, le suivi des visiteurs et des intégrations e-commerce pour gérer les demandes et les interactions commerciales.

Idéal pour

Les boutiques en ligne qui cherchent à capter les clients au bon moment du parcours d’achat, ce qui en fait une solution plus adaptée au commerce électronique qu’aux équipes gérant des files de support complexes après-vente.

Comment évaluer les chatbots GPT avant une adoption en entreprise

Les évaluations qui commencent par comparer les fonctionnalités rencontrent souvent des problèmes plus tard. Les questions liées à la gestion des données, aux contrôles d’accès et aux responsabilités des fournisseurs devraient être posées avant même qu’une plateforme soit présélectionnée, et non après la signature du contrat.
Commencez par examiner la documentation du fournisseur sur le traitement des données. Avant toute chose, il faut comprendre où vont les données de conversation, combien de temps elles sont conservées, si elles servent à entraîner les modèles et comment fonctionne leur suppression. Si un fournisseur ne peut pas répondre précisément à ces questions, cette absence de réponse est déjà une réponse.
Vérifiez les limites d’intégration avant les tests. L’accès du chatbot aux systèmes internes, dossiers CRM, tickets de support et historiques clients doit être défini et limité avant toute utilisation de données de production. La capacité d’intégration et la gouvernance des intégrations sont deux choses différentes, et les fournisseurs sont généralement plus à l’aise pour démontrer la première que pour documenter la seconde.

Considérez le DPA comme un prérequis et non comme une étape finale.
Un accord de traitement des données signé devrait être en place avant que l’évaluation n’entre dans une phase proche de la production. Le négocier après les tests techniques crée une pression qui pousse souvent à accepter des conditions auxquelles les équipes juridiques se seraient opposées plus tôt.
Demandez l’architecture des journaux d’audit, pas simplement une liste de fonctionnalités. La question n’est pas de savoir si des logs existent, mais s’ils sont structurés de manière à répondre aux exigences de traçabilité et de contrôle d’accès définies par les équipes conformité. Cette différence devient cruciale lorsqu’un régulateur demande des justificatifs.
Limitez le premier déploiement à un périmètre restreint. Les entreprises qui réussissent leurs déploiements commencent généralement par un cas d’usage où les données sont clairement catégorisées, les périodes de conservation sont défendables et le périmètre est suffisamment étroit pour garder une traçabilité propre. L’expansion vient ensuite, à partir d’une base stable.

Conclusion

Les entreprises qui progressent réellement ne sont pas celles qui ont résolu toutes les questions de conformité. Ce sont celles qui ont défini suffisamment clairement ce que le chatbot peut et ne peut pas faire pour pouvoir opérer avec confiance dans ces limites.
Ce qui bloque souvent les déploiements, c’est le fait de traiter la conformité comme une simple checklist de lancement, puis de découvrir en plein projet que l’architecture des logs du fournisseur ne répond pas réellement aux besoins du juridique, ou que certaines données ont été manipulées d’une manière jamais précisée dans le contrat.
L’escalade des sanctions de la CNIL, passées de 55 millions à 486 millions d’euros en une seule année, n’est pas un simple contexte de fond. C’est l’environnement opérationnel dans lequel les entreprises évoluent désormais. Celles qui considèrent encore la conformité des chatbots comme une formalité d’achat prennent un risque qu’elles n’ont pas correctement évalué.
La technologie n’est plus l’incertitude principale. Ce qui reste encore en construction, c’est tout le cadre qui l’entoure, et se tromper sur cette partie aujourd’hui entraîne des conséquences qui n’existaient pas il y a deux ans.

Building Real-Time E-Commerce Recommendation Systems on AWS

Marvelous Olaoluwa — Fri, 22 May 2026 06:40:23 +0000

Modern e-commerce platforms are no longer competing only on price or product variety. Today, customer experience and personalization have become major factors influencing conversion rates, customer retention, and long-term revenue growth. Businesses that can intelligently recommend products based on customer behavior are gaining significant competitive advantages in the digital marketplace.

Amazon Web Services (AWS) provides powerful cloud infrastructure and machine learning tools that allow companies to build scalable recommendation systems capable of analyzing user behavior in real time.

Understanding the Role of Recommendation Systems

Recommendation engines are intelligent systems designed to analyze customer activity and suggest products that align with user interests, browsing patterns, and purchasing history. These systems improve customer engagement by making product discovery easier and more personalized.

Companies such as Amazon Web Services have helped businesses build recommendation systems capable of processing massive volumes of customer interactions without compromising speed or reliability.

Using Amazon Kinesis for Real-Time Data Processing

Real-time customer behavior tracking is one of the most important parts of a recommendation system. Every click, search, purchase, and interaction generates valuable data that can help businesses understand customer preferences more effectively.

With Amazon Kinesis, organizations can process streaming customer data instantly, allowing recommendation systems to react to user behavior in real time.

For example, if a customer searches for smartphones repeatedly, the recommendation engine can immediately begin displaying related products such as phone accessories, smartwatches, and protective cases.

This improves:

Product visibility
Customer engagement
Sales conversion rates
User experience personalization
Building Machine Learning Models with Amazon SageMaker

Machine learning plays a major role in improving recommendation accuracy. Instead of relying only on simple product categories, AI models can analyze customer patterns deeply and identify relationships between products automatically.

Using Amazon SageMaker, developers can train machine learning models capable of predicting what customers are most likely to purchase based on historical behavior and behavioral trends.

These models continue improving over time as they process more customer interactions and transaction data.

Businesses benefit from:

Smarter recommendations
Improved customer retention
Higher average order values
Better user engagement
Leveraging AWS Lambda for Serverless Automation

Managing infrastructure manually can become expensive and difficult as applications scale. This is why many businesses are adopting serverless architectures for recommendation systems.

With AWS Lambda, businesses can automatically process events and customer interactions without managing servers directly.

Whenever users interact with products, Lambda functions can:

Trigger recommendation updates
Process behavioral events
Update databases
Send personalized notifications

This reduces operational overhead while improving scalability and performance.

Importance of Scalability in E-Commerce Platforms

E-commerce traffic can increase dramatically during sales events, festive seasons, and marketing campaigns. Traditional infrastructure often struggles to handle sudden spikes in demand, leading to downtime and poor customer experiences.

AWS cloud infrastructure helps businesses scale automatically based on user demand, ensuring stable performance even during periods of extremely high traffic.

Scalable cloud systems help businesses:

Prevent service interruptions
Improve application reliability
Reduce infrastructure costs
Maintain consistent customer experiences
The Future of Personalized Shopping

Recommendation systems are becoming a core part of modern e-commerce strategy. Businesses that successfully personalize user experiences are more likely to improve customer loyalty and long-term profitability.
As AI and cloud technologies continue evolving, recommendation systems will become even more intelligent, predictive, and deeply integrated into digital shopping experiences.

AWS continues providing the infrastructure and AI capabilities helping businesses build faster, smarter, and more personalized e-commerce platforms globally.

https://www.qwertymates.com/marketplace

Ariel Madisha — Fri, 22 May 2026 06:37:22 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I completed Qwertymates — a multi-functional digital platform designed to be the home for doers, sellers, and creators.

Live: https://www.qwertymates.com/wall

Qwertymates is more than just a marketplace. It’s a connected ecosystem that brings together:

🛒 QwertyHub – Buy from verified suppliers
🌍 QwertyWorld – Social interactions and discovery
🏪 MyStore – Personal storefront management
🚚 Errands – Service-based task execution
💳 ACBPayWallet – Wallet and payments
📺 QwertyTV – Media streaming
🎵 QwertyMusic – Audio experiences
💬 Morongwa – Communication and messaging

The vision is simple:

Build a platform where users don’t need multiple apps to live, work, trade, and create online.

Demo

🔗 Live Platform: https://www.qwertymates.com
📂 https://github.com/ArielMadisha/Qwertymates
Key Screens (from the build)

Landing Page

Clean product-focused design with messaging:
“The Digital Home for Doers, Sellers & Creators.”
Clear CTAs: Get Started, Register, Sign In

Authentication System

Modern login experience with username/email/phone support
Clean UI over a visual background for a polished feel

Marketplace Feed (Wall)

Product posts from stores (e.g., handbags listing with prices in ZAR)
Social + commerce blended into one experience
Sidebar navigation across ecosystem features
Real-time interaction options (view product, resell, etc.)

The Comeback Story

Before this challenge, Qwertymates was:

💤 Sitting incomplete despite having a powerful vision
🧩 Fragmented across multiple ideas without cohesion
🚧 Missing polish and key integration points

What I fixed and completed:
✅ Unified the platform into a single cohesive ecosystem
✅ Completed authentication and navigation flows
✅ Built a working marketplace + social feed experience
✅ Refined UI for a modern SaaS-level look and feel
✅ Improved structure across modules (Hub, Wallet, TV, Music, etc.)
✅ Polished the user journey from landing → login → interaction
The biggest shift:

Moving from “a collection of ideas” → “a usable platform people can actually explore.”

My Experience with GitHub Copilot

GitHub Copilot played a critical role in helping me finish Qwertymates:
⚡ Speed & Momentum
Copilot helped generate:

UI components
Form handling logic
Reusable structures across modules

This allowed me to focus on architecture and product vision, not repetitive coding.
🧠 Problem Solving
Whenever I hit blockers, Copilot:

Suggested fixes
Helped debug faster
Offered alternative implementations

🧹 Refactoring & Cleanup

Improved code readability
Helped standardize patterns across the platform
Reduced technical debt

DevOps Consulting: How to Evaluate a Partner Before You Engage

Sam — Fri, 22 May 2026 06:36:15 +0000

Most DevOps engagements don't fail because of bad tooling. They fail because the wrong firm was chosen.

The pattern shows up the same way every time. An engineering leader signs a contract based on a polished proposal and an impressive client list. Six months later, the CI/CD pipeline is half-built, the team is dependent on an outside firm for every config change, and the internal engineers are no more capable than when they started.

Choosing a DevOps consulting partner is a consequential decision. The wrong one locks you into broken pipelines, stalled cloud migrations, and a knowledge gap that takes years to close. This article gives you a concrete framework for evaluating a partner before any contract is signed.

What DevOps Consulting Actually Covers

DevOps consulting is not a single service. It spans a wide range of work, and the differences matter when you're evaluating who can actually help you.

Typical scope includes:

Pipeline automation: Building and optimizing CI/CD workflows so code moves from commit to production reliably
Infrastructure as code (IaC): Managing cloud resources through version-controlled configuration rather than manual provisioning
Cloud migration: Moving workloads to AWS, Azure, or GCP with minimal disruption and proper architecture
Platform engineering: Building internal developer platforms that reduce cognitive load on engineering teams
Toolchain integration: Connecting source control, build tools, test frameworks, and deployment targets into coherent pipelines
DevSecOps: Embedding security controls into the pipeline rather than treating them as a separate review gate
Organizational change: Shifting team structure, process, and culture to support continuous delivery

One distinction worth making early: DevOps consulting is not the same as DevOps staffing. A staffing firm places engineers in your org on a time-and-materials basis. A consulting firm is accountable to outcomes. If you're hiring a firm to "do DevOps work," you should be clear on which model you're signing up for — because the contractual accountability is very different.

Also note that Azure DevOps and AWS DevOps are distinct ecosystems. A firm with deep AWS experience may have limited Azure expertise, and vice versa. Platform-specific depth matters more than generic cloud familiarity.

Why Partner Selection Fails

Before getting into evaluation criteria, it helps to understand what goes wrong. The failure modes are specific.

Choosing a generalist for a specialist problem. A firm with broad technology consulting experience may not have the depth to handle a Kubernetes migration or a GitOps implementation. General IT consulting and platform engineering require different skills. A firm that excels at project management and delivery governance is not automatically qualified to design your deployment architecture.

Evaluating on credentials, not execution history. Certifications — AWS Partner status, Microsoft Gold competency, various DevOps framework accreditations — tell you a firm met a threshold. They don't tell you whether that firm has delivered a working pipeline at your scale, with your constraints, under real project pressure. Credentials screen for eligibility, not capability.

No clarity on what "done" looks like. Vague scope is the single most common reason DevOps engagements run over budget and under-deliver. If neither party can describe what a successful engagement produces in concrete, measurable terms before the SOW is signed, the engagement will expand indefinitely.

Ignoring team model fit. DevOps consulting firms operate in fundamentally different ways: embedded teams that work inside your organization, advisory engagements that design and supervise, and managed service models that run your infrastructure on an ongoing basis. Each has appropriate use cases. Choosing the wrong model for your situation is a problem no amount of technical skill will fix.

6 Questions to Ask Before You Sign

These are the questions that separate firms worth engaging from those that look the part.

1. What's your delivery model?

Does the firm embed engineers in your team, operate in an advisory capacity, or run a managed service after implementation? The right answer depends on your goals. If you want your team to own the outcome, you need a firm that builds with you and transfers knowledge. If you need steady-state operations management, a managed service may be appropriate. The wrong answer is when the firm can't articulate its model clearly, or shifts the answer based on what you seem to want to hear.

2. Can you show a comparable engagement?

Ask for a reference from an engagement that mirrors yours: similar stack, similar scale, similar industry constraints. A logo wall is not a reference. A 10-minute call with an engineering director who can tell you what the firm built, what it cost, and what went wrong is a reference. If the firm can't provide that, treat it as a meaningful signal.

3. Who actually does the work?

Some DevOps consulting firms sell with senior engineers and deliver with junior subcontractors or offshore staff. Ask directly: who are the named engineers on this engagement, what are their backgrounds, and will they be consistent throughout the project? Firms with high staff turnover or opaque delivery structures tend to produce inconsistent work and difficult knowledge transfers.

4. How do you handle CI/CD pipeline ownership after handoff?

There are two fundamentally different approaches to delivery: build and leave, or build and enable. The first produces a pipeline your team can't maintain without ongoing vendor involvement. The second produces a pipeline your team understands and owns. Ask what the firm's standard knowledge transfer process looks like. If they don't have a standard answer, plan accordingly.

5. What's your depth on our specific cloud platform?

Ask specifically about AWS, Azure, or GCP — whichever is relevant to your environment. Ask about Azure DevOps pipelines, specific AWS DevOps tooling (CodePipeline, CodeBuild, ECS, EKS), or GCP-native tooling as appropriate. A firm that has delivered on your platform at scale will answer differently than one that has general cloud familiarity.

6. How do you measure success?

If the firm responds with vague language about "improved velocity" or "better collaboration," ask them to be more specific. Mature DevOps consulting firms measure outcomes with DORA metrics: deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate. If the firm can't talk about your current baseline and where you should be at the end of the engagement, they don't have a clear definition of done.

What Strong DevOps Consulting Firms Actually Look Like

The difference between a strong partner and a weak one shows up in specifics, not in proposal quality.

Area	Strong Partner	Weak Partner
References	Specific client outcomes with named contacts	Logo walls and case study PDFs
Toolchain stance	Opinionated, with clear rationale	"Tool-agnostic" with no actual recommendation
Delivery team	Named, consistent engineers from day one	Rotating cast after kickoff
Handoff plan	Documented from proposal stage	Treated as a future conversation
Platform depth	Certified with proof of delivery at scale	Certifications without real project history
Pricing model	Milestone-tied or outcome-based	Pure T&M with no accountability structure
Knowledge transfer	Embedded in the engagement design	An afterthought billed separately

One signal worth singling out: a firm that says it's "tool-agnostic" may be positioning to avoid difficult conversations. A firm with real experience has opinions. They've seen what works in specific contexts. "It depends" is a valid answer to architecture questions — but if a firm won't tell you what it actually recommends and why, that's a problem.

Enterprise vs. Mid-Market DevOps Consulting

Scale changes what you need from a partner, and not all firms serve both markets well.

Enterprise DevOps consulting typically involves compliance requirements, multi-cloud or hybrid environments, large change management programs, and governance structures that affect every decision. Firms that operate at this level tend to have dedicated practices around security, compliance automation, and scaled Agile frameworks.

Mid-market and growth-stage engineering teams usually need speed over process rigor. Over-engineering a pipeline for a 40-person team wastes time and budget. The right firm for this context moves quickly, avoids unnecessary abstraction, and builds something the team can actually own.

A firm that excels at Fortune 500 DevOps transformation may not be the right fit for a 50-person engineering team moving fast. The reverse is also true.

Ask the firm directly: what's the smallest engagement you've run, and what's the largest? The answer tells you where they're most comfortable and where their processes are actually calibrated.

Red Flags to Watch Before the Contract Is Signed

Some problems announce themselves early if you know what to look for.

No named team at proposal stage. If the firm can't tell you who is doing the work before you sign, they're staffing on demand after you sign. That's a different risk profile than what the proposal implies.
Vague scope with pure T&M pricing. Open-ended billing without defined milestones means no accountability for outcomes. You're paying for time, not results.
Over-reliance on a single platform vendor. A firm that consistently recommends one vendor's toolchain regardless of your environment may be optimizing for their certifications or partner margins, not your architecture.
No post-engagement knowledge transfer plan. If the firm hasn't described how your team takes over at the end, they haven't thought through the actual goal of the engagement.
References that don't match your context. A healthcare enterprise reference doesn't tell you much about a SaaS startup moving to Kubernetes. A retail case study doesn't validate DevSecOps capability for a financial services firm.
Proposal language that mirrors your RFP. Some firms mirror your language back to you without demonstrating independent thinking. It reads well. It doesn't mean they know what they're doing.

Questions to Ask on the Discovery Call

The discovery call is the fastest way to assess whether a firm has real experience or polished positioning. These questions expose the difference.

How do you structure a typical DevOps engagement?

A strong answer describes phased delivery with defined checkpoints: assessment, design, implementation, hardening, handoff. It names what gets delivered at each stage and what decisions the client makes. A weak answer describes a general process that could apply to any consulting engagement.

What does your knowledge transfer process look like?

Firms that have done this well have a standard answer. They can describe how documentation is created, how pairing works between their engineers and your team, and what "ready to own" looks like at handoff. Firms that haven't solved for this will treat it as a customization question.

How do you handle disagreements on architecture or tooling decisions?

This question reveals whether the firm is genuinely advisory or just executing to spec. You want a firm that will push back when they see a problem, explain the tradeoff clearly, and defer to you once the decision is made. A firm that always agrees isn't protecting your interests.

What's your experience with our specific cloud platform?

Listen for specifics: named services, version-specific details, failure patterns they've seen, architectural decisions they've made under real constraints. Generic answers signal breadth without depth.

How to Structure the Evaluation Process

Once you've done the first round of outreach, a structured process protects you from selecting based on proposal quality rather than delivery capability.

Define your success criteria internally before reaching out. What does a successful engagement produce in 90 days? In six months? If you can't answer that, you're not ready to evaluate.
Send a structured brief, not an open-ended intro call. Describe your current environment, your target state, your constraints (compliance, budget, timeline), and the two or three outcomes that matter most. Firms that respond thoughtfully to a structured brief will also respond thoughtfully to a real project.
Request two comparable references. Same industry or stack, roughly similar scale. Ask for engineering contacts, not account managers.
Run a paid discovery engagement before committing to full implementation. A two-to-four-week assessment gives you a working sample of the team's thinking, communication, and technical judgment. It's the most reliable signal you can get.
Evaluate the delivery team, not the sales team. Ask to meet the engineers who will be on-site. If the firm can't or won't do that before you sign, treat it as a structural problem, not a scheduling issue.

Before You Sign

The right DevOps consulting partner is not the largest firm on the list or the one with the most certifications. It's the one whose delivery model, team structure, and platform depth match what you're actually trying to build — and who has proof of doing it before.

Evaluating a partner takes more deliberate effort than evaluating a tool. The cost of the wrong choice isn't a canceled subscription. It's six to eighteen months of rework, dependency, and lost momentum for your engineering team.

How I Analyzed the Linux Kernel's Deadliest Logic Bug: A Deep Dive into Dirty Pipe (CVE-2022-0847)

amir — Fri, 22 May 2026 06:34:56 +0000

As developers, we often think of kernel exploits as highly complex assembly-level wizardry, heap grooming, or race-condition battles. But recently, I decided to sit down, pull up the Linux kernel source code, and trace the infamous Dirty Pipe vulnerability, CVE-2022-0847, line by line.

What I found was mind-blowing: a simple, uninitialized struct member in the core memory-management path allowed an unprivileged local user to write into read-only files through the Page Cache.

No race conditions.

No classic memory corruption.

No heap spraying.

Just one stale flag in a reused kernel structure.

This is my technical post-mortem and step-by-step code analysis of how this elegant logic bug worked.

The Conceptual Backstory: Page Cache, Pipes, and `splice()`

Before looking at the buggy code, we need to understand the three Linux kernel mechanisms that collided to create Dirty Pipe:

The Page Cache
Pipe buffers
The splice() system call

1. The Page Cache: RAM as a Disk Mirror

To avoid slow disk reads, Linux keeps recently accessed file data in memory. This memory-backed representation is called the Page Cache.

When multiple processes read the same file, for example /etc/passwd, the kernel does not necessarily load separate copies for every process. Instead, it can map those processes to the same physical memory page that represents the file's cached content.

Normally, if a process tries to write to a page without write permission, the kernel's Copy-on-Write mechanism protects the original data:

The original page remains unchanged.
A private copy is created.
The process writes to that private copy.
The read-only backing file remains safe.

That is the expected contract.

Dirty Pipe broke that contract.

2. The Pipe Buffer

In Linux, a pipe is implemented as a circular ring of buffers represented internally by struct pipe_inode_info.

Each slot in that ring is a struct pipe_buffer, defined in include/linux/pipe_fs_i.h:

struct pipe_buffer {
    struct page *page;
    unsigned int offset, len;
    const struct pipe_buf_operations *ops;
    unsigned int flags; // <-- the field that matters here
    unsigned long private;
};

The important field is:

unsigned int flags;

When data is written to a pipe, the kernel may allocate page-sized buffers, usually 4 KB. If the write does not fill the whole page, the kernel can mark that buffer as mergeable by setting:

PIPE_BUF_FLAG_CAN_MERGE

That flag tells the kernel:

New writes may be appended into the remaining space of this existing pipe buffer instead of allocating a new one.

That behavior is perfectly valid for normal anonymous pipe pages.

The problem appears when a pipe buffer stops pointing to a normal anonymous pipe page and starts pointing to a page from the Page Cache.

3. The `splice()` Syscall: Zero-Copy Magic

The splice() system call is a Linux performance optimization. It moves data between file descriptors and pipes without copying data back and forth through user space.

Instead of doing this:

file -> kernel buffer -> user space -> kernel pipe buffer

splice() can do something closer to this:

file page cache -> pipe buffer reference

That is powerful because it avoids unnecessary copying.

But it also means a pipe buffer can reference a page that belongs to the Page Cache of a file.

Internally, one of the relevant functions is:

copy_page_to_iter_pipe()

This function creates a pipe buffer that references the page containing file data.

That is where the bug lived.

Digging Into the Code: The Bug in `lib/iov_iter.c`

When splice() is used to map file data into a pipe, the kernel executes code similar to this vulnerable version of copy_page_to_iter_pipe():

static size_t copy_page_to_iter_pipe(struct page *page, size_t offset, size_t bytes,
                                     struct iov_iter *i)
{
    // ... validation steps ...
    struct pipe_inode_info *pipe = i->pipe;
    struct pipe_buffer *buf = &pipe->bufs[head & mask];

    buf->ops = &page_cache_pipe_buf_ops;
    get_page(page);
    buf->page = page;
    buf->offset = offset;
    buf->len = bytes;
    // What is missing here?

    pipe->head = head + 1;
    return bytes;
}

The missing line is the entire bug:

buf->flags = 0;

buf->flags was never initialized or cleared.

Because pipes are implemented as circular rings, the kernel reuses old pipe_buffer structures. If a previous operation left PIPE_BUF_FLAG_CAN_MERGE set, that stale flag could remain active when the same buffer slot was reused for Page Cache-backed file data.

That means a buffer referencing a read-only file page could accidentally still look mergeable.

That is the core of Dirty Pipe.

The Intersection of Two Commits

One thing I found especially interesting is that Dirty Pipe was not born from one obviously dangerous commit.

It came from the interaction of two separate changes:

1. Commit `241699cd72a8` — October 2016

This introduced the new pipe-backed iov_iter subsystem and added copy_page_to_iter_pipe().

The function did not initialize buf->flags.

At that time, this was not immediately exploitable because the dangerous merge flag did not exist yet.

2. Commit `f6dd975583bd` — May 2020

This added PIPE_BUF_FLAG_CAN_MERGE.

Suddenly, an old uninitialized field became security-critical.

That is the scary engineering lesson:

A harmless-looking initialization bug can become a critical vulnerability years later when another subsystem evolves.

Step-by-Step: How the Exploit Mechanics Worked

At a high level, the exploit forced the kernel into a bad state:

Prepare a pipe so all its internal buffer slots have PIPE_BUF_FLAG_CAN_MERGE set.
Drain the pipe so it becomes logically empty.
Use splice() to attach a read-only file's Page Cache page to a reused pipe buffer.
Because buf->flags was not cleared, the stale merge flag remains.
A later write to the pipe is merged into the Page Cache page.

The result: the in-memory cached representation of a read-only file is modified.

The disk file itself is not directly overwritten. The modification happens in the Page Cache.

Stage 1: Polluting the Pipe Buffers

The first step is to fill the pipe. This causes the kernel to allocate pipe buffers and mark them mergeable.

A simplified version looks like this:

int p[2];
pipe(p);

int capacity = fcntl(p[1], F_GETPIPE_SZ);
char dummy = 'A';

for (int r = capacity; r > 0; ) {
    int n = r > sizeof(dummy) ? sizeof(dummy) : r;
    write(p[1], &dummy, n);
    r -= n;
}

After this stage, the internal pipe buffer slots have been used and may contain PIPE_BUF_FLAG_CAN_MERGE.

Stage 2: Draining the Pipe

Next, the pipe is drained:

for (int r = capacity; r > 0; ) {
    int n = r > sizeof(dummy) ? sizeof(dummy) : r;
    read(p[0], &dummy, n);
    r -= n;
}

Now the pipe is logically empty.

But the kernel's internal pipe_buffer metadata is still there, ready to be reused.

The stale flags may still exist in those reused slots.

Stage 3: Splicing File Data into the Pipe

Then splice() is used to move data from a target file into the pipe without copying it through user space:

int fd = open("/path/to/read-only-file", O_RDONLY);
loff_t offset = 0;

splice(fd, &offset, p[1], NULL, 1, 0);

Behind the scenes, the kernel creates a pipe buffer that references the file's Page Cache page.

But because buf->flags was not cleared, the buffer may still have the old merge flag.

Now we have a dangerous state:

pipe_buffer.page  -> file Page Cache page
pipe_buffer.flags -> PIPE_BUF_FLAG_CAN_MERGE

That should never happen.

Stage 4: Writing into the Pipe

A subsequent write to the pipe is then treated as mergeable.

The kernel thinks it is appending data into a normal anonymous pipe page.

In reality, the buffer points to a file-backed Page Cache page.

So the write lands inside the cached file page.

That is why Dirty Pipe could modify the in-memory contents of files that the attacker should not have been able to write.

Why Dirty Pipe Was So Dangerous

Dirty Pipe was terrifying because it was not a fragile exploit.

No Race Condition

Dirty COW, CVE-2016-5195, depended on winning a race condition. Dirty Pipe did not.

There was no timing window to win.

No Classic Memory Corruption

This was not a buffer overflow or heap corruption bug.

The kernel was following its own logic, but that logic was operating on stale state.

High Reliability

Once the vulnerable state was created, the behavior was deterministic.

Page Cache Impact

The modification happened in memory through the Page Cache. That means the on-disk file might remain unchanged, but programs reading the file could observe the modified cached version.

Dirty Pipe vs Dirty COW

Dirty Pipe and Dirty COW are often compared because both involve unexpected writes related to file-backed memory.

But the exploit style is very different.

Feature	Dirty COW	Dirty Pipe
CVE	CVE-2016-5195	CVE-2022-0847
Bug type	Race condition	Uninitialized/stale state logic bug
Reliability	Timing-dependent	Highly deterministic
Main mechanism	Copy-on-Write race	Stale `PIPE_BUF_FLAG_CAN_MERGE`
Kernel area	Memory management	Pipes, Page Cache, `splice()`

Dirty Pipe is a great reminder that not all dangerous vulnerabilities look like obvious memory corruption.

Sometimes the bug is just one field that was not reset.

The Upstream Fix

The fix was surprisingly small.

In the patched version, the kernel explicitly clears the flags when creating a new pipe buffer:

diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index b0e0acdf96c15e..6dd5330f7a9957 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -414,6 +414,7 @@ static size_t copy_page_to_iter_pipe(struct page *page, size_t offset, size_t bytes,
         return 0;

     buf->ops = &page_cache_pipe_buf_ops;
+    buf->flags = 0;
     get_page(page);
     buf->page = page;
     buf->offset = offset;

One line.

One field.

A huge security impact.

Key Developer Takeaways

Analyzing Dirty Pipe gave me a stronger appreciation for defensive engineering in low-level systems.

1. Always Initialize Reused Structures

If a structure is reused, every stateful field should be explicitly initialized.

Relying on previous state is dangerous.

In kernel code, stale state is not just a bug. It can become a privilege escalation.

2. Flags Are Security Boundaries

A single bit can completely change how the kernel interprets memory.

PIPE_BUF_FLAG_CAN_MERGE looked like a performance optimization flag, but in the wrong context it became a security boundary bypass.

3. Subsystem Interactions Matter

The original missing initialization existed for years.

It became dangerous only after another feature introduced a new meaning for the stale field.

This is why reviewing only the changed file is not enough.

When adding new flags, modes, or state transitions, we should audit every path that creates, recycles, or reuses the structure.

4. Logic Bugs Can Be More Reliable Than Memory Corruption

Dirty Pipe was not powerful because it crashed the kernel or corrupted random memory.

It was powerful because the kernel's internal state machine became logically inconsistent.

That kind of bug can be easier to exploit and harder to detect.

5. Defensive Coding Is Not Optional in Systems Programming

In application code, forgetting to initialize a field may cause a weird UI bug or a failed request.

In kernel code, it may let an unprivileged user modify read-only file content.

That difference is why explicit initialization, careful invariants, and subsystem-level reviews are essential.

Exploit Discussion: Why I Will Not Weaponize It Here

At this point, it is tempting to drop a full copy-paste exploit and call the analysis complete.

Dirty Pipe is not just an academic bug. It is a real local privilege escalation vulnerability that can be used to modify sensitive files, abuse SUID binaries, and turn limited local execution into root-level impact on vulnerable systems.

So instead of publishing a weaponized exploit, I prefer to focus on the part that actually matters for experienced engineers: understanding the primitive, validating exposure safely, and reducing the blast radius.

The important idea is this:

Dirty Pipe gives an attacker a write primitive into the Page Cache under very specific conditions.

That is enough to explain the risk without handing someone a ready-made privilege escalation chain.

Safe Validation: How to Check Exposure Without Exploiting the Machine

The first thing I would check is the running kernel version.

uname -a
uname -r

Dirty Pipe affected Linux kernel versions starting from 5.8 and was fixed in patched kernel releases such as:

5.16.11
5.15.25
5.10.102

The exact package version depends on the distribution, because vendors often backport security fixes without changing the upstream kernel version in an obvious way.

That is why I do not rely only on uname -r in production. I also check the distribution security advisories and installed kernel changelog.

On Debian or Ubuntu-based systems:

apt list --installed | grep linux-image
apt changelog linux-image-$(uname -r)

On RHEL, Rocky, AlmaLinux, or Fedora-based systems:

rpm -q kernel
rpm -q --changelog kernel | grep -i CVE-2022-0847 -A 5

The goal here is not to exploit the host.

The goal is to answer one operational question:

Is this system running a kernel package that contains the Dirty Pipe fix?

Mitigation: The Real Fix Is a Kernel Update

There is no clever application-level patch that fully fixes Dirty Pipe.

The bug lives in the kernel.

So the primary mitigation is simple:

sudo apt update
sudo apt full-upgrade
sudo reboot

Or on RHEL-like systems:

sudo dnf update kernel
sudo reboot

After rebooting, always verify the active kernel:

uname -r

Installing a fixed kernel is not enough if the machine is still booted into the vulnerable one.

This is a common production mistake: the package is patched, the vulnerability scanner looks cleaner, but the running kernel is still old because nobody rebooted the host.

Reducing the Attack Surface

Dirty Pipe requires local code execution.

That local execution can come from many places:

an SSH account
a compromised web application
a CI/CD runner
an untrusted container workload
a shared development server
a low-privileged service user

So while patching is the real fix, reducing local execution paths is still important.

A few practical checks I usually care about:

# Users with interactive shells
cat /etc/passwd | grep -E '/bin/bash|/bin/sh|/bin/zsh'

# Users with sudo-like access
getent group sudo
getent group wheel

# Recently created users
sudo awk -F: '$3 >= 1000 { print $1, $3, $6, $7 }' /etc/passwd

If a user does not need shell access, remove it.

sudo usermod -s /usr/sbin/nologin username

If an old account should no longer authenticate, lock it.

sudo passwd -l username

None of this replaces patching.

But it reduces the number of places an attacker can start from.

Containers: Do Not Forget the Host Kernel

One of the most important operational lessons from Dirty Pipe is that containers do not bring their own kernel.

A container shares the host kernel.

So if the host kernel is vulnerable, a containerized workload may still be dangerous, especially when combined with weak isolation, excessive capabilities, or sensitive host mounts.

For production workloads, I would avoid patterns like this unless there is a very strong reason:

docker run --privileged ...

A safer baseline looks more like this:

docker run \
  --read-only \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  image-name

Also be careful with host mounts:

-v /:/host
-v /etc:/host/etc
-v /var/run/docker.sock:/var/run/docker.sock

Those mounts can turn a local container compromise into a much more serious host-level problem.

Dirty Pipe is a kernel bug, but real incidents usually happen through chains.

The kernel bug is one link.

Bad container isolation can be another.

Monitoring Sensitive Files

Dirty Pipe modifies data through the Page Cache, which makes the behavior unusual.

Still, sensitive files are the obvious places defenders should care about:

/etc/passwd
/etc/shadow
/etc/group
/etc/sudoers
/root/.ssh/authorized_keys

On Linux, auditd can help monitor write attempts and metadata changes:

sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/shadow -p wa -k shadow_changes
sudo auditctl -w /etc/group -p wa -k group_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes

Then search the audit logs:

sudo ausearch -k passwd_changes
sudo ausearch -k shadow_changes
sudo ausearch -k group_changes
sudo ausearch -k sudoers_changes

For file integrity monitoring, tools like AIDE can also help:

sudo apt install aide
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check

This is not a perfect Dirty Pipe detector.

But it is part of a healthy defensive baseline.

My Practical Takeaway for Security Engineers

When I look at Dirty Pipe from a defender's perspective, I do not think the lesson is "learn the exploit and move on."

The lesson is broader:

patch kernels quickly
reboot after kernel updates
reduce local shell access
avoid over-privileged containers
monitor sensitive identity and privilege files
review code paths that recycle stateful structures

The exploit is interesting.

But the engineering lesson is more valuable.

A single stale flag inside a reused kernel structure broke one of the assumptions Linux users rely on every day:

read-only files should not be writable by an unprivileged process.

That is the kind of bug that reminds me why low-level systems programming requires paranoia, not just correctness.

Final Thoughts

Dirty Pipe is one of those vulnerabilities that looks almost too simple after you understand it.

A stale flag survived inside a reused pipe buffer.

That pipe buffer was later pointed at a Page Cache page.

The kernel trusted the stale flag.

And that was enough.

For me, the most important lesson is this:

Security bugs often live at the boundaries between correct subsystems.

The Page Cache was doing its job.

Pipes were doing their job.

splice() was doing its job.

But the transition between those systems carried stale state, and that stale state broke the security model.

That is why kernel engineering is so fascinating — and so unforgiving.

References

Zero-Install Tunneling in 2026: The Developer's Complete Guide to Agentless Localhost Proxies

InstaTunnel — Fri, 22 May 2026 06:34:21 +0000

IT
InstaTunnel Team
Published by our engineering team
Zero-Install Tunneling in 2026: The Developer's Complete Guide to Agentless Localhost Proxies
How a single SSH command replaces bloated CLI daemons — and what your InfoSec team needs to know about it.

The Problem: When Your Laptop Won’t Let You Install Anything
Modern corporate endpoints are locked down tighter than ever. Endpoint Detection and Response (EDR) platforms like CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint actively flag and block the installation of unsigned or unrecognized binaries — including popular tunneling CLIs written in Go or Rust. Application whitelisting policies mean that even legitimate developer tools can be quarantined before they ever run.

For a developer trying to share a locally running React app for a quick stakeholder review, or expose a webhook endpoint to test a Stripe integration, this creates a frustrating paradox: the tools that would solve the problem are themselves blocked by policy.

The elegant workaround is already sitting on every developer’s machine, pre-approved by every IT department on the planet: OpenSSH.

What Is Agentless Localhost Tunneling?
Agentless tunneling (also called zero-install tunneling) refers to exposing a local port to the public internet using nothing more than the native SSH client already bundled with your operating system — no downloaded binary, no npm package, no elevated install permissions required.

The technique relies on SSH’s Remote Port Forwarding (-R) flag, which instructs a remote server to accept public traffic and relay it down an encrypted SSH tunnel to a port on your local machine. The remote relay server acts as the public-facing endpoint; your laptop acts as the hidden origin.

The architecture looks like this:

[ Public Internet User ]
│
▼ (HTTPS Request)
Relay Server
│
│ SSH Reverse Tunnel (Port 443)
▼
Your Laptop
│
▼ (Internal Routing)
Local App
Dissecting the One-Liner
Here is a typical zero-install tunnel command:

ssh -p 443 -R0:localhost:3000 free@a.pinggy.io
Each flag does something specific:

ssh — Invokes the native OpenSSH binary. No download needed; it ships with macOS, every major Linux distro, and Windows 10⁄11.
-p 443 — Connects over port 443 instead of the default SSH port 22. This is a deliberate engineering choice: corporate firewalls almost universally allow outbound HTTPS traffic on 443, whereas port 22 is frequently blocked for workstations. The SSH handshake rides through the same channel as normal web traffic.
-R — Activates Remote Port Forwarding. This tells the remote server to open a port and forward traffic back to you.
0:localhost:3000 — The 0 asks the relay to dynamically assign an available public port or subdomain. localhost:3000 tells the relay where to send that traffic on your machine.
free@a.pinggy.io — The relay server’s address, with free as the username prefix (Pinggy uses this field for parameter injection, explained later).
On execution, the relay server issues an autogenerated public URL — something like https://rkyxl-12-34-56.a.pinggy.link — printed directly to your terminal and ready to share.

Why Port 443 Is the Critical Trick
Most enterprise firewalls are configured to block outbound port 22 from developer workstations to prevent unauthorized remote management. Port 443 is reserved for HTTPS web traffic and is almost always open — blocking it would break normal web browsing for the entire organization.

By running SSH over 443, the tunnel’s initial handshake is indistinguishable from a standard TLS connection to a web server. Deep Packet Inspection (DPI) appliances see it as high-volume encrypted HTTPS traffic. As noted in security research from JUMPSEC Labs, many corporate environments still allow outbound SSH even when they believe they don’t, because monitoring SSH as a “living off the land” binary (LOLBIN) is not standard practice for blue teams focused on malware detection.

Important note for security teams: This dual-use nature is covered in detail in the Security section below.

The Leading Agentless Tunneling Platforms in 2026
Because every user runs the same standard SSH binary, differentiation between zero-install services lies entirely in the relay server’s capabilities. Here are the platforms worth knowing:

Pinggy Pinggy has emerged as the most feature-complete agentless option available without any installation. A single SSH command launches a fully interactive terminal UI (TUI) complete with real-time request counters, live traffic statistics, and a QR code rendered directly in the terminal — useful for immediately testing mobile responsiveness.

Key capabilities: - Protocol support for HTTP, HTTPS, TCP, and UDP (UDP tunneling is something neither ngrok nor Localtunnel offer) - A built-in web debugger accessible at http://localhost:4300 when combined with a local port forward (-L 4300:localhost:4300), allowing inspection of HTTP headers, payloads, and request replay - Advanced traffic control injected through the SSH username string (authentication, IP whitelisting, CORS overrides, custom headers — all without touching a config file) - Free tier sessions cut off after 60 minutes; paid tiers start at $3/month for persistent tunnels

Confirmed working (as of March 2026 testing by the NousResearch Hermes Agent team): a single SSH command produces both HTTP and HTTPS public URLs instantly, with free Let’s Encrypt certificates, no account required.

Performance caveat: In a 100 MB file transfer benchmark conducted by LocalCan in 2025, Pinggy delivered approximately 1.10 MB/sec (8.81 Mbps), which was the slowest among tools tested. This is largely a consequence of the TCP-over-TCP problem inherent to SSH-based tunneling: both the inner application TCP layer and the outer SSH tunnel perform their own congestion control, and a single lost packet on the outer layer can stall the inner connection. For webhook testing and UI sharing this is rarely an issue; for large file transfer scenarios, it matters.

localhost.run For absolute minimalism, localhost.run provides a dependable, zero-configuration alternative with no visual overhead:

ssh -R 80:localhost:3000 nokey@localhost.run
The server returns a clean HTTPS link and stays quietly in the background — ideal for automated bash scripts, CI/CD pipeline validations, and situations where terminal real estate must be preserved. It supports HTTP and HTTPS only (no TCP or UDP), and works on any OS with SSH available. No account is required to start tunneling immediately.

Serveo Serveo is a long-established free option notable for one feature: you can request a specific subdomain directly in the command:

ssh -R mysubdomain:80:localhost:5000 serveo.net
If the subdomain is available, the server binds it immediately. This is useful for persistent webhook URLs during development. As a community-supported free resource, availability can fluctuate under load compared to commercial infrastructure — worth keeping in mind for anything time-sensitive.

Localtonet (SSH Mode) Localtonet started as a client-heavy multi-protocol tunneling tool but has built a dedicated zero-install SSH entry point. Users configure a tunnel via a web dashboard, which outputs a token-authenticated SSH command string. This bridges enterprise control requirements with agentless execution.

As of January 2026, Localtonet is priced at $2 per tunnel per month and offers multi-region redundancy, UDP support, SSO integration, and 99.9% uptime — making it the most complete option for teams needing more than a quick demo URL.

How These Compare to Traditional Tools
Feature Pinggy localhost.run Serveo ngrok Cloudflare Tunnel
Installation Required None (SSH) None (SSH) None (SSH) CLI binary cloudflared daemon
Protocol Support HTTP, HTTPS, TCP, UDP HTTP, HTTPS HTTP, HTTPS, TCP HTTP, HTTPS, TCP HTTP, HTTPS, gRPC
Terminal Dashboard Yes (interactive TUI) No (text only) No (text only) Yes (custom CLI) No (cloud console)
Web UI Inspector Yes (via local port) No No Yes (localhost port) Yes (cloud console)
Custom Domains Paid tiers Paid tiers Yes (if available) Paid tiers Yes (free via DNS)
Free Tier Limit 60 min sessions Unlimited Unlimited 1 GB/month Unlimited bandwidth
UDP Support Yes No No No No
Throughput (100 MB test) ~1.10 MB/s Not benchmarked Not benchmarked ~0.84 MB/s ~3.47 MB/s
ngrok pricing as of early 2026: Free tier (1 GB/month, random domains, session interstitial warning), Personal at $8/month (5 GB, 1 persistent domain), Pro at $20/month (15 GB, edge config, load balancing). Cloudflare Tunnel remains entirely free for HTTP/HTTPS with no bandwidth cap, making it exceptional value for teams already in the Cloudflare ecosystem — though it requires installing the cloudflared daemon.

Advanced Features Without a Client: Parameter Injection via SSH Username
A common misconception is that going agentless means losing access to advanced features like authentication, header manipulation, and CORS control. Pinggy’s engineering team solved this by using a feature of the SSH protocol that most developers overlook: the SSH username field can carry arbitrary strings.

Since the SSH connection protocol allows any string as the username, Pinggy parses this string on their edge nodes to dynamically apply traffic configurations before packets enter the tunnel. You pass your parameters by separating them with +.

Basic Authentication
Lock a public URL behind username/password credentials — useful when exposing internal tools to external stakeholders:

ssh -p 443 -R0:localhost:3000 "b:admin:secretpassword+free@a.pinggy.io"
Pinggy’s edge intercepts incoming requests and issues a standard HTTP Basic Auth browser prompt. Your local server never receives an unauthenticated request.

IP Whitelisting (CIDR)
Restrict access to a specific IP range — e.g., your company’s VPN egress IP:

ssh -p 443 -R0:localhost:3000 "w:192.0.2.0/24+free@a.pinggy.io"
Custom HTTP Header Injection
Useful for simulating specific environments, bypassing API gateway checks, or validating webhook signatures:

ssh -p 443 -R0:localhost:3000 "a:X-Environment:Staging+free@a.pinggy.io"
Global CORS Override
When testing microservices across different origins and cross-origin blocking is halting frontend execution:

ssh -p 443 -R0:localhost:3000 "co+free@a.pinggy.io"
Parameters can be chained. A tunnel with basic auth, CORS enabled, and a custom header looks like:

ssh -p 443 -R0:localhost:3000 "b:admin:pass+co+a:X-Environment:Staging+free@a.pinggy.io"
This moves complex routing and security logic onto edge servers, controlled entirely through string parsing in the SSH handshake.

Dealing with Restrictive Proxies
If your network blocks outbound port 443 as well, or requires all traffic to route through an HTTP proxy, Pinggy documents a workaround using ncat and openssl:

ssh -p 443 -R0:localhost:4000 \
-o ProxyCommand="ncat --proxy-type http --proxy 192.168.2.2:3128 %h %p" \
a.pinggy.io
This routes the SSH tunnel through your corporate HTTP proxy, making it viable even in environments with aggressive outbound filtering.

The Security Perspective: What InfoSec Teams Need to Know
Zero-install tunneling is fundamentally dual-use. The same properties that make it frictionless for developers — encrypted traffic over 443, no binary to flag, no install events to log — make it a viable data exfiltration vector if misused or exploited.

What developers gain
From a data-in-transit standpoint, agentless proxies are genuinely secure. The link between the developer’s machine and the relay server is wrapped in SSH encryption (AES-GCM or ChaCha20-Poly1305). Traffic on the public side travels over standard HTTPS to the provider’s edge, where it is decrypted and re-encrypted via SSH before arriving on the local machine. On open or compromised local networks — coffee shop Wi-Fi, conference hotel networks — corporate code payloads cannot be sniffed or intercepted.

What security teams should monitor
Because the traffic rides inside an encrypted SSH wrapper over port 443, traditional DPI appliances classify it as generic HTTPS traffic. There is no binary installation event, no registry modification, no process with an unusual name. The only signal is an outbound SSH connection to an unfamiliar domain.

Practical governance approaches that forward-looking security teams are adopting:

Relay Infrastructure Whitelisting. Rather than attempting to block all SSH tunneling (which risks blocking legitimate uses), enterprises partner with commercial zero-install providers like Pinggy Pro or Localtonet Enterprise. The organization configures a dedicated custom domain (e.g., *.tunnels.company.com) and whitelists the static IP spaces of those specific relay nodes at the firewall. Unauthorized relay providers are blocked by default.

SSH Key Enforcement. Security teams require that any SSH tunnel initiated from a corporate asset must authenticate using an authorized corporate SSH key pair tied to an employee’s Identity Provider (IdP) account. This ensures complete auditability: which account opened the tunnel, when it opened, and how much bandwidth was transferred.

Embracing Ephemeral Lifespans. Pinggy’s free tier enforces automatic 60-minute session cutoffs. InfoSec teams can adopt this as a feature rather than a limitation, establishing policy that tunnels are ephemeral assets — spun up on demand for a specific debugging task, torn down immediately after. This minimizes the attack surface available to internet scanners and persistent threat actors.

Behavioral Detection. Security tools like Zeek and modern EDR platforms with SSH behavioral rules can be configured to alert on unusual port-forwarding patterns — for example, a workstation establishing an -R type forward to an external host, or sustained high-bandwidth SSH sessions to non-corporate domains. This is a more sustainable detection strategy than trying to block SSH entirely.

When to Use What: A Decision Framework
Use Pinggy if: You need something running in under 30 seconds with zero installs, want a request inspector, need UDP support, or want to share a QR code for mobile testing.

Use localhost.run if: You’re scripting automation, running CI/CD validation, or need a quiet background process with no terminal dashboard overhead.

Use Serveo if: You need a memorable, persistent subdomain during a specific development sprint and can tolerate occasional availability hiccups.

Use Localtonet if: You’re on a team, need multi-region reliability, SSO integration, or UDP support with a proper SLA.

Use Cloudflare Tunnel if: You’re already in the Cloudflare ecosystem, need production-grade reliability, HTTP/HTTPS bandwidth is unlimited, and you don’t mind installing cloudflared. It delivered 3.47 MB/s in throughput benchmarks — the fastest of any hosted tunnel option tested in 2025.

Use ngrok if: You need the broadest ecosystem of integrations and are willing to pay for persistence and volume. Its throughput benchmark of 0.84 MB/s makes it the slowest of the major options despite being the most widely recognized.

Conclusion
The case for zero-install tunneling in 2026 is not merely about convenience — it’s about working with the security architecture enterprises have built rather than constantly fighting against it. A native SSH binary is pre-trusted. It generates no install events. It requires no elevated permissions. And when tunneled over port 443, it passes through corporate egress filters without friction.

The platforms built on top of this model — Pinggy, localhost.run, Serveo, Localtonet — have reached a level of maturity where they genuinely match or exceed the developer-facing features of traditional CLI clients. The addition of parameter injection for auth, CORS, and header manipulation means that the username string in a single SSH command can replicate what previously required a full configuration file and a running daemon.

For InfoSec and NetOps teams, the right response is not to block SSH (which introduces more problems than it solves) but to structure governance around approved relay infrastructure, key-based authentication auditing, and behavioral detection. The tools exist; the frameworks are evolving.

For the developer navigating a locked-down endpoint: stop fighting installer permissions. The most powerful tunneling client you need is already on your machine.

ssh -p 443 -R0:localhost:3000 free@a.pinggy.io
That’s it.

Last updated: May 2026. Pricing and feature details for Pinggy, ngrok, Cloudflare Tunnel, and Localtonet verified against current documentation and third-party benchmarks.

zero-install tunneling, agentless localhost proxy, Pinggy SSH tunnel alternatives, localhost.run configuration, SSH reverse tunnels, native SSH client proxy, enterprise security compliance, bypassing corporate IT restrictions, no-binary tunneling, browser-based local testing, secure port forwarding, ssh remote port forwarding, exposing localhost safely, developer infrastructure 2026, shadow IT mitigation, ngrok alternative ssh, serveo alternatives, cloudflared vs agentless, secure localhost ingress, native macOS ssh tunnel, native linux reverse proxy, zero-trust ssh gateway, corporate laptop security, developer productivity tools, endpoint protection compliance, command-line port forwarding, remote access without binaries, enterprise-safe localhost sharing, ssh port map, light-weight reverse proxy, automated webhooks local testing, public URL native SSH, secure tunneling for developers, agentless infrastructure 2026, web development tools, proxying without install, bypassing software blocks, devops port forwarding, cloud-to-local agentless bridge, public entrypoint via SSH

How an expired SSL cert took down our checkout for six hours (and what I should have had watching)

SamReid — Fri, 22 May 2026 06:34:12 +0000

The site was "up." The monitor said so. HTTP 200, response times normal, no alerts.

What the monitor didn't know - what I didn't know - was that our SSL certificate had expired 87 minutes earlier and every user hitting the site was getting a certificate error in their browser. Not a down page. Not a 5xx. A cert error. The kind where browsers show a big red warning screen and most users immediately close the tab.

For a checkout flow, that's about as bad as the server being down. Worse, actually, because at least a down server triggers your uptime alert.

This is the post-mortem.

What happened

We were running Let's Encrypt with certbot and auto-renewal configured. The renewal was supposed to happen when the cert had 30 days left. It had been working fine for about 18 months.

Then it didn't.

The renewal job ran, hit a DNS validation error - our DNS provider had a 30-minute API hiccup that day - and failed silently. Certbot logged the failure, but nobody was watching certbot logs. The retry ran 12 hours later, same issue. Then it was fine. But by then, the "success" window had passed and the cert expired before the next attempt.

Let's Encrypt auto-renewal fails for reasons that feel random at the time:

DNS propagation delays when you're using DNS-01 validation and your DNS provider has latency
Rate limits - Let's Encrypt has per-domain limits (5 failures per hour) that cause subsequent retries to also fail
Firewall or load balancer changes that block the HTTP-01 validation path on port 80
File permission issues on the cert directory after a system update
Webhook or deploy hook failures - the cert renews but the service doesn't reload to pick up the new cert

In our case it was DNS validation timing plus a log nobody was watching. The cert expired at 3:14 PM. The Slack alert - from a user, not a monitor - came in at 4:58 PM.

Why my uptime monitor missed it for four hours

GrabDiff monitors SSL expiry now, which is part of why I built it. But at the time I was using a basic HTTP ping monitor. Here's what it was doing:

Make HTTP request to our URL
Check for 200 response
Mark as healthy

The problem is step 1. The monitor was connecting via HTTP (port 80) and following the redirect to HTTPS. The redirect itself returned 301, healthy. Then the HTTPS request... also returned 200?

Sort of. The monitor wasn't validating the SSL certificate. It was making the HTTPS request with cert verification disabled, because false positives from cert issues in test environments made that the default in a lot of ping monitoring setups. So it dutifully checked the response code, got a 200 (from behind the expired cert that browsers were rejecting), and marked everything green.

Four hours of "everything is fine."

What proper SSL monitoring actually checks

SSL expiry monitoring should check a few distinct things:

1. Certificate expiry date - the obvious one. Get the cert's Not After field and alert at configurable thresholds. I alert at 30 days and 7 days. If you're using Let's Encrypt with 90-day certs, a 30-day warning gives you two full renewal windows to fix it.

2. Full-chain validation - not just that a cert exists, but that the entire chain from your cert to the root CA is valid. Intermediate cert issues cause browser errors even when your cert itself hasn't expired.

3. Cert actually served matches expected domain - if something went wrong with your load balancer config and it's serving the cert for a different domain, that's a browser error even with a valid cert.

4. Port 443 is actually accepting connections - a "port not open" situation is different from "cert expired" but both cause the same user-facing result.

5. The cert returned matches what's on disk - this catches the case where renewal succeeded but the service didn't reload and is still serving the old, expired cert.

A ping monitor does none of these. A lot of "SSL monitoring" tools only do #1, which misses the cases that actually catch you off guard.

What I'd do differently

Monitor the cert directly, not via HTTP. Connect to port 443, do the TLS handshake, and inspect the cert that's actually being served. Don't just check the expiry date - validate the chain.

Set alert thresholds that give you time to fix things manually. Let's Encrypt certs renew at 30 days remaining. I alert at 30 days (something's wrong with auto-renewal) and 7 days (it's still not fixed and now it's urgent). That gives me 23 days between "something's wrong" and "now panic."

Watch the renewal logs. Not the SSL cert itself, but the renewal process. Set up a heartbeat - certbot's --deploy-hook can ping a monitoring URL on successful renewal. If the heartbeat doesn't arrive within period + grace, alert. This catches the "cert renewed but didn't reload" case too.

Test your renewal before it matters. certbot renew --dry-run in your staging environment, regularly. Not just once when you set it up.

The monitoring stack I run now

For SSL specifically: I use GrabDiff for the cert expiry checks - it connects directly to port 443, validates the full chain, and alerts at 30 days and 7 days with enough context to know what's actually wrong (expiry date, issuer, which check failed).

For the renewal heartbeat: I have certbot's --deploy-hook send a ping to a GrabDiff heartbeat monitor after each successful renewal. If it doesn't ping within 93 days (the Let's Encrypt cert lifetime plus a week), I get alerted. That catches the silent renewal failures before they become a problem.

The six-hour checkout outage cost us - I'd rather not quantify it. The monitoring stack that would have caught it costs $9/month. That math is not complicated.

The broader lesson

SSL expiry is one of the most embarrassing categories of outage because it's entirely predictable. You know the cert will expire. You have the date. The only question is whether you catch it before your users do.

The same is true for domain expiry, for that matter. I've seen teams let their primary domain expire because the renewal email went to a former employee's address and nobody caught it. The monitoring there is trivial - check the WHOIS expiry date, alert 60 days out. But people don't do it until they have to learn the hard way.

If your current monitoring setup would have missed the scenario I described above - HTTP 200 from an expired-cert server - it's worth spending 20 minutes fixing that before you have your own version of this post-mortem to write.

I wrote this mostly to stop myself from having to explain this incident verbally ever again. Now I can just link it.

But seriously - SSL expiry outages are embarrassing in a specific way because they're so avoidable, and I've seen them happen to teams that clearly knew what they were doing otherwise. If you've had your own cert-expiry story (or a renewal failure that was weirder than mine), I'd like to hear it in the comments. Knowing the failure modes other people have hit is the only way to build a monitoring checklist that actually covers the real world.

Forem

Better Loading Buttons in Angular Material v22

A Simple Example

The Old Way: Swap the Label for a Spinner

The Angular Material v22 Way: Use showProgress and progressIndicator

Why This Feels Better

This Does Not Have to Be a Material Spinner

Cleaner Loading Buttons in Angular Material

Want to Go Deeper With Modern Angular?

Additional Resources

DevOps on AWS: Accelerating Software Delivery Through Automation

📚 The Book Pattern: Progressive Disclosure for AI Agents

📚 The Anatomy of a Technical Book

🤖 The Orchestrator File Is the Cover, Preface, and Table of Contents

📖 Every Skill Is a Chapter

📎 The References Folder Is the Appendix

🏷️ The Industry Name: Progressive Disclosure

⚖️ Why It Beats the All-in-One Prompt

✍️ Writing Your Orchestration Like an Author

🧭 The Bookshelf Mental Model

Learn MERN Stack by Building and Deploying a Real FullStack Application — Live 2-Day Webinar

📅 Dates & Timings

What You'll Build

📌 Day-by-Day Breakdown

🔥 Day 1 — React Fundamentals (Frontend)

🔥 Day 2 — Backend + Integration + Deployment

🎯 Who Is This For?

✅ Why This Webinar Is Different

⚠️ Limited Seats — Register Now

About Me

The Most Concerning AI Risk of 2026

The AI Takeover is Here

The Claude Code Connection

A Threat to Developers

Preparing for an AI Future

Chatbots GPT et conformité au RGPD : comment les entreprises françaises abordent l’adoption de l’IA

Pourquoi les chatbots GPT sont considérés comme des systèmes opérationnels

Comment le RGPD influence chaque décision autour du déploiement de l’IA

Ce que signifie réellement la “conformité” lorsqu’une IA est utilisée en production

Meilleures plateformes de chatbots GPT

1. Intercom

Idéal pour

2. YourGPT

Idéal pour

3. Zendesk

Idéal pour

4. Ada

Idéal pour

5. Crisp

Idéal pour

6. Tidio

Idéal pour

Comment évaluer les chatbots GPT avant une adoption en entreprise

Conclusion

Building Real-Time E-Commerce Recommendation Systems on AWS

https://www.qwertymates.com/marketplace

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

DevOps Consulting: How to Evaluate a Partner Before You Engage

What DevOps Consulting Actually Covers

Why Partner Selection Fails

6 Questions to Ask Before You Sign

What Strong DevOps Consulting Firms Actually Look Like

Enterprise vs. Mid-Market DevOps Consulting

Red Flags to Watch Before the Contract Is Signed

Questions to Ask on the Discovery Call

How to Structure the Evaluation Process

Before You Sign

How I Analyzed the Linux Kernel's Deadliest Logic Bug: A Deep Dive into Dirty Pipe (CVE-2022-0847)

The Conceptual Backstory: Page Cache, Pipes, and splice()

1. The Page Cache: RAM as a Disk Mirror

2. The Pipe Buffer

3. The splice() Syscall: Zero-Copy Magic

Digging Into the Code: The Bug in lib/iov_iter.c

The Intersection of Two Commits

1. Commit 241699cd72a8 — October 2016

2. Commit f6dd975583bd — May 2020

Step-by-Step: How the Exploit Mechanics Worked

The Angular Material v22 Way: Use `showProgress` and `progressIndicator`

The Conceptual Backstory: Page Cache, Pipes, and `splice()`

3. The `splice()` Syscall: Zero-Copy Magic

Digging Into the Code: The Bug in `lib/iov_iter.c`

1. Commit `241699cd72a8` — October 2016

2. Commit `f6dd975583bd` — May 2020