Adapt patterns from KongAirlines

KongAirlines is a collection of patterns that you adopt one at a time. You don’t need to install the whole platform. You can explore the repositories without a Konnect account, deployment credentials, or a running Gateway. Select a practice that solves a problem you have, learn its boundaries, and adapt it to your own delivery platform.

The example uses kongctl for Konnect resources, decK for Gateway configuration, and GitHub Actions for delivery. The practices work with other repository structures and other CI systems.

If you are new to the project, start with the repository map. To see the whole delivery sequence, follow an API change.

What it enables: teams manage their APIs and the platform team doesn’t deliver every change.

The platform repository declares shared resources and access assignments. Service repositories manage their own Catalog APIs. They use the shared Dev Portals and control planes and don’t declare duplicate copies.

Where to look:

• Platform foundations: shared resources and team roles.
• Repository access assignments: automation identity membership.
• Bookings development manifest: service-owned resources and references to shared infrastructure.

Adapt: the team boundaries, the resource topology, and the permissions to your organization. The broad Catalog API roles in the example are a starting point. They don’t isolate the APIs of one team from another.

Keep: the difference between a reference to a shared resource and ownership of it. Konnect RBAC authorizes access. Declarative namespaces identify ownership.

What it enables: developers work on an API contract, and reviewers see the Gateway configuration that the contract produces.

CI generates and tests Gateway configuration from OpenAPI and from explicit transformation inputs. A separate workflow commits the tested output to the service PR and maintains a review comment.

Where to look:

• Gateway generator: conversion and transformations.
• PR validation: generation and tests without credentials.
• Artifact materialization: branch updates and review summaries.

Adapt: your contract linting, your Gateway policies, your conversion rules, and your CI provider. Keep intentional transformations as inputs and don’t edit the generated output by hand.

Keep: the boundary between PR validation that’s untrusted and automation that has credentials. The workflow that can write makes sure that the source commit and the artifact boundaries are correct. It doesn’t run scripts that the PR controls.

What it enables: the platform team governs changes in the production traffic path, and service teams keep control of their API lifecycle.

A service workflow opens a platform PR with the exact reviewed production Gateway candidate and its provenance. Platform automation deploys the aggregate. Then it triggers the production Catalog workflow of the service from that source commit.

Where to look:

• Service promotion: copying the candidate and recording its source.
• Platform production workflow: governed Gateway delivery and Catalog dispatch.
• Service production Catalog workflow: deployment with the service identity.

Adapt: your review policies, your production topology, and your approval process. An organization can use this pattern without a separate platform repository.

Keep: the reviewed artifact and its source identity across the handoff. Do not regenerate a different candidate after approval. A service can deploy Catalog resources without production Gateway write access.

What it enables: development and production change independently, and you don’t maintain environment branches.

The example uses separate resources, files, and credentials for each stage. Development Gateway writes are scoped to the tagged configuration of one service. The platform reviews production Gateway state and synchronizes it as one aggregate.

Where to look:

• Development manifest and production manifest: explicit stage resources.
• Gateway generator: environment and ownership tags.
• Production aggregate: the synchronization boundary that the platform owns.

Adapt: the number of stages, control planes, and repositories.

Keep: explicit reconciliation scopes. Stages that synchronize independently must not prune the resources of each other. Namespaces and decK tags scope desired state. They don’t replace RBAC.

What it enables: a team chooses a release through a reviewed PR and doesn’t change version numbers inside deployment scripts.

The release workflow retains a stable contract, selects it for production, and advances the root development contract. Generation reads that selection. Older contracts stay available and the workflow doesn’t overwrite them.

Where to look:

• Release workflow: release inputs and PR creation.
• Release preparation: file transformations and production selection.
• Release validation: tests for retained releases and version changes.

Adapt: your version conventions, your compatibility tests, and your retention policy. The beta naming convention is an example choice and federation doesn’t require it.

Keep: the connection between the retained contract, the production selector, and the generated candidate. Review the release and its deployment consequences together.

What it enables: API publication includes documentation, discovery, and an application access process, in addition to Gateway routing.

The platform owns Dev Portal content and application authentication strategies. Services publish their APIs to those Dev Portals. Flights and Destinations show public access. Bookings and Customer show access with an approved application key.

Where to look:

• Shared Portal content: pages, navigation, and reusable guide snippets.
• Platform foundations: Dev Portals and application authentication strategies.
• Bookings publication: service-owned publication that uses a shared strategy.

Adapt: your audience, your Dev Portal visibility, your approval process, and your authentication strategy. Before you copy the protected API policies, read the authentication decisions.

Keep: the difference between documentation visibility and runtime authorization. An application identity is different from a passenger identity. The example service source uses fictional accounts, so it doesn’t show how a deployed upstream behaves.

Choose a small outcome, such as showing generated Gateway differences in PRs. Inspect its inputs, its workflow, its generated files, and its trust boundaries. Implement that practice in one repository and test its behavior before you extend it. That practice doesn’t need the complete KongAirlines topology or authentication design.

If you use a coding agent, give it the outcome that you selected, the linked example files, and the constraints of your repository. Ask it to explain the dependencies and the tests before it proposes changes. The optional Reference Platform skill gives the agent more guidance. Your own manifests and policies remain the source of truth.