Give teams self-serve delivery and day-two operations on Azure Kubernetes Service while IT retains control of identity, workspace boundaries, secrets and audit.
Control plane and workloads run inside your Azure subscription.
A live deployment view—not a mockup.
Runs on your Azure stack
Delivery, governance and operations stay connected instead of becoming separate tools, tickets and permission models.
Teams deploy applications, Helm platforms and scheduled jobs from approved registries and repositories through one repeatable delivery path.
Identity, workspace roles, ownership and namespace rules determine what each team can see and change. Application secrets stay in Azure Key Vault.
Developers and operators inspect health, review logs and events, scale services, restart deployments and respond to alerts from one interface.
Inside the platform
Explore real Enkindlr screens. Select a capability to see how teams deliver and operate workloads inside the boundaries IT defines.
Give every team a governed operating boundary. Membership, roles, workloads, integrations, pipelines and alerts remain scoped to the active workspace.
Select the image to inspect it full screen.Developers, scripts and coding agents such as Claude Code and Codex can use the CLI or REST API. They authenticate, select a workspace and operate only within the permissions assigned to that identity.
Use a dashboard-issued token or the optional browser flow, then select the target cluster and workspace.
The CLI and documented API expose deployments, pipelines, platforms, jobs, integrations and operations.
The workload appears in the product interface and state-changing operations enter the same audit trail.
Web, CLI and API—one authorization model, one workspace boundary, one operational record.
Enkindlr is deployed to customer-controlled AKS. Its control-plane data, identities, registries, secrets and application data remain within the customer’s Azure environment.
| Product area | Available capabilities |
|---|---|
| Workloads | Container applications, Helm platforms, CronJobs, resources, environment variables, SSO and deployment history |
| Delivery | Azure DevOps and GitHub pipelines, webhooks, polling, build logs, image promotion and continuous deployment |
| Governance | Entra ID, platform RBAC, workspace roles, ownership, namespace claims, audit and optional network isolation |
| Operations | Status, scaling, restarts, rollback, logs, Kubernetes events, resource details and cluster drill-down |
| Integrations | AKS, ACR, Azure DevOps, GitHub, Key Vault, Azure Monitor and PostgreSQL/MySQL providers |
| AI controls | Model registry, versions, lifecycle status, gateway keys, revocation and usage records |
| Alerting | Kubernetes and Prometheus conditions with Teams, Slack, email and webhook notifications |
| Automation | Python CLI, REST API, OpenAPI contract, bearer authentication and workspace scoping |
Planned: Native MCP tool service and in-product agent creation or execution are not presented as available features.
A focused evaluation proves the complete path using your approved source repository, registry, identity and secret-management processes.
Deployment timing depends primarily on the readiness of your AKS, identity, DNS and security approvals. We confirm the implementation sequence after the prerequisite review.
Enkindlr is a self-hosted operations control plane for deploying and operating applications, Helm platforms and scheduled jobs on Azure Kubernetes Service. It also provides a registry and gateway for controlled access to registered AI models.
The control plane runs inside your Azure subscription. The AKS cluster, container registry, Key Vault, database, identities and application data remain customer-controlled.
No. Source code remains in your existing repositories. Enkindlr connects those repositories to governed build, image-promotion, deployment and operational workflows.
Resources are scoped to workspaces. Backend-enforced membership and workspace roles control access, while Kubernetes namespaces and optional network policies provide workload-level separation.
Application secrets are stored in Azure Key Vault and mounted into workloads through the Secrets Store CSI Driver. Enkindlr retains references rather than plaintext application secret values.
Yes. Coding agents can invoke the Python CLI or REST API, subject to the same authentication, permissions and workspace scope as a human user.
Enkindlr exposes workload status, Kubernetes events, logs, cluster health and Azure Monitor managed Prometheus metrics. Alerting supports Kubernetes and custom Prometheus conditions.
A native Enkindlr MCP service and in-product agent execution are planned, not generally available today. The CLI and REST API are the supported automation interfaces.
Bring your Azure architecture questions. We’ll walk from workspace creation through source integration, deployment, day-two operations and the resulting audit trail.
