We are thrilled to announce that we have reached a significant milestone in our journey to provide the best possible developer experience to our Kong user community. We have added a host of new functionality to decK, our declarative management tool for Kong Gateway. These new functions enhance API lifecycle automation (APIOps) capabilities and provide a smoother path to federated API management. These features are now available to everyone and can be found in decK 1.24.0.
Before looking at the new features, let's do a quick recap of API management with decK and federated management.
decK is a popular declarative management tool for Kong Gateway. With decK, users create gateway configurations in a straightforward YAML syntax and build automations for validating and synchronizing them to Kong Gateway. Typically users store these declarative configuration files in source code repositories and build automations using readily available CI/CD tools.
We have learned that as microservice architectures have emerged, users want API management to become less centralized. For example, take a development team with a very domain specific concern. They want to configure an API gateway to pass requests through a serverless function before routing it to their upstream service. Simultaneously, the centralized platform team is tasked with ensuring all APIs conform to the required security policies. What is the best way for these two teams to coordinate the API gateway's configuration while not impeding each other's progress? Federated API management is the solution that allows developer team autonomy and maintains central governance capabilities while permitting shared gateway infrastructure. Let's see how the new decK features can help.
decK file configurations are full configurations. This means, when you synchronize to the gateway, you pass the entire configuration to decK. decK detects necessary changes and enacts them via the gateway Admin API. The full configuration is beneficial as it represents the complete desired state of your gateway. However, as every developer knows, shared files lead to collaboration friction. We've introduced a set of new commands to decK that makes working with partial configurations possible, and will change the way you work with decK files.
Broadly we have introduced two new categories of commands to decK, transformations, and declarative configuration generation. Let's start with transformations.
Following the Unix philosophy of keeping components simple and composable, we have added transformations that allow you to build declarative configurations over a sequence of steps. Most developers will be familiar with piping commands on the command line:
ls -l | grep kong
This is how you will work with transformations as well. Transformations can be given a full or a partial configuration file, transform it based on user input, and generate an output that can be written to a file or passed to a subsequent transformation.
Note: All of the new commands operate on decK files only and do not connect to a running gateway. We've organized all of the new commands under a new top-level command named file.
Here is a description of each of the new transformation commands:
deck file patch [flags] [...patch-files] (documentation)
patch is used to apply a partial update to a Kong Declarative configuration using a JSONPath selector syntax. With the patch command, you can precisely target changes to any part of a configuration, without needing the entire file.
deck file merge [flags] filename [...filename] (documentation)
merge brings multiple decK files into one. Top-level arrays are merged by concatenating them and all other keys are copied. In a federated management scenario, merge is a useful stage prior to synchronization to a gateway. If you are building a complex application or an API platform for multiple teams, you will likely have multiple services and code repositories which may have their own decK configuration files. Using CI/CD pipelines, merge can help you bring the configurations together to deploy on shared gateway infrastructure.
deck file add-tags [flags] tag [...tag](documentation)
deck file remove-tags [flags] tag [...tag] (documentation)
Tags are important metadata for your Kong Gateway entities, and we’ve made managing them in your configurations a breeze. Use these transformations to add or remove tags from entities based on a JSONPath selector.
deck file add-plugins [flags] [...plugin-files] (documentation)
Plugins are a critical part of any Kong Gateway deployment, and managing them is an essential task. The add-plugins command is handy for adding plugins to objects that match a given selector or to the global top-level plugins array.
OpenAPI is the de facto standard for defining API behavior. Kong has provided the ability to generate declarative configuration from OpenAPI specifications in Insomnia, an open source API development platform since 2021. To better align with operating Kong Gateways, we are moving this functionality into decK. This allows gateway operators to use a single tool for the entire API deployment workflow.
As a result, in this release, we've added a command to generate a Kong Gateway declarative configuration from a provided OpenAPI Specification (OAS) file.
deck file openapi2kong [flags] (documentation)
The openapi2kong command is used to convert an OAS file to a Kong declarative configuration. Typically this would be the first step in a larger pipeline of delivering an API to the gateway. The documentation provides more details on the command usage and examples.
Now that we've seen the new commands added to decK, how can you use them to improve your APIOps capabilities? Using partial configurations and sequences of commands is powerful because they enable organizations to implement a federated approach to API management.
Using common CI/CD tools, you can bring various parts of the configuration together from a single repository, or across many repositories (as is common in a microservices architecture).
Each step of the pipeline is concise and single purpose, but when combined creates a powerful tool for building a full declarative state for your API gateway.
We’re thrilled to bring you these latest features, all designed to streamline APIOps workflows.
The full documentation provides the command reference and a user guide. Your feedback has been instrumental in helping us build these new capabilities, and we can’t wait to see how you’ll use them to manage your Kong configurations with greater ease and efficiency.
To provide feedback, please file an issue in the source code repository or contact your Kong representative.
The easiest way to get started with Kong Gateway is with Kong Konnect. Try these new decK features with your Konnect free trial today!
Managed Redis cache is a turnkey "Shared State" add-on for Kong Dedicated Cloud Gateways. It is designed to combine the performance of an in-memory data store with the simplicity of a SaaS product. When you spin up a Dedicated Cloud Gateway in Kong
Agents are ultimately decision makers. They make those decisions by combining intelligence with context, ultimately meaning they are only ever as useful as the context they can access. An agent that can't check inventory levels, look up customer his
The Kong MCP Registry acts as a central directory for AI agents and clients to access services that provide context or take action. For AI agents, think of it as a combination of a "Service Catalog" and a "Developer Portal." It offers the metadata,
The numbers tell a compelling story. While 65% of organizations that use APIs are currently generating revenue from them, a significant gap exists between API adoption and AI readiness. 83.2% of respondents have adopted some level of an API-first ap
Jason Cumberland , CPO and co-founder of API and data monetization platform HyperCurrent , contributed to this post. In our last article on how to get started with API monetization , we laid out how to build your API monetization strategy and av
