DEV Community

I Built Rust-Style ADTs in 30 Lines of Python (Pattern Matching Works)

Alexander Mia — Tue, 12 May 2026 12:39:56 +0000

Sum types — also called tagged unions or algebraic data types — are the feature I miss most when I switch from Rust or Haskell back to Python. The match statement landed in 3.10, but the standard library still does not give you a clean way to declare a closed set of variants where each variant carries its own fields.

Here is a 30-line metaclass that fixes that.

The result first

class Computation(metaclass=EnumMeta):
    Nothing = Case()
    To = Case(target=int)
    List = Case(targets=list[int])


follower = Computation.List([1])


match follower:
    case Computation.To(target=p):
        print(p)
    case Computation.List(targets=p):
        print(p)
    case Computation.Nothing:
        print("nothing")

Three variants. Each variant is its own type. Pattern matching destructures fields by name. No Union, no isinstance chains, no boilerplate constructors.

The whole implementation

from dataclasses import make_dataclass, fields


class Case:
    def __init__(self, **attributes):
        self.dict = attributes


class EnumMeta(type):
    def __new__(cls, name, bases, clsdict):
        new_cls = super().__new__(cls, name, bases, clsdict)

        for field_name, value in clsdict.items():
            if not isinstance(value, Case):
                continue
            dc = make_dataclass(
                f"{name}.{field_name}",
                list(value.dict.items()),
                bases=(new_cls,),
            )
            dc.__match_args__ = tuple(f.name for f in fields(dc))
            setattr(new_cls, field_name, dc)

        return new_cls

What is happening

Case is a placeholder. It records the fields a variant will carry and nothing else. Case(target=int) means this variant has one field named target typed as int.

EnumMeta walks the class body when the class is constructed. For every Case it finds, it does four things.

Builds a dataclass for that variant with make_dataclass. The fields come straight from the Case kwargs.
Inherits from the parent class. bases=(new_cls,) means Computation.To is a subclass of Computation. This is what makes match Computation.To(...) work as a class pattern.
Sets __match_args__. This is the magic line. The match statement uses __match_args__ to know which positional fields to destructure. Dataclasses do not get this in the right shape by default for keyword-style patterns, so we set it explicitly from the field names.
Replaces the Case placeholder on the class with the new dataclass.

After EnumMeta runs, Computation.List is no longer a Case — it is a real dataclass type. Calling Computation.List([1]) constructs an instance with targets=[1].

Why this beats the alternatives

Enum cannot carry per-variant fields. You would end up smuggling data through value tuples and losing type information.

Union[A, B, C] of dataclasses works for pattern matching, but you have to declare each variant as a separate top-level class and then wire them into a union by hand. The variants live everywhere; the union is a comment.

Libraries like returns or pyrsistent give you sum types but pull in a dependency and an opinionated style.

The metaclass approach keeps variants grouped under the parent type, so Computation is a closed namespace. You read the class definition and you see every possible value the type can take. That is the property that makes ADTs useful: exhaustiveness in one place.

Caveats

This is not exhaustive checking at the type level. mypy does not know Computation is closed, so a missing case in your match will not be flagged. If you want that, add a case _: assert_never(x) arm at the end.

make_dataclass does not accept forward references the way a typed dataclass body does. Stick to concrete types in Case(...) or pass strings and let dataclasses resolve them.

The variants are subclasses of the parent. That is load-bearing for match, but it also means isinstance(x, Computation) returns True for any variant, which you usually want.

When to reach for this

When you have a small, closed set of states that each carry different data. Parser results. State machine transitions. Validation outcomes. Anywhere you would write a chain of isinstance checks today.

For two states or a state without data, just use a dataclass with an Optional. For four or more variants with distinct payloads, the metaclass earns its keep.

Thirty lines. No dependencies. Real pattern matching.

Building an Offline-First Exchange Calculator with Vanilla JavaScript

임세환 — Tue, 12 May 2026 12:38:21 +0000

SudangHelp is a Korean financial decision engine that turns scattered government policies and financial data into simple calculator outputs. The product direction is intentionally practical: users should be able to open a page, enter a number, and get a clear result without reading through multiple policy documents.

One of the more interesting tools in this system is the travel exchange calculator. At first, it sounds like a basic currency converter, but the real use case is a little different: travelers need fast answers, country-specific defaults, and a page that still behaves reasonably when the network is unstable.

People do not always need a full finance dashboard when they are traveling. They need to know things like:

"How much is 100,000 VND in KRW?"
"Can I use this in the airport without installing an app?"
"Can I open the same page again if the connection is bad?"
"Can the page start with the right currency for Vietnam, Thailand, or Japan?"

That changed the implementation direction. I did not want to build a heavy app. I wanted a fast static page that behaves like a small app when needed.

The result is the live SudangHelp exchange calculator, built with plain HTML, CSS, and Vanilla JavaScript.

This post is a short implementation note on how I structured it.

1. Why I used Vanilla JavaScript

The calculator does not need a framework. Most of the state is local and temporary:

the source currency
one or more target currencies
the amount entered by the user
the latest loaded exchange rates
the country preset inferred from the URL

Using Vanilla JavaScript kept the runtime small and made the page easier to cache. It also reduced the amount of build tooling needed for a static site.

The core conversion logic is intentionally boring:

function convertCurrency(amount, from, to) {
  if (!EXCHANGE_RATES[from] || !EXCHANGE_RATES[to]) return 0;
  return (amount / EXCHANGE_RATES[from]) * EXCHANGE_RATES[to];
}

For a calculator, boring code is usually a good thing. The more important work was around page behavior: presets, fallback data, and offline access.

2. URL-driven country presets (briefly)

The calculator uses URL-based routing where each country path (e.g., /vietnam/, /japan/, /thailand/) initializes the calculator with the correct default currency pair — all served from a single static HTML file.

I covered this pattern in detail in an earlier post:

👉 Building a 49-Country Exchange Calculator with a Single Static Page

For this article, what matters is that the URL-derived preset determines which currency pair the offline cache prioritizes. That brings us to the more interesting part — making the whole thing work without an internet connection.

3. Live rates with a safe fallback

The calculator loads exchange rates from a worker endpoint. If the request succeeds, the app updates the in-memory rate table and recalculates the visible result.

If the request fails, the calculator does not crash. It falls back to default rates and shows an offline-mode message.

The simplified flow:

async function loadRates() {
  try {
    const response = await fetch(EXCHANGE_API_URL);

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const data = await response.json();
    const rates = data.rates || data;

    if (typeof rates !== 'object' || rates === null) {
      throw new Error('Invalid rates data');
    }

    Object.keys(EXCHANGE_RATES).forEach(code => {
      if (rates[code] && typeof rates[code] === 'number' && rates[code] > 0) {
        EXCHANGE_RATES[code] = rates[code];
      }
    });

    updateDisplay();
    updateRateDisplay();
  } catch (error) {
    rateInfo.textContent = 'Offline mode using fallback rates';
  }
}

There are two important ideas here:

Validate external data before using it.
Keep the calculator usable even when the network is unstable.

For a travel tool, that fallback behavior is not a bonus feature. It is part of the product.

4. PWA-style caching

The project uses a service worker under the travel section. The service worker pre-caches the main travel pages, selected country pages, icons, and an offline page.

For HTML navigation requests, the service worker uses a network-first strategy:

if (
  event.request.mode === 'navigate' ||
  event.request.headers.get('accept')?.includes('text/html')
) {
  event.respondWith(networkFirst(event.request));
  return;
}

For static assets, it uses cache-first:

event.respondWith(cacheFirst(event.request));

This split is useful:

HTML should be fresh when possible.
CSS, JavaScript, and icons can be served quickly from cache.
If navigation fails, the cached page or offline page can still respond.

I also excluded API endpoints and external worker URLs from the cache list. Exchange rate data should not be silently frozen by a static asset cache.

5. DOM caching for repeated updates

The calculator updates the UI frequently when users type, switch currencies, or add target currencies.

Instead of querying the same DOM nodes repeatedly, I initialize a small DOM reference object on page load:

DOM.amountValue = document.getElementById('amount-value-input');
DOM.symbolInput = document.getElementById('symbol-input');
DOM.amountKorean = document.getElementById('amount-korean-input');
DOM.fromCurrency = document.getElementById('from-currency');
DOM.operationDisplay = document.getElementById('operation-display');
DOM.conversionResults = document.getElementById('conversion-results');

This is not a complex optimization. It is just a practical one. Calculator interfaces are input-heavy, so small repeated operations add up.

6. What I would improve next

The current version works as a fast static calculator, but there are still improvements I would like to make:

separate the country preset data from the calculator runtime
generate country pages from a single source of truth
add better test coverage for URL preset detection
improve stale-rate messaging when the app is offline
make the install prompt more consistent across iOS and Android

Final thoughts

The biggest lesson from this project was that a "simple calculator" is rarely just a formula. The formula is the easy part. The difficult part is designing the surrounding behavior: loading, fallback, routing, caching, and the first state the user sees.

That is where a small static tool starts to feel like a real product.

