Conduktor Self-service lets application teams request Kafka topics and access without going through the platform team for every change. Platform teams set the rules upfront; everything else flows from there.Documentation Index
Fetch the complete documentation index at: https://docs.conduktor.io/llms.txt
Use this file to discover all available pages before exploring further.
How it works
Self-service introduces two roles:- Platform teams — assign application’s owner a set of resources and define the governance rules they will be restricted by.
- Application teams — create resources within their ownership scope, approve access requests, and subscribe to other teams’ topics. Approved requests are applied automatically without platform team intervention for each change.
Key concepts
| Concept | Description |
|---|---|
| Application | A logical grouping for a team or service — owns its topics and ACLs |
| Application team | Group of people interacting with an application’s resources, organized into ApplicationGroups with explicit resource and instance permissions (e.g., support team with read access, devOps team with API key creation rights) |
| Access request | A request for read or write access to a topic owned by another application |
| Policy | Rules that constrain what teams can request (e.g., max partitions, naming conventions) |
| Ownership | Each resource has a declared owner. Access management (requesting and granting) is delegated to ApplicationGroup members with the appropriate instance permissions |
Benefits
- Less bottleneck — teams don’t wait on platform for routine requests
- Guardrails, not gatekeeping — policies constrain what can be requested, not who can work
- Full audit trail — every change is in Git, reviewable and revertible
- Explicit ownership — each resource has a declared owner, so access requests go to the right person
- Data discovery — Kafka is made to open access to data. Our data catalog is here for that and exposes topics metadata to add context