/keptn/


is a message-driven control plane for application delivery and automated operations, that allows

  • Developers to focus on code instead of creating YAML files
  • DevOps to focus on tools instead of building pipelines
  • SREs to enforce processes instead of debugging problems
Quick Start

Learn more about Keptn, its components, and its use cases

See and hear more about Keptn!

Keptn Core Features

Message-driven Control Plane

Keptn is a message-driven control plane that can be used for Application Delivery and Automated Operations. Here are two examples how Keptn orchestrates both delivery and operations. Please note that the tools that deploy, tests, monitor, etc. are left out for simplicity. This section focuses on the control-plane aspect of Keptn.

Back to top

Application Delivery

Application Delivery starts when a new artifact is available, e.g. a container that has been built in a CI pipeline has been pushed to a container registry (1). Keptn gets notified about the new artifact by either a webhook or a user that sends an event to Keptn (2). Keptn updates the project configuration in git (3) and dispatches an event to start a dark deployment (4), . After a successful deployment tests are executed (5). Keptn gathers metrics from a monitoring provider (6) and evaluates against the specified quality criteria (quality gate) and decides that the artifact gets promoted to the next stage. Keptn updates the configuration (7) and triggers a blue/green deployment (8). As before, Keptn gathers metrics (9) and finds that the metrics don't pass the specified quality gate. Keptn rolls back changes in the configuration (10) and undeploys the new artifact from the current stage (11). Eventually, Keptn notifies the user that the application delivery workflow wasn't successful.

Application Delivery


Back to top

Automated Operations

Automated Operations starts by adding service level indicators (SLI), service level objectives (SLO), and remediation instructions to the project configuration in Keptn (1)(2). Based on this information, Keptn configures the monitoring provider with alerting rules (3). As the monitoring of the application takes place (4), the monitoring provider finds that a SLO is not met anymore (5) and sends an alert to Keptn (6). Keptn finds an appropriate remediation action in the configuration (7) and executes said remediation action (8). The monitoring provider oversees the process and gives feedback if the problem has been solved (9).

Automated Operations

Back to top

Keptn for Developers

Keptn for developers

Back to top

Keptn for DevOps Engineers

Keptn for DevOps

Back to top

Keptn for SREs

Keptn for SREe

Back to top