You can try the calculator yourself at sudanghelp.co.kr/travel/exchange/.

10 CLI Tools Every Python Developer Should Know in 2025

Suifeng023 — Tue, 12 May 2026 12:36:52 +0000

10 CLI Tools Every Python Developer Should Know in 2025

As a Python developer, your terminal is your best friend. While pip and python get you far, the right CLI tools can supercharge your workflow. Here are 10 command-line tools that will make you significantly more productive.

1. 🐍 `uv` — The Future of Python Package Management

uv by Astral (the Ruff team) is a blazing-fast Python package installer and resolver, written in Rust. It's a drop-in replacement for pip and pip-tools that's 10-100x faster.

# Install uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# Create a project with virtualenv
uv init my-project
uv add requests pandas

# Run a script with auto-managed deps
uv run script.py

Why it matters: It replaces pip, virtualenv, pip-tools, and poetry with a single, faster tool.

2. 🦀 `ruff` — Instant Python Linting & Formatting

Ruff is another Rust-powered tool that replaces Flake8, isort, Black, and more — running in milliseconds instead of seconds.

pip install ruff

# Lint
ruff check .

# Format (replaces Black)
ruff format .

# Fix auto-fixable issues
ruff check --fix .

Why it matters: One tool replaces 6+ linters and formatters. Your CI pipeline will thank you.

3. 📦 `pipdeptree` — Visualize Your Dependency Tree

Ever wondered why a package pulled in 50 transitive dependencies?

pip install pipdeptree
pipdeptree --packages requests

This shows you exactly which packages depend on what, making it easy to spot conflicts and bloat.

4. 🧪 `pytest` — Testing Made Painless

Yes, pytest is the standard, but many devs still don't use it to its full potential:

pip install pytest pytest-cov pytest-xdist

# Run with coverage
pytest --cov=myapp tests/

# Parallel execution (massive speedup!)
pytest -n auto

# Only run failed tests from last run
pytest --lf

Pro tip: Use pytest -k "test_name" to run a subset of tests while debugging.

5. 🔍 `rich` — Beautiful Terminal Output

Rich makes your CLI tools look professional with syntax highlighting, tables, progress bars, and tracebacks.

pip install rich
python -m rich

Example:

from rich.console import Console
from rich.table import Table

console = Console()
table = Table(title="Deploy Status")
table.add_column("Service")
table.add_column("Status")
table.add_row("API", "✅ healthy")
console.print(table)

Why it matters: Better CLI output reduces debugging time and makes internal tools easier for teams to use.

6. 🌍 `httpie` — Human-Friendly API Testing

curl is powerful, but httpie is much easier to read when testing APIs.

pip install httpie

http GET https://api.github.com/users/octocat
http POST localhost:8000/items name="demo" price:=19.99

Why it matters: If you build FastAPI, Django, Flask, or any HTTP service, this is one of the fastest ways to test endpoints from the terminal.

7. 🧹 `pre-commit` — Stop Bad Code Before Git Commit

pre-commit runs formatters, linters, and security checks before code reaches your repository.

pip install pre-commit
pre-commit install

Example .pre-commit-config.yaml:

repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.6.0
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format

Why it matters: It creates a quality gate that runs automatically, not only when someone remembers.

8. 🔐 `pip-audit` — Find Vulnerable Dependencies

Dependency security is no longer optional. pip-audit checks your installed packages against known vulnerabilities.

pip install pip-audit
pip-audit

You can also audit a requirements file:

pip-audit -r requirements.txt

Why it matters: It is a quick security win for side projects, SaaS apps, and production APIs.

9. 📊 `py-spy` — Profile Python Without Changing Code

Performance problems are hard to solve if you are guessing. py-spy lets you profile a running Python process.

pip install py-spy
py-spy top --pid 12345
py-spy record -o profile.svg -- python app.py

Why it matters: You can see where time is actually going instead of optimizing random functions.

10. 🗂️ `typer` — Build Clean Python CLIs Fast

If you need to build your own command-line apps, typer is one of the best choices. It is built on Click and uses type hints beautifully.

pip install typer

import typer

app = typer.Typer()

@app.command()
def hello(name: str):
    print(f"Hello {name}")

if __name__ == "__main__":
    app()

Run it:

python app.py hello Alice

Why it matters: Internal automation scripts become easier to maintain when they have proper arguments, help text, and validation.

My Recommended Setup

If you want the highest productivity boost with the least setup, start with this combo:

pip install uv ruff pytest rich httpie pre-commit pip-audit

Then add a basic workflow:

ruff format .
ruff check --fix .
pytest
pip-audit

That gives you formatting, linting, testing, and security scanning in minutes.

Final Thoughts

The Python ecosystem is moving toward faster, more integrated developer tooling. Tools like uv and ruff show how much speed matters, while pre-commit, pip-audit, and py-spy help teams ship safer and more reliable code.

You do not need to adopt everything at once. Pick one tool from this list, add it to your daily workflow, and measure how much time it saves.

Check out my AI Prompt Packs: https://payhip.com/b/ADsQI | https://payhip.com/b/6lqVh | https://payhip.com/b/XLNPm | https://payhip.com/b/CAN9Z

Layering data sources: accept both APIs as fallback, don't choose one

Can Ceylan — Tue, 12 May 2026 12:36:49 +0000

The single-source problem

You pick one free data API for financial information. It works well most of the time. But:

Some companies report through non-standard channels and the API misses them
Cash flow data for certain sectors is systematically wrong
The API rate-limits you and returns empty data without saying so
A company restructuring causes a gap in the data for 2–3 weeks

Your analysis breaks silently for affected companies. You don't know which ones until you manually check.

The layering pattern

Instead of choosing one source, define a priority order:

def get_cash_flow(ticker: str) -> float | None:
    # 1. Try the primary source
    primary = fetch_from_primary_api(ticker, "freeCashFlow")
    if primary is not None:
        return primary

    # 2. Fall back to secondary source (e.g. official regulatory filings)
    secondary = fetch_from_sec_filings(ticker, "FreeCashFlow")
    if secondary is not None:
        return secondary

    # 3. No data available
    return None

The primary source handles the majority of cases. The secondary source catches the gaps. Neither source needs to be perfect — together they cover more of the space.

Why "fallback" is better than "merge"

A tempting alternative is to merge data from both sources — average them, or take the max, or reconcile differences. This is more complex and introduces new failure modes: what if the two sources disagree significantly? Which one is right?

The fallback pattern is simpler: primary is trusted if available; secondary is used only when primary is absent. You never have to reconcile disagreement because you never look at the secondary if the primary gave you something.

Rate limit isolation

Two sources also means two rate limit buckets. If the primary API rate-limits you, the secondary is unaffected. You can fetch from the secondary while the primary recovers.

for ticker in tickers:
    data = get_data_with_fallback(ticker)
    process(data)
    time.sleep(2)  # still rate-limit between requests

The sleep still applies — you're still making requests to external APIs. But the sleep now protects two APIs simultaneously, and a rate limit on one doesn't stop the pipeline entirely.

Logging which source was used

For debugging and data quality monitoring, log which source provided each data point:

@dataclass
class DataPoint:
    value: float | None
    source: str  # "primary", "secondary", "none"
    ticker: str
    metric: str

This lets you answer: "what percentage of our data is coming from the fallback?" A high fallback rate for a specific metric signals that the primary source has a systematic gap there.

When to add a third source

Two sources cover most gaps. Add a third only when:

You have a specific metric that both primary and secondary miss for a meaningful portion of your universe
The third source requires significantly different authentication or rate limiting
You've measured the gap and it materially affects your analysis

Don't add sources speculatively. Each additional source adds maintenance overhead and the possibility of new failure modes. Add them in response to measured gaps, not anticipated ones.

The principle

Resilience in data pipelines comes from redundancy, not from finding the perfect single source. Accept that any single free API will have gaps. Layer sources to fill the gaps, log which source filled each gap, and monitor the distribution over time.

When the bug isn't a bug: diagnosing runtime barriers before debugging

Can Ceylan — Tue, 12 May 2026 12:36:42 +0000

The pattern that wastes days

You need a capability — web scraping, image processing, ML inference. You reach for your existing stack. You try library A, it fails. You try library B, same class of error. You try a workaround, it partially works. You try another workaround. Three days later you have a brittle solution held together with patches.

The diagnosis that would have saved those three days: the runtime is wrong for this capability. No amount of library-switching or workaround-stacking will produce a clean solution, because the underlying problem is structural.

This is a runtime barrier — a mismatch between what your current environment can do well and what you're asking it to do.

The signal

A runtime barrier looks like:

The same error class persists across multiple different libraries
Workarounds work partially but introduce new problems
The error occurs at a level below your code (TLS, native module, OS)
The ecosystem for this capability is thin or unmaintained in your language

Common examples:

Capability	Poor-fit runtime	Symptom
Web scraping with anti-bot	Node.js	403s or empty results that Python handles fine
ML inference	Node.js / Go	No native tensor runtime; everything is a wrapper
Heavy parallel computation	Python (GIL)	CPU-bound tasks don't parallelise
Reactive UI	Python	No native component model; everything is a workaround

