# Kyma Modules for Kubernetes Cloud-Native Applications > Kyma is a set of opinionated Kubernetes building blocks for building, connecting, exposing, and observing cloud-native applications. Its current model emphasizes independently delivered modules rather than a single monolithic runtime. **kyma-project/kyma** — Kyma is an opinionated set of Kubernetes-based modular building blocks, including all necessary capabilities to develop and run enterprise-grade cloud-native applications. - Repository: https://github.com/kyma-project/kyma - Website: https://kyma-project.io - Stars: 1,559 · Forks: 398 - Language: Go - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/kyma-project-kyma ## Kyma's Module Model and Intended Users Kyma addresses teams that need to assemble cloud-native applications from Kubernetes-based components instead of building every supporting capability from first principles. The README describes it as an opinionated set of modular building blocks for developing and running enterprise-grade applications. It also positions Kyma as an open path into the SAP ecosystem and as a foundation for SAP BTP's Kyma runtime. The intended users are therefore more specific than general Kubernetes users. Application teams may need serverless execution, API exposure, connectivity to external systems, service-to-service communication, cloud service management, or telemetry collection. Platform teams may need a supported collection of components that can be connected through a Kubernetes runtime. The project can run in a user's own Kubernetes cluster, while SAP BTP offers a managed version with a ready-to-use Kubernetes cluster powered by Gardener. That positioning also exposes the main adoption boundary. Kyma is not simply a Go library or a standalone application. It is a collection of deployment-oriented modules around Kubernetes. Its value depends on whether the organization already uses Kubernetes and needs the integration choices Kyma packages. ## What the Kyma Modules Cover The README names several functional areas, and each one represents a separate concern in an application platform. The Serverless module runs lightweight Functions in a cost-efficient and scalable way. The System Connectivity module exposes an endpoint for registering events and APIs belonging to external applications. Istio handles service-to-service communication and proxying. These modules address execution, integration, and networking as distinct responsibilities. Other components cover platform operations. The Service Management module provides access to built-in services from cloud providers including GCP, Azure, and AWS. The API Gateway module provides secure API exposure. The Telemetry module collects telemetry data and sends it to observability backends. The README also mentions a CLI and an intuitive UI used to connect an application to a Kubernetes cluster. This breadth is useful when a team wants a coherent application platform, but it also means Kyma is not a minimal deployment. Selecting one module does not make the rest irrelevant in an enterprise design. Teams still need to decide how workloads authenticate, how APIs are routed, how telemetry reaches its backend, and how external systems are registered. ## Kyma's Modular Delivery Shift and Upgrade Implications The README contains an important change in scope: global Kyma releases have been discontinued. It says that each module now develops and delivers functionality independently, and that users should subscribe to individual module repositories. The former monolithic Kyma installation is therefore not the documented path for current users. This change affects upgrade planning. A team cannot assume that upgrading the main repository upgrades every capability at once. Module versions and delivery cycles need to be tracked separately. The README provides links to module documentation and module repositories, but it does not document compatibility rules, rollback procedures, or a complete upgrade matrix. Those omissions matter for an application platform that combines functions, gateways, connectivity, networking, and telemetry. The repository has a recent last push date of 2026-09-28, but the listed releases are 2.20.0 from 2023-11-08, 2.20.0-rc1 from 2023-11-03, and 2.19.3 from 2023-10-30. The release history shown here does not, by itself, establish the current release cadence of every individual module. Maintenance assessment should therefore focus on the selected module repositories and their compatibility requirements rather than the existence of the older Kyma tags. ## Installing Kyma Through the Documented Quick Install Path The README does not provide a local installation command for Kyma. It directs users to the Kyma project's Quick Install guide when the goal is to install Kyma with specific modules. That is the only confirmed installation instruction. The first practical use begins by choosing the modules required for the application and following the linked Quick Install guide. The separate examples repository is also documented as a source of ready-to-use code snippets for testing extensions and core functionality. The README does not describe the exact commands for deploying those examples, so a complete application walkthrough cannot be reproduced from the repository excerpt alone. The repository contains documentation tooling for developing the Kyma documentation site. The following command starts the VitePress development server, as defined in package.json. It is useful for contributors working on the documentation rather than as a production installation of Kyma itself. ## A First Documentation Workflow For a contributor who wants to work on the repository's documentation, package.json defines four scripts. `docs:dev` starts VitePress, `docs:build` runs the public-directory preparation step before building, `docs:build2` builds the site directly, and `docs:preview` previews a built site. The normal local documentation loop starts with the development command. A reader should expect the VitePress site to open through the command's configured development server. The README does not document a fixed port, so no port can be specified here. The build command is more involved because it runs `sh ./move_to_public.sh` and removes `docs/public` after the build. The scripts also reveal that this repository contains more than Go services. Its top-level entries include `docs/`, `.vitepress/`, JavaScript configuration, and `package.json`. That matters when estimating maintenance: documentation changes can involve VitePress, Prettier, Husky, and lint-staged even when the primary project language is Go. ## Kyma Compared With Direct Kubernetes Composition A direct Kubernetes approach can be compared with Kyma by looking at where integration responsibility sits. In a direct composition, an engineering team selects and configures the workload runtime, ingress or gateway, service mesh, external connectivity, secrets, and observability components itself. Kyma packages a set of opinionated choices around those concerns and presents them as modules. The difference is not that Kyma makes Kubernetes unnecessary. Its modules remain Kubernetes-based, so a Kyma deployment still depends on cluster administration and operational practices. The difference is the starting point. Kyma provides named modules for serverless execution, API exposure, system connectivity, service management, Istio, and telemetry, while a direct approach begins with separate infrastructure decisions and integrations assembled by the adopter. That convenience can also become a constraint. An organization that requires a particular gateway, service mesh policy, telemetry backend, or cloud-provider integration may need to check whether the module can be adapted. The README does not document those integration limits, so the module documentation is the relevant source for evaluating them. ## Operational Boundaries and Licensing Kyma's enterprise orientation does not remove normal distributed-systems concerns. Function execution, API exposure, external application registration, service-to-service proxying, cloud service access, and telemetry delivery each introduce configuration and failure modes. The README identifies the capabilities, but it does not specify failure behavior, observability retention, quota behavior, rollback support, or the operational responsibility for each module. The project is released under Apache-2.0, and the repository includes `LICENSE`, `LICENSES/`, and `NOTICE.md` files. This identifies the stated licensing and notices associated with the repository. It does not answer how a particular SAP BTP service, cloud provider service, or third-party module is licensed. Those dependencies require separate review when an application combines Kyma with managed platform services or external systems. The practical boundary is organizational as much as technical. Kyma fits teams that can operate Kubernetes modules and accept the SAP-oriented ecosystem. It is less suitable for a team seeking a small self-contained Go application, a single-purpose function runner, or a gateway with no platform requirements. ## Conclusion Adopt individual Kyma modules when you need Kubernetes-native application capabilities and can manage module integration in your own cluster or SAP BTP environment. Do not treat the former Kyma releases as a current monolithic installation path, and verify module compatibility, documentation coverage, and operational ownership before deployment. ## FAQ ### What is Kyma used for? Kyma provides Kubernetes-based modular building blocks for developing and running cloud-native applications. Its documented modules cover functions, system connectivity, Istio, cloud service management, API exposure, telemetry, and cluster connection workflows. ### Can I install Kyma as one monolithic runtime? The README says global Kyma releases are discontinued and that individual Kyma module repositories are delivered independently. It directs current users to the Kyma Modules documentation rather than to a monolithic installation. ### Where can I run Kyma modules? The README says modules can be used in your own Kubernetes cluster. It also mentions a managed version in SAP BTP with a ready-to-use Kubernetes cluster powered by Gardener. ## Sources - [kyma-project/kyma on GitHub](https://github.com/kyma-project/kyma) - [License: Apache-2.0](https://github.com/kyma-project/kyma/blob/main/LICENSE) - [Project website](https://kyma-project.io) - [README](https://github.com/kyma-project/kyma/blob/main/README.md) - [Releases](https://github.com/kyma-project/kyma/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kyma-project-kyma