KongAirlines

KongAirlines is the example implementation of the Reference Platform. Its public repositories show how service teams deliver independently while a platform team governs shared infrastructure and production Gateway changes.

The best starting points are the OpenAPI contracts, the kongctl manifests, the generated decK configuration, and the delivery workflows. You can read them without deploying the example. Use the pattern guide to choose the practices that you want to adapt. You don’t need to reproduce every repository and resource.

The platform repository represents the platform team. It owns shared Konnect infrastructure, access governance, Dev Portals, and production Gateway configuration.

Two service teams own the API repositories:

Service teams own their development and production Catalog APIs, specifications, versions, and publications. They write Gateway configuration directly to the development control plane of their team. They propose production Gateway changes through platform PRs and don’t write to the production control plane.

Read Bookings first, because it is a representative service repository. The other services follow the same delivery structure. Flights is a good contrast because it has a public API.

• OpenAPI contract: the current development design.
• Konnect manifests: service-owned Catalog state and references to shared infrastructure.
• Gateway artifacts: generated development and production configuration, and the policy inputs.
• Workflows: validation, development delivery, release preparation, and production promotion.

To see how these files connect in sequence, follow an API change.

In the platform repository, compare the shared foundations with the references that the service makes to those resources. Then read the production Gateway configuration to see the reviewed service artifacts and their provenance.

The production delivery workflow shows how platform approval leads to Gateway synchronization. After synchronization, the workflow dispatches production Catalog delivery to the service that owns the change.

The platform also owns the Portal pages and navigation. Publications that the services own connect API delivery to discovery and application access. The source of the protected services uses fictional accounts that belong to an application. It doesn’t use passenger login.

The Gateway delivery workflows don’t deploy the application source. The source shows the identity contract. It doesn’t show how an existing upstream deployment behaves.

The repository topology, the version conventions, and the authentication strategy are example decisions. You can adopt API-first PR review without the same Portal or control plane topology. Start with a pattern that addresses your needs. For design tradeoffs, read the FAQ.