This article follows the official documentation. We haven’t tested this tool for a hands-on review.
When a coding agent needs to inspect Kong Gateway configuration, it can use Kong decK to compare a configuration file with a running gateway. The file lists gateway settings. These include Services and Routes, as well as plugins. decK reads or changes the gateway through its Admin API, the interface Kong Gateway provides for administration.
An agent can check a configuration file locally, then request a live diff, which shows how the file differs from the running gateway. It should stop before sync until a person approves the proposed changes. Syncing makes the gateway match the file and removes any configuration the file leaves out. These commands follow Kong’s documentation; they have not been installed or tested for this article.
Install and prepare decK
Install the version for your operating system using Kong’s official decK installation instructions. Then confirm the executable is available and check its gateway commands:
deck version
deck gateway --help
To check a file locally, the agent needs the decK executable and a configuration file, such as kong.yaml, that lists the desired gateway settings. It does not need to contact a gateway for the example below. To compare the file with a live gateway, the machine running decK must be able to reach the gateway’s Admin API.
Keep Admin API credentials outside the agent prompt. If the gateway requires authentication, configure access using the options documented for your decK version and environment. For Konnect, use a supported token with only the permissions the task requires.
Validate and preview changes
Start with a configuration file already present in the repository. The first command checks the file; the second compares it with a gateway:
deck gateway validate -s ./kong.yaml
export KONG_ADMIN_URL='http://localhost:8001'
deck gateway diff -s ./kong.yaml --kong-addr "$KONG_ADMIN_URL"
The URL is a placeholder for a locally reachable Admin API; replace it with the address of the gateway you intend to inspect. The validate command checks the file's settings without changing a gateway, while diff contacts the configured Admin API and shows the changes decK proposes. Kong documents the command and its connection options in the gateway diff reference.
Read the diff as a proposed plan, including removals, before taking any write action. The example uses no output-format flag. If an agent needs machine-readable output, check deck gateway diff --help and the documentation for the installed version rather than assuming a JSON option exists.
To use this example, an agent could receive a prompt such as: “Validate kong.yaml. Then compare it with the gateway at the configured Admin API URL. Summarize additions, updates, and deletions. Do not run sync.”
Treat sync as a separate write
deck gateway sync applies the declarative file to the target gateway. Kong’s sync documentation warns that decK deletes gateway configuration that is absent from the file. A file containing only a partial configuration can therefore remove existing Services, Routes, or other entities.
Keep the write step separate from the preview:
deck gateway sync -s ./kong.yaml --kong-addr "$KONG_ADMIN_URL"
Run it only after reviewing the diff and confirming that the file represents the intended full configuration for that target. Do not run multiple decK processes against the same gateway at once; Kong warns that concurrent decK processes can corrupt gateway configuration.
When decK fits an agent task
decK works well when an agent's task involves a Kong configuration file that lists the desired settings. The agent can check a change, compare it with a gateway, and report the planned result. Kong describes this pattern as capturing configuration, editing the state file, comparing it, and then synchronizing it in its APIOps overview.
This command-line workflow differs from Kong’s Konnect MCP Server, which lets assistants that support MCP perform Konnect operations. An agent needs shell access to run decK and must use the correct decK version. It also needs a suitable configuration file and access to the target Admin API. The operator remains responsible for approving any sync that writes to the gateway.