Integrations

Every place a change happens, and every place its reason is written down.

Nakana is designed to read 161 sources across 13 categories. All read-only. No agent on your servers. Click any integration to see how it connects, what Nakana reads and the access you'd grant.

Nakana is in early access. This is our integration plan, not a list of shipped connectors. Design partners decide what we build first.

How Nakana connects

Pull by default. Push where it's faster. No agent on your servers.

You never have to send Nakana anything to get started. It pulls from your systems with read-only credentials and back-fills history. Where a source can push events as they happen, Nakana takes them in seconds. The only thing Nakana sends out is what you ask for: verdicts on change tickets, questions in Slack, events to your SIEM.

Pull

Nakana polls the source's API with read-only credentials you create. History is back-filled when you connect.

Push

The source sends events to Nakana as they happen: webhooks, event streams or log forwarding. Seconds, not minutes.

Via log platform

Nakana reads these events from Datadog, Splunk, Elastic or your SIEM, where you already send them. Nothing new to install.

Relay

For systems that aren't reachable from the internet. One small relay container in your network makes outbound-only HTTPS connections. No inbound ports.

Collector

Optional. Our lightweight collector, only for hosts whose telemetry doesn't already reach a log platform or EDR.

Public feed

Public data Nakana downloads itself. Nothing to configure.

Connects by

Change and incident management 12

Where the reason is written down: change requests, approvals, windows, incidents.

Source control 6

The code behind a change, who wrote it and who reviewed it. Branch protection and repo settings changes are changes too.

CI/CD and deployment 14

The run that built and shipped the change, and who triggered it. Edits to pipelines themselves are tracked as changes.

Infrastructure as code and config management 12

The declared state a change should match. Anything changed outside these tools is a ClickOps candidate.

Cloud platforms 14

Control-plane changes and the identity that made them.

Kubernetes and containers 12

What changed in the cluster and whether GitOps put it there.

Servers, kernel and endpoints 16

File, package, service, user and kernel changes on the machine itself. Most of this already reaches your log platform or EDR, so Nakana reads it there.

Databases and data platforms 12

Schema, grant, role and parameter changes, and who ran them.

Network and security devices 13

Line-level config diffs and the session that made them. Most network gear sits behind the relay.

Observability, logs and SIEM 11

Use the pipelines you already pay for instead of collecting twice. This is how Nakana sees host, kernel and database logs without an agent.

Identity, HR and privileged access 16

Who the person is, what they normally do, and whether they should have had access. This is how Nakana knows people, not just accounts.

Vulnerability and software composition 12

Nakana isn't a scanner. It reads the findings your existing tools already produce, then tells the person making a change when it touches a library or host with a known CVE, especially one on CISA's Known Exploited Vulnerabilities list.

Approvals, flags and secrets 11

The other places a change gets made or approved.

Don't see your stack?

Tell us what you run. Anything with an audit log, an API or a syslog feed can be a source.

Request an integrationGet early access