Integrations
Every place a change happens, and every place its reason is written down.
Nakana is designed to read 147 sources across twelve categories. All read-only. Where you already ship logs to Datadog, Splunk or a SIEM, Nakana reads from there instead of collecting twice.
Nakana is in early access. This is our integration plan, not a list of shipped connectors. Design partners decide what we build first.
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.
CI/CD and deployment 14
The run that built and shipped the change.
Infrastructure as code and config management 12
The declared state a change should match.
Cloud platforms 12
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.
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.
Observability, logs and SIEM 11
Use the pipelines you already pay for instead of collecting twice.
Identity, HR and privileged access 16
Who the person is, what they normally do, and whether they should have had access.
Approvals, flags and secrets 11
The other places a change gets made or approved.
Nothing matches. Tell us what you run: [email protected]
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.