One of the superpowers of Kong Gateway that its users most appreciate is its declarative configuration management capabilities, facilitated by the decK command line tool. Declarative configuration enables you to manage your Kong Gateway configuration using GitOps practices, including federated configuration management, mandatory review processes, and automated policy enforcement via CI/CD.
This is a great start, but it’s not enough anymore. With the advent of Kong Konnect, Kong’s next-generation API management platform, there are a lot more entities that need configuration. You can deploy Kong Mesh control planes, publish API Products, configure your Developer Portal, and more. Declarative configuration only works if all of your configuration is declarative.
The Konnect platform provides a whole set of new capabilities that need to be managed declaratively. Being able to configure which APIs are published to which Developer Portal, and which branding that portal should have is a key workflow for API Product owners. Being able to do it declaratively is a requirement when it comes to operating at scale.
The Kong team considered expanding decK to manage Konnect entities in addition to Gateway entities, but it didn’t feel right to us. decK manages entities that live inside a single Kong Gateway control plane, and adding support to create control planes or manage organization settings was confusing to our users. So we went back to the drawing board and looked for alternatives.
Many of our users are already using Terraform to manage their infrastructure on AWS, Azure, and GCP. Kong is infrastructure too, so why don’t we let you manage Kong Gateway and all other entities above it at the Kong Konnect level with Terraform? This allows users to use a tool that they’re already familiar with.
Enabling customers to practice GitOps is a north star for Kong, and tools such as Atlantis allow us to ship Terraform support knowing that GitOps is at the heart of every successful workflow. Existing Terraform users are likely to have this automation in place already, and by shipping a Terraform provider we slot right into that existing infrastructure. All the benefits with none of the CI/CD toil.
It’s with great pleasure that we announce that terraform-provider-konnect is now generally available. We’ve been using it internally and with our beta testers for the last six months, and I’m not exaggerating when I say that 90% of the projects I see day to day are using the Terraform provider to manage their Konnect configuration.
The provider has already been installed over 7,500 times, and supports everything you need to get started with Konnect:
You might be wondering what the future looks like for decK now that we have Terraform support. decK isn’t going anywhere. It’s still a strategic tool for Kong Gateway, and the declarative configuration format that decK uses forms the basis for our whole APIOps story.
We see Terraform and decK co-existing indefinitely. There are a lot of things that you can do with decK that you can’t do with Terraform:
deck file patchread_timeout must be set) using deck file validatedeck file mergeHowever, we know that many of you want to use Terraform but also benefit from decK’s APIOps capabilities. That’s why we’ve built deck file kong2tf, which takes a decK declarative configuration file and generates Terraform manifests automatically. This means you have two options when it comes to APIOps:
decK to sync your config (you can even run deck from Terraform).deck file kong2tf to convert your declarative config to Terraform and use Terraform for everythingIf I were looking to adopt Terraform today, I’d use deck file kong2tf to provide a complete pipeline that means that the development team only has to write an OpenAPI spec. And thanks to the power of openapi2kong and kong2tf the infrastructure team gets to interact with Terraform manifests that they’re comfortable with.
Some of you may be thinking, “But I don’t use Konnect!” If that’s the case, I have two things for you:
In addition to the terraform-provider-konnect GA release, I’m excited to share that we have a beta release of terraform-provider-kong-gateway for you all to test.
The two providers are almost identical, except that the on-prem provider doesn’t require you to specify a control plane ID on your entities. Other than that, all the same Kong Gateway resources can be managed using identical Terraform resources.
Kong and Terraform are a great match. Terraform helps configure critical infrastructure and prevent configuration drift, and Kong Gateway is a key part of that infrastructure.
If you want to try it out, the quickest way to get started is to create a free Konnect account and use terraform-provider-konnect.
If you’re an existing on-prem user, you can use terraform-provider-kong-gateway to manage your deployment.
No matter which provider you choose, we’d love to hear from you via GitHub about what you’re doing with Kong Konnect or on-prem.
As of September 2025, Kong Gateway Enterprise 3.8 will enter its End Of Life (EOL) phase and will no longer be fully supported by Kong. Following this, Kong Gateway Enterprise 3.8 will enter a 12-month sunset support period, focused on helping cus
We're very excited to announce Kong Mesh 2.12 to the world! Kong Mesh 2.12 delivers two very important features: SPIFFE / SPIRE support, which provides enterprise-class workload identity and trust models for your mesh, as well as a consistent Kuma R
Meet Emily. She’s an API product manager at ACME, Inc., an ecommerce company that runs on dozens of APIs. One morning, her team lead asks a simple question: “Who’s our top API consumer, and which of your APIs are causing the most issues right now?”
Today, we’re announcing that Kong has acquired OpenMeter , the open source and SaaS leader for real-time usage metering and billing. OpenMeter’s capabilities will be integrated into Kong Konnect, enabling usage-based pricing, entitlements, and invo
It’s been almost a year since we released our Konnect Terraform provider . In that time we’ve seen over 300,000 installs, have 1.7 times as many resources available, and have expanded the provider to include data sources to enable federated managem
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen