Why We Built OrbitMesh

The story of a problem we kept running into until we decided to solve it ourselves.

It started with a question nobody could answer

Whenever there was a security incident or a compliance audit, the same question came up:

Can you prove that the API gateway enforced the policy at that exact moment?

That sounds like it should be an easy question. It was not.

We would go to the logs and try to piece together what happened. The logs showed that a request came in and a response went out. But they did not clearly show what the gateway actually decided.

Did the gateway reject the request because the token was invalid? Did rate limiting block it? Was an older TLS version still being accepted on a specific endpoint?

Those are important questions, but in practice the answers were often incomplete, delayed, or based on guesswork.

That gap stayed with us.

What we kept seeing in real teams

Over time, we saw the same pattern across platform, security, and compliance teams.

DevOps engineers were spending too much time after incidents trying to reconstruct gateway behavior from scattered logs.

DevSecOps teams were defining policies for authentication, TLS, and rate limiting, but they had no simple way to prove those policies were actually enforced for a specific request.

CISOs and compliance teams were walking into audits with screenshots, spreadsheets, and manual explanations. Everyone was doing their best, but the process was fragile and stressful.

The tools around the gateway were mature in some areas and missing in one important area. There were logs. There were SIEM platforms. There were dashboards. But there was no clean record of enforcement decisions at the gateway layer.

The gap we could not ignore

API gateways like NGINX sit at a critical point in the path of every request. Authentication checks happen there. TLS negotiation happens there. Rate limiting happens there. Policy matching happens there.

But the actual enforcement decision at that layer is rarely captured in a form teams can search, trust, and export.

That means when something goes wrong, teams reconstruct events from fragments.

When an auditor asks for proof, teams scramble.

When a configuration change is about to go live, teams do not always know what enforcement behavior will change.

We felt that gap directly, and we did not see a good solution for it.

So we built one.

What OrbitMesh does

OrbitMesh is an NGINX dynamic module that runs alongside your existing gateway. It does not capture request payloads or response payloads. It captures enforcement metadata.

For each request, OrbitMesh records things like:

• Authentication result
• TLS version
• Rate limit outcome
• Policy match information

That is the core idea.

Not payload inspection. Not user content. Not sensitive request bodies.

Just the enforcement record of what the gateway decided and why.

We then make that data useful through:

• Search and query tools for enforcement decisions
• Configuration change tracking with diffs
• Exportable evidence bundles for audits
• Impact analysis before rolling out gateway configuration changes

Why we built it as an NGINX module

We considered different architectures.

We could have built a separate proxy. We could have built a sidecar. We could have added another hop in the path.

We chose an NGINX dynamic module because the most accurate place to capture an enforcement decision is inside the process that is making that decision.

That choice mattered to us.

It meant no traffic rerouting, no extra network hop, and no major architectural change just to collect evidence. It also meant lower operational overhead for teams that already run NGINX in production.

Who we built it for

We built OrbitMesh for teams that live close to the operational reality of APIs.

For DevOps and platform engineers, it reduces the time spent trying to answer what the gateway did during an incident.

For DevSecOps teams, it provides a way to prove that configured policies were actually enforced.

For CISOs and compliance teams, it provides cleaner evidence for audits without turning every evidence request into an engineering fire drill.

What we are not trying to replace

OrbitMesh is not a SIEM.

It is not trying to replace Splunk, Datadog, or the rest of your existing monitoring and security stack.

Those systems already play an important role.

OrbitMesh fills a different gap. It captures enforcement decisions at the gateway and gives teams a stronger layer of proof that can feed into the systems they already use.

We are also not trying to replace compliance platforms. We are focused on the space between having a policy and being able to prove that the policy actually ran.

Why this mattered to us personally

There is also a human side to this.

A lot of important infrastructure work stays invisible until something breaks or someone asks for proof. Teams put real care into designing, enforcing, and maintaining controls, but the evidence of that work is often hard to surface when it matters most.

We wanted to make that work visible.

If a gateway enforced a policy, that should be recorded. If a configuration changed, that should be tracked. If an auditor asks for evidence, teams should be able to answer with confidence.

That belief is what led us to build OrbitMesh.

Try it

OrbitMesh is available now with a free Tryout plan.

If you run NGINX and care about enforcement visibility, visit orbitmesh.io.

If you want to talk through your setup, an upcoming audit, an incident workflow, or a configuration change process, reach out to us. We built this for teams doing real operational work in production.

• The OrbitMesh Team