The diagnosis process

Step 1: Name the capability precisely.
Not "it's not working" — "I'm trying to make authenticated HTTP requests that bypass bot detection." Precise naming lets you assess fit against known ecosystem strengths.

Step 2: Check the ecosystem.
Search for the 3 most popular libraries for this capability in your runtime. If they all have the same class of failure or are unmaintained, that's an ecosystem gap, not a library bug.

Step 3: Cross-reference with a reference runtime.
Does the capability work cleanly in another language? If Python's requests + anti-bot library handles this in 10 lines, and Node.js has no equivalent after 3 library attempts, the gap is real.

Step 4: State the barrier clearly.
"This is a runtime barrier. Node.js is the wrong tool for anti-bot scraping. No amount of debugging will fix this — the ecosystem gap is fundamental."

This is a hard sentence to say, especially after investment in a particular approach. It's also the sentence that unblocks progress.

The architectural response

Once you've diagnosed a barrier, the solution is a service boundary — not a workaround.

A service boundary means: let each capability live in the runtime best suited to it, and define a clean interface between them.

Option A — separate process: The capability runs as a standalone process in the right runtime. It writes results to a shared database or communicates via HTTP. Your main application reads from the database. No shared runtime, no compromise.

Option B — purpose-built script: For scheduled or batch work, a standalone script in the right language is called by your scheduler. It doesn't live in your main application at all.

What you don't do: embed the capability as a subprocess call (python script.py from Node.js, exec(), shell-out). This creates two runtimes with two package managers, two test runners, and deployment confusion. It looks like a solution and is actually a maintenance problem.

Document the barrier

Once a runtime barrier is diagnosed and resolved, document it:

## Runtime Barrier — [date]

**Capability:** Anti-bot web scraping
**Runtime attempted:** Node.js
**Failure:** All tested libraries produced empty results against DataDome protection
**Resolution:** Python scraper process writes to shared SQLite; Node.js reads from it
**Do not re-attempt:** Node.js scraping for this target — the barrier is structural

This entry prevents a future developer (or a future version of yourself) from re-attempting the same failed approach and re-discovering the same barrier from scratch.

Kreuzberg & SurrealDB: from unstructured documents to hybrid retrieval

Mark Gyles — Tue, 12 May 2026 12:35:55 +0000

Author: Ignacio Paz

We’re excited to share a new partner integration: kreuzberg-surrealdb, a connector that bridges the Kreuzberg document intelligence framework directly into SurrealDB. This integration was created by the Kreuzberg team and we are excited to have this functionality available now in SurrealDB.

Kreuzberg extracts, chunks, and generates embeddings from 88+ document formats, while SurrealDB provides a multi-model database for AI applications, combining documents, graphs, vectors, and full-text search in a single system.

Together, they make it easy to build document search and RAG pipelines.

What the integration does

kreuzberg-surrealdb handles the full ingestion workflow:

Automatic schema setup
Content deduplication using SHA-256 hashing
Storage and indexing in SurrealDB
Documents ready for search immediately after ingest

The integration supports two modes:

DocumentConnector:indexes full documents for BM25 keyword search.
DocumentPipeline:chunks documents, generates embeddings, and enables semantic and hybrid search using HNSW vector indexes and Reciprocal Rank Fusion.

Why it matters

Building document search systems often requires combining multiple tools for extraction, chunking, embeddings, and storage.

With kreuzberg-surrealdb, the entire workflow runs through a single integration—no schema boilerplate, no duplicate ingestion, and built-in support for keyword, semantic, and hybrid search.

Get started

See how to get started in SurrealDB Docs: Kreuzberg Integration, and check out our example of How to build a knowledge graph for AI with SurrealDB and Kreuzberg.

Spring Security with Spring Boot Actuator: the authorization model that survived the incident

Juan Torchia — Tue, 12 May 2026 12:30:23 +0000

Spring Security with Spring Boot Actuator: the authorization model that survived the incident

68% of security misconfigs in Spring Boot come from configuration that looks secure because it doesn't throw an error. Yeah, read that again. No exception, no warning in the log, nothing. The endpoint just responds 200 and you don't find out until someone else does.

That's exactly what happened in the case I described in the previous post. Actuator running in production, /env and /metrics returning data without asking for credentials — all because Spring Boot 3's default configuration doesn't lock down what you don't know about. We closed the misconfigured endpoints. But closing them wasn't enough — the authorization model that remained was inherited, implicit, and fragile. It had to be rebuilt.

My thesis is this: an inherited-by-default authorization model is technically worse than an explicit one, even if both produce the same observable behavior today. Because the first one will break when you update a dependency or add a new endpoint. The second one will scream.

The problem with the SecurityFilterChain we had

Before the incident, the Spring Boot 3 + Java 21 backend had no SecurityFilterChain dedicated to Actuator. It depended on the default behavior of Spring Security 6 and properties in application.yml. The result was predictable in hindsight: any change in the Spring Boot version could break the security contract without the build catching it.

This is what you don't want to have:

# ❌ Ambiguous configuration — what you do NOT want
management:
  endpoints:
    web:
      exposure:
        include: "*"  # exposes EVERYTHING — terrible in production
  endpoint:
    health:
      show-details: always  # stack traces and details to anyone

Spring Boot with include: "*" exposes /actuator/env, /actuator/heapdump, /actuator/threaddump, /actuator/loggers, and a long list. With show-details: always, the health endpoint returns datasource details, dependency status, and internal error messages to any IP.

The problem wasn't just "who can see what?". It was that the model wasn't explicit. Nobody could read the code and understand the security intent without knowing the default behavior of Spring Boot for that specific version.

The resulting SecurityFilterChain: before/after with real code

The rebuild started with a design decision: Actuator needs its own SecurityFilterChain, separate from the application's main chain. Spring Security 6 with Spring Boot 3.x supports this natively with @Order.

// SecurityConfig.java
// Dedicated chain for Actuator — explicit order before the main app chain
@Bean
@Order(1) // Processed before the app chain
public SecurityFilterChain actuatorSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        // Only applies to Actuator routes
        .securityMatcher("/actuator/**")
        .authorizeHttpRequests(auth -> auth
            // Public health only for Railway/k8s probe — no internal details
            .requestMatchers("/actuator/health/liveness").permitAll()
            .requestMatchers("/actuator/health/readiness").permitAll()
            // General health without details — useful for load balancer
            .requestMatchers("/actuator/health").permitAll()
            // Info public — only what we explicitly configure in application.yml
            .requestMatchers("/actuator/info").permitAll()
            // Metrics, env, loggers — ACTUATOR_ADMIN only
            .requestMatchers("/actuator/metrics/**").hasRole("ACTUATOR_ADMIN")
            .requestMatchers("/actuator/env/**").hasRole("ACTUATOR_ADMIN")
            .requestMatchers("/actuator/loggers/**").hasRole("ACTUATOR_ADMIN")
            // Everything else in Actuator — also requires ACTUATOR_ADMIN
            .anyRequest().hasRole("ACTUATOR_ADMIN")
        )
        // Actuator doesn't need CSRF — it's an internal API
        .csrf(csrf -> csrf.disable())
        // HTTP Basic auth for private endpoints — over HTTPS only
        .httpBasic(Customizer.withDefaults())
        // No session state in Actuator
        .sessionManagement(session ->
            session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
        );

    return http.build();
}

// Main application chain — order 2, processes everything else
@Bean
@Order(2)
public SecurityFilterChain appSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/public/**").permitAll()
            .anyRequest().authenticated()
        )
        // ... rest of app configuration
        ;

    return http.build();
}

The @Order(1) is critical. Without it, Spring Security can apply the wrong chain to Actuator routes depending on bean initialization order — another example of implicit behavior that bites you when you least expect it.

application.yml: what gets exposed and what doesn't

The SecurityFilterChain controls who can access. But if the endpoint isn't even enabled, even better: smaller attack surface.

# application.yml — explicit Actuator configuration
management:
  endpoints:
    web:
      # ✅ Explicit whitelist — only what we actually need
      exposure:
        include:
          - health
          - info
          - metrics
          - loggers
          - env
        # heapdump and threaddump — disabled in production
        # too risky, too much sensitive information in a dump
        exclude:
          - heapdump
          - threaddump
          - httptrace
  endpoint:
    health:
      # No details on general health — UP/DOWN only
      show-details: never
      # Kubernetes/Railway probes separated
      probes:
        enabled: true
      group:
        # Liveness group — only what's critical for the process to be alive
        liveness:
          include:
            - livenessState
          show-details: never
        # Readiness group — datasource + external dependencies
        readiness:
          include:
            - readinessState
            - db
          show-details: never
    # Info: only what we explicitly decide to expose
    info:
      enabled: true
  info:
    env:
      enabled: false  # Don't expose environment variables in /actuator/info
    git:
      mode: simple   # Only commit hash and branch — not the full history

The heapdump point deserves a separate note: a heap dump from a digital identity backend contains tokens, hashed passwords, session data, and potentially cryptographic keys in memory. There is no production use case that justifies that endpoint being exposed — not even behind authentication. We disabled it completely.

Real validation: how to confirm the lockdown actually worked

This is what frustrates me most about generic security posts: they explain the configuration but don't show how to verify that the lockdown actually worked. Because "it works" in dev with spring.profiles.active=dev means nothing for production.

The validation procedure I used, reproducible with any backend:

# 1. Verify that public endpoints respond without credentials
curl -s -o /dev/null -w "%{http_code}" https://my-backend.railway.app/actuator/health
# Expected: 200

curl -s -o /dev/null -w "%{http_code}" https://my-backend.railway.app/actuator/health/liveness
# Expected: 200

curl -s -o /dev/null -w "%{http_code}" https://my-backend.railway.app/actuator/info
# Expected: 200

# 2. Verify that private endpoints reject without credentials
curl -s -o /dev/null -w "%{http_code}" https://my-backend.railway.app/actuator/metrics
# Expected: 401 (not 200, not 403 with details)

curl -s -o /dev/null -w "%{http_code}" https://my-backend.railway.app/actuator/env
# Expected: 401

# 3. Verify that disabled endpoints don't exist
curl -s -o /dev/null -w "%{http_code}" https://my-backend.railway.app/actuator/heapdump
# Expected: 404 (not 401 — the endpoint doesn't exist, it's not just protected)

# 4. Verify access with valid credentials for ACTUATOR_ADMIN
curl -s -u "actuator-admin:SECURE_PASSWORD" \
  https://my-backend.railway.app/actuator/metrics \
  | jq '.names[:5]'
# Expected: list of available metrics

# 5. Verify that incorrect credentials return 401, not useful information
curl -s -u "admin:wrong" https://my-backend.railway.app/actuator/metrics
# Expected: 401 with no body containing error details

Point 3 is the most important and the most commonly skipped: there's a real difference between an endpoint that returns 401 and one that returns 404. If /actuator/heapdump returns 401, it exists but is protected. If it returns 404, the endpoint is disabled — attack surface effectively eliminated, not just covered.

Common mistakes when configuring this in Spring Boot 3

Mistake 1: Trusting management.server.port as security

Moving Actuator to an internal port (e.g., 8081) looks like a solution, but on Railway, Fly.io, or any platform where ports are mapped dynamically, that "internal port" can end up exposed anyway. It's not a replacement for authorization — it's a network layer you don't fully control.

Mistake 2: Using hasAuthority instead of hasRole

Spring Security 6 automatically prefixes roles with ROLE_ when you use hasRole("ACTUATOR_ADMIN"). If you mix hasAuthority("ACTUATOR_ADMIN") and hasRole("ACTUATOR_ADMIN") in the same chain, you'll get inconsistent behavior that's a nightmare to debug. Pick one and be consistent throughout the entire model.

Mistake 3: The Actuator chain without securityMatcher

If you create a SecurityFilterChain for Actuator without securityMatcher("/actuator/**"), Spring Security will apply it to all routes according to order. @Order(1) without the matcher is a ticking time bomb.

Mistake 4: show-details: when_authorized with the wrong model

when_authorized seems like the balanced option, but its behavior depends on who is "authorized" according to Spring Security at that moment. If authorization isn't properly configured, it can show details to authenticated app users who shouldn't be seeing datasource state. never for the public endpoint, always only on the protected endpoint — that's more predictable.

Mistake 5: Not checking what /actuator/env actually exposes

The /env endpoint on a typical backend exposes environment variables, Spring properties, and resolved values. That includes DATABASE_URL, JWT_SECRET, REDIS_PASSWORD — any variable you've defined in the environment. Even behind authentication, you need to think carefully about who holds the ACTUATOR_ADMIN role in production.

FAQ: Spring Boot Actuator Security and Spring Security in production

Why do I need a separate SecurityFilterChain for Actuator instead of just properties in application.yml?

The management.endpoints properties control which endpoints are enabled and exposed. The SecurityFilterChain controls who can access them and with what credentials. They're two orthogonal layers. You can disable an endpoint from application.yml and Spring Security never sees it — that's fine. But relying only on properties without an explicit chain means your security behavior is coupled to the defaults of whichever version of Spring Boot you're running, which change between minor versions.

What role should the ACTUATOR_ADMIN user have?

In Spring Security 6, hasRole("ACTUATOR_ADMIN") expects the user to have the authority ROLE_ACTUATOR_ADMIN. If you manage users in a database, that role needs to exist separately from your application roles. Ideally it's a dedicated technical user, with credentials rotated periodically, used only for internal observability — never the same user the app uses at runtime.

How do I handle Railway or Kubernetes health probes without exposing internal details?

With Spring Boot 3's health groups: management.endpoint.health.group.liveness and management.endpoint.health.group.readiness. Each group exposes /actuator/health/liveness and /actuator/health/readiness respectively. These can be public (permitAll() in the chain) with show-details: never — they only return {"status":"UP"} or {"status":"DOWN"} with zero internal detail. The general health at /actuator/health can also be public but equally detail-free.

Is it safe to have /actuator/info public?

Depends on what you expose in that endpoint. By default, Spring Boot can expose the Java version, the Spring Boot version, Git information, and environment variables prefixed with info.. That last one is the problem: if you have INFO_SOMETHING=sensitive_value in your environment, it can show up. With management.info.env.enabled: false and management.info.git.mode: simple you can have a public /actuator/info that only returns commit hash, branch, and artifact version — enough for operational debugging, nothing sensitive.

How do I integrate this with an API Gateway that already handles authentication?

If the backend sits behind a gateway (Kong, AWS API Gateway, your own Nginx), the temptation is to assume the gateway protects everything and relax the backend's authorization model. Don't. The defense in depth principle says every layer has to be secure independently. The gateway can go down, can be misconfigured, can have a bypass. The backend has to survive on its own.

How do I validate that Spring Security is actually processing Actuator routes and not the wrong chain?

With Spring Security's debug log. Enable logging.level.org.springframework.security: DEBUG in a staging environment, make a request to /actuator/metrics without credentials, and look in the log for which SecurityFilterChain was selected. You'll see something like Trying to match request against ... DefaultSecurityFilterChain. If the chain that shows up isn't the Actuator one, your @Order or securityMatcher is wrong. That's the only reliable diagnostic.

My take after rebuilding this

Locking down endpoints isn't enough. Spring Boot's inherited-by-default authorization model is fine for demos and small projects, but in any backend where the data matters, it's technical debt with an unknown expiration date.

What's still standing after rebuilding this is a model where every rule has an explicit intent that's readable in the code. Anyone who opens the SecurityFilterChain can understand what's protected, why, and with what credentials — without needing to know the defaults of the specific Spring Boot version being used.

If you're running Spring Boot Actuator in production and you've never written an explicit SecurityFilterChain for it, now is the time. Not because you're going to have an incident tomorrow — but because when the incident does come, you'll want the explicit model already in production, not be rebuilding it under pressure.

For the broader context of how I handle infrastructure security across different layers of the stack, you can also check out the encryption analysis with Themis vs Web Crypto API and the post on Jakarta EE vs Spring Boot in real production backends.

Original source:

Spring Boot Docs — Securing HTTP Endpoints: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints.security

This article was originally published on juanchi.dev

Spring Security con Spring Boot Actuator: así quedó el modelo de autorización después del incidente

Juan Torchia — Tue, 12 May 2026 12:30:18 +0000

Spring Security con Spring Boot Actuator: así quedó el modelo de autorización después del incidente

El 68% de los misconfigs de seguridad en Spring Boot vienen de configuración que parece segura porque no tira error. Sí, leíste bien. No hay excepción, no hay warning en el log, no hay nada. El endpoint simplemente responde 200 y vos no te enterás hasta que alguien más lo encuentra.

Eso es exactamente lo que pasó en el caso que describí en el post anterior. Actuator corriendo en producción, /env y /metrics devolviendo datos sin pedir credenciales, todo porque la configuración por default de Spring Boot 3 no cierra lo que no conocés. Cerramos los endpoints mal configurados. Pero cerrarlos no fue suficiente — el modelo de autorización que quedó era heredado, implícito y frágil. Había que rehacerlo.

Mi tesis es esta: un modelo de autorización heredado por default es técnicamente peor que uno explícito, incluso si los dos producen el mismo comportamiento observable hoy. Porque el primero va a romperse cuando actualices una dependencia o agregues un endpoint nuevo. El segundo va a gritar.

El problema con el SecurityFilterChain que teníamos

Antes del incidente, el backend de Spring Boot 3 con Java 21 no tenía ningún SecurityFilterChain dedicado a Actuator. Dependía del comportamiento default de Spring Security 6 y de las propiedades en application.yml. El resultado era predecible en retrospectiva: cualquier cambio en la versión de Spring Boot podía romper el contrato de seguridad sin que el build lo detectara.

Esto es lo que no tenías que tener:

# ❌ Configuración ambigua — lo que NO querés
management:
  endpoints:
    web:
      exposure:
        include: "*"  # expone TODO — terrible en producción
  endpoint:
    health:
      show-details: always  # stacktraces y detalles a cualquiera

Spring Boot con include: "*" expone /actuator/env, /actuator/heapdump, /actuator/threaddump, /actuator/loggers y una lista larga. Con show-details: always, el health endpoint devuelve detalles del datasource, estado de dependencias y mensajes de error internos a cualquier IP.

El problema no era solo "¿quién puede ver qué?". Era que el modelo no era explícito. Nadie podía leer el código y entender la intención de seguridad sin conocer el comportamiento default de Spring Boot para esa versión específica.

El SecurityFilterChain resultante: antes/después con código real

La reconstrucción empezó con una decisión de diseño: Actuator necesita su propio SecurityFilterChain, separado del chain principal de la aplicación. Spring Security 6 con Spring Boot 3.x lo soporta nativamente con @Order.

// SecurityConfig.java
// Chain dedicado para Actuator — orden explícito antes del chain principal
@Bean
@Order(1) // Procesado antes que el chain de la app
public SecurityFilterChain actuatorSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        // Solo aplica a rutas de Actuator
        .securityMatcher("/actuator/**")
        .authorizeHttpRequests(auth -> auth
            // Health público solo para el probe de Railway/k8s — sin detalles internos
            .requestMatchers("/actuator/health/liveness").permitAll()
            .requestMatchers("/actuator/health/readiness").permitAll()
            // Health general sin detalles — útil para load balancer
            .requestMatchers("/actuator/health").permitAll()
            // Info público — solo lo que configuramos explícitamente en application.yml
            .requestMatchers("/actuator/info").permitAll()
            // Métricas, env, loggers — solo ACTUATOR_ADMIN
            .requestMatchers("/actuator/metrics/**").hasRole("ACTUATOR_ADMIN")
            .requestMatchers("/actuator/env/**").hasRole("ACTUATOR_ADMIN")
            .requestMatchers("/actuator/loggers/**").hasRole("ACTUATOR_ADMIN")
            // Todo lo demás de Actuator — también requiere ACTUATOR_ADMIN
            .anyRequest().hasRole("ACTUATOR_ADMIN")
        )
        // Actuator no necesita CSRF — es una API interna
        .csrf(csrf -> csrf.disable())
        // Autenticación HTTP Basic para endpoints privados — sobre HTTPS únicamente
        .httpBasic(Customizer.withDefaults())
        // Sin estado de sesión en Actuator
        .sessionManagement(session ->
            session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
        );

    return http.build();
}

// Chain principal de la aplicación — orden 2, procesa el resto
@Bean
@Order(2)
public SecurityFilterChain appSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/public/**").permitAll()
            .anyRequest().authenticated()
        )
        // ... resto de la configuración de la app
        ;

    return http.build();
}

El @Order(1) es crítico. Sin él, Spring Security puede aplicar el chain equivocado a las rutas de Actuator dependiendo del orden de inicialización de beans — otro ejemplo de comportamiento implícito que muerde cuando menos lo esperás.

application.yml: lo que se expone y lo que no

El SecurityFilterChain controla quién accede. Pero si el endpoint ni siquiera está habilitado, mejor: superficie de ataque más chica.

# application.yml — configuración de Actuator explícita
management:
  endpoints:
    web:
      # ✅ Lista blanca explícita — solo lo que realmente necesitamos
      exposure:
        include:
          - health
          - info
          - metrics
          - loggers
          - env
        # heapdump y threaddump — deshabilitados en producción
        # demasiado riesgo, demasiada información sensible en un dump
        exclude:
          - heapdump
          - threaddump
          - httptrace
  endpoint:
    health:
      # Sin detalles en el health general — solo UP/DOWN
      show-details: never
      # Probes de Kubernetes/Railway separados
      probes:
        enabled: true
      group:
        # Grupo liveness — solo lo crítico para que el proceso esté vivo
        liveness:
          include:
            - livenessState
          show-details: never
        # Grupo readiness — datasource + dependencias externas
        readiness:
          include:
            - readinessState
            - db
          show-details: never
    # Info: solo lo que decidimos exponer explícitamente
    info:
      enabled: true
  info:
    env:
      enabled: false  # No exponer variables de entorno en /actuator/info
    git:
      mode: simple   # Solo commit hash y branch — no la historia completa

El punto sobre heapdump merece una nota aparte: un heap dump de un backend de identidad digital contiene tokens, contraseñas hasheadas, datos de sesión y potencialmente claves criptográficas en memoria. No hay ningún caso de uso en producción que justifique ese endpoint expuesto, ni detrás de autenticación. Lo deshabilitamos completamente.

Validación real: cómo confirmar que el cierre funcionó

Esto es lo que me da más bronca de los posts de seguridad genéricos: explican la configuración pero no muestran cómo verificar que el cierre realmente funcionó. Porque "funciona" en dev con spring.profiles.active=dev no significa nada para producción.

El procedimiento de validación que usé, reproducible con cualquier backend:

# 1. Verificar que los endpoints públicos responden sin credenciales
curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/health
# Esperado: 200

curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/health/liveness
# Esperado: 200

curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/info
# Esperado: 200

# 2. Verificar que los endpoints privados rechazan sin credenciales
curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/metrics
# Esperado: 401 (no 200, no 403 con detalles)

curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/env
# Esperado: 401

# 3. Verificar que los endpoints deshabilitados no existen
curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/heapdump
# Esperado: 404 (no 401 — el endpoint no existe, no está protegido)

# 4. Verificar acceso con credenciales válidas para ACTUATOR_ADMIN
curl -s -u "actuator-admin:PASSWORD_SEGURO" \
  https://mi-backend.railway.app/actuator/metrics \
  | jq '.names[:5]'
# Esperado: lista de métricas disponibles

# 5. Verificar que credenciales incorrectas dan 401, no información útil
curl -s -u "admin:wrong" https://mi-backend.railway.app/actuator/metrics
# Esperado: 401 sin body con detalles del error

El punto 3 es el más importante y el que más se omite: hay diferencia entre un endpoint que devuelve 401 y uno que devuelve 404. Si /actuator/heapdump devuelve 401, existe pero está protegido. Si devuelve 404, el endpoint está deshabilitado — superficie de ataque efectivamente eliminada, no solo cubierta.

Los errores comunes al configurar esto en Spring Boot 3

Error 1: Confiar en management.server.port como seguridad

Mover Actuator a un puerto interno (ej: 8081) parece una solución, pero en Railway, Fly.io o cualquier plataforma donde los puertos se mapean dinámicamente, ese "puerto interno" puede terminar expuesto igual. No es un reemplazo de autorización — es una capa de red que no controlás completamente.

Error 2: Usar hasAuthority en lugar de hasRole

Spring Security 6 prefija automáticamente los roles con ROLE_ cuando usás hasRole("ACTUATOR_ADMIN"). Si mezclás hasAuthority("ACTUATOR_ADMIN") y hasRole("ACTUATOR_ADMIN") en el mismo chain, vas a tener comportamientos inconsistentes que son un quilombo para debuggear. Elegí uno y sé consistente en todo el modelo.

Error 3: El chain de Actuator sin securityMatcher

Si creás un SecurityFilterChain para Actuator sin securityMatcher("/actuator/**"), Spring Security lo va a aplicar a todas las rutas según el orden. El @Order(1) sin el matcher es una bomba de tiempo.

Error 4: show-details: when_authorized con el modelo equivocado

when_authorized parece la opción equilibrada, pero su comportamiento depende de quién es "autorizado" según Spring Security en ese momento. Si la autorización no está bien configurada, puede mostrar detalles a usuarios autenticados de la app que no deberían ver el estado del datasource. never para el endpoint público, always solo en el endpoint protegido, es más predecible.

Error 5: No revisar qué expone /actuator/env específicamente

El endpoint /env en un backend típico expone variables de entorno, propiedades de Spring y valores resueltos. Eso incluye DATABASE_URL, JWT_SECRET, REDIS_PASSWORD — cualquier variable que hayás definido en el entorno. Incluso detrás de autenticación, hay que pensar bien quién tiene el rol ACTUATOR_ADMIN en producción.

FAQ: Spring Boot Actuator Security y Spring Security en producción

¿Por qué necesito un SecurityFilterChain separado para Actuator y no solo propiedades en application.yml?

Las propiedades de management.endpoints controlan qué endpoints están habilitados y expuestos. El SecurityFilterChain controla quién puede acceder a ellos y con qué credenciales. Son dos capas ortogonales. Podés deshabilitar un endpoint desde application.yml y que Spring Security nunca lo vea — eso está bien. Pero confiar solo en propiedades sin un chain explícito significa que el comportamiento de seguridad está acoplado a los defaults de la versión de Spring Boot que estés usando, que cambian entre versiones menores.

¿Qué rol debería tener el usuario de ACTUATOR_ADMIN?

En Spring Security 6, hasRole("ACTUATOR_ADMIN") espera que el usuario tenga la autoridad ROLE_ACTUATOR_ADMIN. Si manejás usuarios en base de datos, ese rol tiene que existir separado de los roles de la aplicación. Lo ideal es que sea un usuario técnico dedicado, con credenciales rotadas periódicamente, usado solo para observabilidad interna — nunca el mismo user que usa la app en runtime.

¿Cómo manejo los health probes de Railway o Kubernetes sin exponer detalles internos?

Con los health groups de Spring Boot 3: management.endpoint.health.group.liveness y management.endpoint.health.group.readiness. Cada grupo expone /actuator/health/liveness y /actuator/health/readiness respectivamente. Estos pueden ser públicos (permitAll() en el chain) con show-details: never — solo devuelven {"status":"UP"} o {"status":"DOWN"} sin ningún detalle interno. El health general en /actuator/health también puede ser público pero igualmente sin detalles.

¿Es seguro tener /actuator/info público?

Depende de qué exponés en ese endpoint. Por default, Spring Boot puede exponer la versión de Java, la versión de Spring Boot, información de Git y variables de entorno marcadas con el prefijo info.. El problema es el último punto: si tenés INFO_ALGO=valor_sensible en el entorno, puede aparecer. Con management.info.env.enabled: false y management.info.git.mode: simple podés tener un /actuator/info público que solo devuelve commit hash, branch y versión del artifact — suficiente para debugging operacional, nada sensible.

¿Cómo integro esto con un API Gateway que ya maneja autenticación?

Si el backend está detrás de un gateway (Kong, AWS API Gateway, un Nginx propio), la tentación es asumir que el gateway protege todo y relajar el modelo de autorización del backend. No lo hagas. El principio de defensa en profundidad dice que cada capa tiene que ser segura independientemente. El gateway puede caerse, puede estar mal configurado, puede tener un bypass. El backend tiene que sobrevivir solo.

¿Cómo valido que Spring Security realmente está procesando las rutas de Actuator y no el chain equivocado?

Con el log de debug de Spring Security. Activá logging.level.org.springframework.security: DEBUG en un entorno de staging, hacé un request a /actuator/metrics sin credenciales y buscá en el log qué SecurityFilterChain fue seleccionado. Vas a ver algo como Trying to match request against ... DefaultSecurityFilterChain. Si el chain que aparece no es el de Actuator, el @Order o el securityMatcher está mal. Es el único diagnóstico confiable.

Mi postura después de reconstruir esto

No alcanza con cerrar endpoints. El modelo de autorización heredado por default de Spring Boot es suficiente para demos y proyectos chicos, pero en cualquier backend donde los datos importan, es una deuda técnica con fecha de vencimiento desconocida.

Lo que quedó en pie después de reconstruir esto es un modelo donde cada regla tiene una intención explícita legible en el código. Cualquier persona que entre al SecurityFilterChain puede entender qué está protegido, por qué y con qué credenciales — sin necesidad de conocer los defaults de la versión específica de Spring Boot que se esté usando.

Si estás usando Spring Boot Actuator en producción y nunca escribiste un SecurityFilterChain explícito para él, este es el momento de hacerlo. No porque vayas a tener un incidente mañana — sino porque cuando llegue el incidente, vas a querer tener el modelo explícito ya en producción, no estar reconstruyéndolo bajo presión.

Para el contexto más amplio de cómo manejo seguridad de infraestructura en distintas capas del stack, podés ver también el análisis de cifrado con Themis vs Web Crypto API y el post sobre Jakarta EE vs Spring Boot en backends reales.

Fuente original:

Spring Boot Docs — Securing HTTP Endpoints: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints.security

Este artículo fue publicado originalmente en juanchi.dev

Top 11 Identity Orchestration Tools and Platforms for 2026

Dwayne McDaniel — Tue, 12 May 2026 12:23:46 +0000

TL;DR: Identity orchestration unifies fragmented IAM environments by connecting identity providers, directories, access policies, and governance workflows into a single, automated control plane. The top identity orchestration tools in 2026 fall into several categories: identity orchestration engines, IAM platforms with orchestration capabilities, identity governance and lifecycle platforms, and secrets security and NHI exposure prevention. Most enterprises need an orchestration layer to unify identity flows and a secrets security layer to ensure credentials and non-human identities (NHIs) aren't compromised.

Why Identity Orchestration Is a Top Priority in 2026

For context, the average enterprise manages identities across 5 to 10+ identity providers, directories, and access management systems.

The result? Fragmented access policies, inconsistent lifecycle management, identity blind spots, and a sprawling attack surface. This is especially true for non-human identities (NHIs) that slip through the cracks of traditional IAM.

This is why identity orchestration — the practice of connecting, coordinating, and automating identity management across multiple systems through a unified control plane — is so important. Rather than ripping and replacing your existing identity stack, identity orchestration software sits above it, enforcing consistent policies, automating lifecycle workflows, and centralizing visibility across all connected systems.

The Need for Identity Orchestration Software

Multi-cloud and hybrid identity sprawl. Organizations running workloads across AWS, Azure, GCP, and on-premises end up with disconnected identity silos.
Legacy-to-modern IAM migration complexity. Many companies run critical applications on legacy systems that depend on LDAP or on-premises Active Directory.
SaaS and third-party integration explosion. Every SaaS tool comes with its own identity requirements.
Non-human identity proliferation. API keys, service accounts, OAuth tokens, and certificates now outnumber human identities in most enterprise environments.
Zero-trust architecture requirements. Zero trust demands continuous verification and centralized policy enforcement across every identity interaction.
Compliance complexity. Meeting SOC 2, ISO 27001, and PCI DSS requirements across a multi-vendor IAM stack creates significant overhead without a centralized governance layer.

The NHI Blind Spot in Identity Orchestration

Identity orchestration platforms manage identity flows and access policies. But these tools can't detect if the credentials moving through said flows are compromised. If an API key was hardcoded in a repository two years ago and has been sitting exposed in git history ever since, rotating it through an orchestration workflow would only partially help until someone finds and remediates the original leak.

This is why it's important to integrate a dedicated secrets security platform like GitGuardian with the specific identity orchestration solution you choose.

Key Capabilities of Modern Identity Orchestration Platforms

1. Identity Unification and Fabric Architecture — Connect multiple identity providers, directories, and cloud IAM systems through a single control plane with protocol normalization across SAML, OIDC, OAuth, SCIM, and LDAP.

2. Workflow Automation and No-Code Orchestration — Visual workflow builders for identity journeys, provisioning, deprovisioning, and lifecycle events.

3. Multi-Cloud and Hybrid Support — Cross-cloud identity federation, on-premises app bridging, and Kubernetes support.

4. Non-Human Identity Coverage — Service account discovery, API key and token lifecycle orchestration, machine identity visibility.

5. Governance, Compliance, and Audit — Centralized audit trails, compliance reporting for SOC 2/ISO 27001/PCI DSS, risk scoring and access reviews.

Top Identity Orchestration Tools for 2026

1. Strata Identity

Category: Identity orchestration and identity fabric platform

Strata Identity pioneered the "identity fabric" approach. The platform abstracts identity infrastructure into a unified orchestration layer, helping companies modernize legacy apps, consolidate multi-cloud identities, and enforce consistent policies without rip-and-replace migrations.

Pros: True identity fabric approach with strong multi-IdP unification. Excellent for legacy-to-modern migration. Strong multi-cloud and hybrid support.

Cons: Not focused on secrets exposure detection. Organizations should layer secrets security tooling to cover leaked credentials passing through orchestration workflows.

Enterprise Fit: Ideal for large enterprises with complex, multi-IdP environments undergoing legacy IAM modernization. Website: strata.io

2. Ping Identity (PingOne DaVinci)

Category: No-code identity orchestration engine

PingOne DaVinci lets identity teams build adaptive authentication flows and visual identity journeys without custom development, with a library of connectors for IdPs, MFA providers, and fraud detection tools.

Pros: Powerful no-code orchestration with mature connector ecosystem. Adaptive access and risk-based authentication. Well-integrated with the Ping Identity platform.

Cons: Best within the Ping ecosystem. No secrets exposure detection.

Enterprise Fit: Strong for enterprises already in the Ping ecosystem. Website: pingidentity.com

3. Simeio

Category: Managed identity orchestration services

Simeio combines an identity orchestrator platform with managed identity services, connecting disparate IAM platforms like Okta, Azure AD, and SailPoint.

Pros: Managed-service model reduces operational burden. Good multi-vendor IAM unification.

Cons: May not suit organizations preferring self-service platforms.

Enterprise Fit: Quality for enterprises needing managed orchestration across multiple IAM vendors. Website: simeio.com

4. Auth0 (Okta)

Category: Developer-centric identity platform with orchestration capabilities

Auth0 provides a developer-first identity platform with flexible orchestration through its "Actions and Rules" framework. Strong support for Machine-to-Machine (M2M) authentication via OAuth2 client credentials flow.

Pros: Very developer-friendly. Flexible Actions framework. Strong community and marketplace ecosystem.

Cons: Orchestration is code-driven, requiring developer involvement. Not a multi-IdP fabric.

Enterprise Fit: Excellent for developer-led organizations and SaaS companies. Website: auth0.com

5. Microsoft Entra ID (Azure AD)

Category: Enterprise IAM platform with orchestration and governance

Microsoft Entra ID provides identity orchestration through conditional access policies, identity governance workflows, and workload identity management as part of the Microsoft ecosystem.

Pros: Deep Microsoft/Azure integration. Strong conditional access and governance. Native workload identity support.

Cons: Limited for multi-vendor, multi-IdP orchestration outside Azure. No secrets exposure scanning.

Enterprise Fit: Essential for Microsoft-centric enterprises. Website: microsoft.com/en-us/security/business/identity-access/microsoft-entra-id

6. TrustBuilder

Category: European identity orchestration and access management

TrustBuilder emphasizes European data sovereignty and GDPR-aligned identity governance with a visual workflow editor and adaptive authentication.

Pros: Strong visual workflow orchestration. Good fit for European enterprises with data sovereignty requirements.

Cons: Smaller ecosystem than US-based platforms. Limited NHI exposure visibility.

Enterprise Fit: Suitable for European enterprises needing orchestration with GDPR compliance. Website: trustbuilder.com

7. Tech Prescient (Identity Confluence)

Category: Customized identity orchestration and automation

Tech Prescient offers Identity Confluence, a customizable orchestration platform with white-glove implementation services for complex enterprise requirements.

Pros: Highly customizable. Strong consulting support. Good hybrid coverage.

Cons: More services-oriented than a pure SaaS product.

Enterprise Fit: Good for enterprises with complex, customized requirements. Website: techprescient.com

8. SailPoint

Category: Identity governance and orchestration platform

SailPoint is a leading IGA platform that has expanded into identity orchestration with workflow automation, AI-driven access recommendations, and support for both human and non-human identities.

Pros: Market-leading IGA capabilities. AI-driven access governance insights. Broad connector ecosystem.

Cons: More IGA than dedicated orchestration. No secrets exposure detection.

Enterprise Fit: Quality choice for enterprises needing IGA as their orchestration foundation. Website: sailpoint.com

9. Saviynt

Category: Cloud-native identity governance and orchestration

Saviynt provides cloud-native IGA with orchestration capabilities, integrating IGA and PAM capabilities with continuous risk scoring.

Pros: Strong cloud-native architecture. Good IGA + PAM integration. Risk-based analytics.

Cons: More IGA than orchestration. Less focused on developer workflows and secrets exposure.

Enterprise Fit: Solid for cloud-first enterprises needing IGA with orchestration and PAM. Website: saviynt.com

10. ConductorOne

Category: Identity security and access orchestration

ConductorOne automates access reviews, streamlines provisioning, and provides an identity graph showing who has access to what across SaaS and cloud apps.

Pros: Fast to deploy with a modern, lightweight approach. Strong automated access reviews. Good NHI visibility for service accounts.

Cons: Still-growing connector ecosystem. Less focused on legacy/on-premises identity. No secrets exposure detection.

Enterprise Fit: Great for modern, cloud-first teams. Website: conductorone.com

11. Okta (Workforce Identity Cloud)

Category: Enterprise IAM platform with orchestration workflows

Okta's Workforce Identity Cloud provides SSO, adaptive MFA, lifecycle management, and identity governance through Okta Workflows — a no-code automation engine with 7,000+ pre-built integrations.

Pros: Massive integration ecosystem. Powerful no-code Workflows engine. Strong adaptive MFA.

Cons: Orchestration stays within the Okta ecosystem. No secrets exposure detection or NHI credential scanning.

Enterprise Fit: Best for enterprises already using Okta as a primary IdP. Website: okta.com

The Secrets Security Layer Every Orchestration Stack Needs

None of the tools above offer secrets security and NHI exposure intelligence — using them in isolation weakens your security posture.

GitGuardian

Category: Secrets security and NHI exposure intelligence for identity orchestration

GitGuardian is an enterprise-grade secrets security and NHI exposure platform that provides the critical security layer identity orchestration stacks need. While orchestration platforms unify and automate identity flows, GitGuardian ensures the credentials, API keys, tokens, and service account secrets moving through those flows aren't compromised.

Core Features: Internal Secrets Monitoring, Public Secrets Monitoring, NHI Governance, CI/CD Pipeline Scanning (via ggshield), Collaboration Tool Coverage (Slack/Jira/Confluence/Teams), Vault Integration (HashiCorp Vault, CyberArk), Agentic AI Security.

Enterprise Fit: Essential for any large company deploying identity orchestration and wanting to ensure credentials flowing through their workflows are secure and properly governed.

Website: gitguardian.com

Implementation Strategy for Enterprise Identity Orchestration

Phase 1: Identity Discovery and Orchestration Deployment — Inventory all identity providers and federated trust relationships. Deploy orchestration aligned with your architecture. Bridge legacy and modern identity protocols.

Phase 2: Credential Hygiene and Secrets Exposure Remediation — Scan all repositories (including full git history), CI/CD pipelines, and collaboration tools for leaked secrets. Identify and remediate hardcoded credentials. Deploy continuous secrets monitoring.

Phase 3: NHI Governance and Continuous Monitoring — Discover and inventory all non-human identities. Automate secret rotation and certificate renewal. Enforce least-privilege for all NHIs. Establish clear ownership models across AppSec, IAM, and Platform Engineering.

The Future of Identity Orchestration

Identity fabric convergence — Dedicated orchestration platforms, IGA tools, and PAM solutions are converging into unified platforms.
AI-driven orchestration — Autonomous identity workflows and adaptive policy recommendations driven by ML.
Non-human identity as a first-class concern — As machine identities proliferate across Kubernetes, CI/CD, and agentic AI systems, platforms without strong NHI coverage will fall short.
Secrets security integration becomes standard — Detection of exposed credentials is moving from a specialized function to an expected orchestration layer.
Decentralized and verifiable identity — New cross-organization federation patterns without centralized identity stores.

If you're currently deploying identity orchestration workflows, secure the credentials that flow through them. Book a demo of GitGuardian to see how our platform fits into your identity security strategy.

I built my own programming language at 19 — Akro (runs in the browser, no install)

Ankit bishnoi — Tue, 12 May 2026 12:22:20 +0000

Who am I?

I'm Ankit Bishnoi, 19 years old from India.

Skills: JavaScript, TypeScript, React, HTML/CSS, Python, MongoDB, SQL, Ethical Hacking, Social Media.

GitHub: @ankitkhileryy

What I built

Akro — a minimal programming language that runs entirely in the browser.

The name comes from my initials "AK". Personal name, universal language.

No install needed → try it now: akro-lang.dev/playground

What it looks like


akro
fn main {
  name := "World"
  say "Hello, {name}!"

  nums := [1, 2, 3, 4, 5]
  total := reduce(nums, fn(a, b) { return a + b }, 0)
  say "Sum = {total}"

  grade := match 87 {
    case 90..100 { "A" }
    case 80..89  { "B" }
    case _       { "C or below" }
  }
  say "Grade: {grade}"
}

Auditing 1,000 French SMB sites: the top technical tier captures 4.2x the sector median in organic traffic

J-Christophe C. — Tue, 12 May 2026 12:21:50 +0000

Over several months, we audited 1,000 French SMB sites using a unified protocol — same criteria, same tools, same thresholds. The goal: identify what actually separates sites capturing organic traffic from sites that stagnate. The results are sharper than we expected.

The headline number

Technically top-tier sites — those that pass Core Web Vitals, carry valid structured data, and use a coherent semantic architecture — capture on average 4.2x the sector-median organic traffic. Not 20% more. Not double. Over four times.

This gap does not close with isolated content pushes or ad campaigns. It widens month over month because technical signals compound. Sites starting late watch competitors consolidate.

Three major findings

Average SEO score for French SMBs sits at 43/100. That is low. The majority of sites have meaningful gaps, and clearing 60/100 is enough to stand out in most sectors.
Average mobile Lighthouse score: 42/100. Only 18% clear Google's "Good" threshold. Core Web Vitals have been a ranking signal since 2021, yet most French SMB sites continue to ignore them. For a competitor willing to invest, this is a structural opportunity.
Over 65% of agency-built sites shipped with structural SEO errors. Duplicate title tags, missing structured data, flat architecture, uncompressed images. Signals that a large portion of the agency market sells design and dev without integrating acquisition.

Laggard sectors are the biggest opportunities

Sector disparities are pronounced. Legal sits in the bottom three with law firm averages near 28/100. Construction/trades barely reaches 29/100 despite huge local search volumes. Healthcare professions also trail.

These lags are not anomalies — they are opportunities. Operators in these sectors who invest seriously in SEO can reach page one in months because organic competition is thinner. ROI is mechanically faster than in saturated sectors.

What the top 18% actually do differently

Analyzing sites scoring above 65/100, five patterns appear consistently:

Semantic silo architecture — not an administrative site map, but a mesh of pages organized by search intent
Core Web Vitals validated in real-user conditions, not just Lighthouse-in-dev-tools
Regular editorial publishing — minimum 2 articles per month
Contextual internal linking — at least 3 internal links per content page, pointing to other pages in the same silo
Structured data matched to content type, tested and valid

None of these is expensive. All are systematically neglected by sites that plateau.

The compounding power of regular content

One number worth isolating: companies publishing at least 2 articles per month saw organic traffic grow by 67% over 12 months on average. This is not the explosive outliers — it is the average for disciplined publishers. Modest but consistent editorial output produces steady compound growth.

Sites publishing episodically, without a structured content plan, stagnate or decline. SEO rewards continuity, not sprints.

Launch quality determines the trajectory

Among sites reaching strong SEO levels, the vast majority applied a complete checklist at launch. Sites launched without verification reach their first meaningful organic traffic roughly 6 weeks later on average. That starting gap hardens into a structural gap that is hard to recover.

📖 This article is a summary of our full study. Read the detailed analysis on Clickzou — Auditing 1,000 French SMB sites: the top technical tier captures 4.2x the sector median in organic traffic

How to Auto-Unlock LUKS2 Encrypted Disks at Boot with Clevis and Tang

Fatih Şennik — Tue, 12 May 2026 12:21:45 +0000

The Problem

Full disk encryption is great — until you reboot a headless server at 3am and realize you need to type a passphrase with no keyboard attached. Every reboot now requires manual passphrase entry. That's... not great when your server is a headless VM sitting in a datacenter rack in another city.

Enter Clevis and Tang. Together they let your server auto-unlock its LUKS2 volume at boot — but only when it can reach your Tang server on the network. No Tang server reachable? No unlock. It's elegant and your data is safe even if someone walks off with the physical server.

How Clevis talks to Tang (and why it's clever)

During boot, Clevis contacts Tang and initiates a JOSE/JWK key exchange. What makes this secure is what doesn't happen — your LUKS passphrase is never transmitted, Tang gains zero knowledge of the disk key, and the derived secret exists only in RAM long enough to unlock the volume. The wire traffic reveals nothing useful to an attacker and the Tang server never sees your LUKS passphrase; it just participates in the math.

Let's say that Tang server is unreachable, then Clevis gets no response, the key exchange fails, and the disk stays locked. You can still fall back to a manual passphrase, which is a separate LUKS keyslot you keep as a backup.

Keep a backup passphrase keyslot! Clevis adds its own keyslot but doesn't touch your existing passphrase. Keep it. Store it in your password manager. If Tang ever goes down permanently you'll need it. LUKS supports multiple keyslots for exactly this reason.

Installing Tang on your secure key server which is located in different location.

Tang runs as a simple systemd socket service. It's lightweight — It functions solely as a key exchange endpoint, requiring no database and no configuration files other than the key material it generates automatically. it automatically generates its key material in /var/db/tang/. That's it. No config needed.

apt-get update

apt install tang jose

# Enable and start
systemctl enable --now tangd.socket

# Change its port to any. Example: 9102
nano /lib/systemd/system/tangd.socket

systemctl daemon-reload

# Verify it's running
curl 127.0.0.1:9102/adv

Keep the server security hardened via a separated network segment and a secure random port. The /adv endpoint returns Tang's public key advertisement as JSON. If you can curl it, Clevis can reach it during boot. If you can't, neither can Clevis — fix your firewall first.

Installing Clevis on your luks encrypted server.

apt-get update

apt install clevis clevis-luks clevis-initramfs clevis-systemd

# Find your LUKS2 device
# Replace /dev/sda3 with your actual LUKS partition
cryptsetup luksDump /dev/sda3

# Check your manual passphrase before reboot!
cryptsetup --test-passphrase --key-slot 0 open /dev/sda3

# Bind your LUKS2 device to Tang key server
# it will ask for your existing LUKS passphrase
# Then will fetch Tang's public key and add a new keyslot for LUKS partition.
clevis luks bind -d /dev/sda3 tang '{"url":"http://your-tang-server-ip:9102"}'

When you run that bind command, Clevis contacts Tang, fetches its public key, generates a random key, encrypts it using Tang's key material, stores the encrypted blob in the LUKS2 token metadata, and registers it as a new keyslot. The actual decryption key never leaves your machine unencrypted.

Before embedding Clevis into your boot process, check your network interface name — it could be ens192, eth0, or something similar.

ip a | grep -E "^[0-9]+:"

⚠️ Important Gotcha: To avoid the "network isn't up yet" issue during boot, check how your server receives its IP address.

Clevis needs to reach Tang before the root filesystem mounts — but if your network interface isn't up yet, the whole thing silently fails and drops you to a passphrase prompt.

Open /etc/netplan/50-cloud-init.yaml and verify whether your server is configured for a static IP or DHCP.

Open initramfs

nano /etc/initramfs-tools/initramfs.conf

# and add this to end of the file if your server is configured for static ip
IP=SERVER_IP::SERVER_GATEWAY_IP:SERVER_SUBNET::NETWORK_INTERFACE_NAME:none

# if your server is configured for dhcp then
BOOT=network
DEVICE=NETWORK_INTERFACE_NAME (ens192)
IP=dhcp

# Update your boot process
sudo update-initramfs -u -k all

Wait before rebooting. Test !

# Try to unlock manually using Clevis 
clevis luks unlock -d /dev/sda3 
# Check if Tang server is reachable
curl http://your-tang-server:9102/adv

And that's all there is to it. Your disk will now decrypt and unlock automatically during boot, no manual intervention required.

DEV Community

I Built Rust-Style ADTs in 30 Lines of Python (Pattern Matching Works)

The result first

The whole implementation

What is happening

Why this beats the alternatives

Caveats

When to reach for this

Building an Offline-First Exchange Calculator with Vanilla JavaScript

1. Why I used Vanilla JavaScript

2. URL-driven country presets (briefly)

3. Live rates with a safe fallback

4. PWA-style caching

5. DOM caching for repeated updates

6. What I would improve next

Final thoughts

10 CLI Tools Every Python Developer Should Know in 2025

10 CLI Tools Every Python Developer Should Know in 2025

1. 🐍 uv — The Future of Python Package Management

2. 🦀 ruff — Instant Python Linting & Formatting

3. 📦 pipdeptree — Visualize Your Dependency Tree

4. 🧪 pytest — Testing Made Painless

5. 🔍 rich — Beautiful Terminal Output

6. 🌍 httpie — Human-Friendly API Testing

7. 🧹 pre-commit — Stop Bad Code Before Git Commit

8. 🔐 pip-audit — Find Vulnerable Dependencies

9. 📊 py-spy — Profile Python Without Changing Code

10. 🗂️ typer — Build Clean Python CLIs Fast

My Recommended Setup

Final Thoughts

Layering data sources: accept both APIs as fallback, don't choose one

The single-source problem

The layering pattern

Why "fallback" is better than "merge"

Rate limit isolation

Logging which source was used

When to add a third source

The principle

When the bug isn't a bug: diagnosing runtime barriers before debugging

The pattern that wastes days

The signal

The diagnosis process

The architectural response

Document the barrier

Kreuzberg & SurrealDB: from unstructured documents to hybrid retrieval

What the integration does

Why it matters

Get started

Spring Security with Spring Boot Actuator: the authorization model that survived the incident

Spring Security with Spring Boot Actuator: the authorization model that survived the incident

The problem with the SecurityFilterChain we had

The resulting SecurityFilterChain: before/after with real code

application.yml: what gets exposed and what doesn't

Real validation: how to confirm the lockdown actually worked

Common mistakes when configuring this in Spring Boot 3

FAQ: Spring Boot Actuator Security and Spring Security in production

My take after rebuilding this

Spring Security con Spring Boot Actuator: así quedó el modelo de autorización después del incidente

Spring Security con Spring Boot Actuator: así quedó el modelo de autorización después del incidente

El problema con el SecurityFilterChain que teníamos

El SecurityFilterChain resultante: antes/después con código real

application.yml: lo que se expone y lo que no

Validación real: cómo confirmar que el cierre funcionó

Los errores comunes al configurar esto en Spring Boot 3

FAQ: Spring Boot Actuator Security y Spring Security en producción

Mi postura después de reconstruir esto

Top 11 Identity Orchestration Tools and Platforms for 2026

Why Identity Orchestration Is a Top Priority in 2026

The Need for Identity Orchestration Software

The NHI Blind Spot in Identity Orchestration

Key Capabilities of Modern Identity Orchestration Platforms

Top Identity Orchestration Tools for 2026

1. Strata Identity

2. Ping Identity (PingOne DaVinci)

3. Simeio

4. Auth0 (Okta)

5. Microsoft Entra ID (Azure AD)

6. TrustBuilder

7. Tech Prescient (Identity Confluence)

8. SailPoint

1. 🐍 `uv` — The Future of Python Package Management

2. 🦀 `ruff` — Instant Python Linting & Formatting

3. 📦 `pipdeptree` — Visualize Your Dependency Tree

4. 🧪 `pytest` — Testing Made Painless

5. 🔍 `rich` — Beautiful Terminal Output

6. 🌍 `httpie` — Human-Friendly API Testing

7. 🧹 `pre-commit` — Stop Bad Code Before Git Commit

8. 🔐 `pip-audit` — Find Vulnerable Dependencies

9. 📊 `py-spy` — Profile Python Without Changing Code

10. 🗂️ `typer` — Build Clean Python CLIs Fast