Declarative Kong configuration, versionnable

Hello Any help on the following use-case ? We are deploying Kong over Heroku, and we would like to be able to take advantage of Heroku github binding, and basically versionning our config. The final goal is to have a Kong instance which is controllable by some sort of “config file” versionned inside github, automatically deployed on Heroku, bringing automation, versionning in the process.

We would then be able to:

Have a versionned config file on github
Edit and push it
It redeploys automatically inside Heroku
It restarts the Kong
New routes are applied
And to “Roolback” from here to any previous point, using heroku github binding.

By nature, Kong “configuration” (I mean APIs configuration) is inside a datastore, which is not really meant to be manipulated directly, and the only stuff I found to make it declarative is which seems a good idea, but is using an old release of Kong, adds a middle Layer, and is not widely maintained.

Any thoughts / experiences / warning / advice on this ?


Officially we don’t provide such at the moment. We do have some demos and tools, but nothing yet considering release quality. One such tool is in out upgrade tests:

And you can see the scripts there as well, e.g.:

I think that the question is more about automatization of proxy service and routes configuration. The response is about automating tests, it does not respond the question.

Yes, it is about automating tests (the project), but as you see, it is a config file that declares routes and services. That can clearly be extracted from the rest of the kong-upgrade-tests:


Quite closely answers the question. But that tool is not made as our official declarative config tool, but it might work depending on your needs. We don’t currently provide one. kongfig is probably the best that I have seen.

Hey Bungle.

Glad to hear that, at least, “something exists”.

It would be very appreciable to hear this is upcoming to Kong core… I perfectly understand the need among load balancing and scalability, decoupled and common config, but as of 2018, everything is upcoming to a declarative approach, and having a config (this is still some sort of “config”, I guess) remaining imperative, inside such a trending framework, is a pain…

In my humble opinion, even a “choice” on using or not using the whole concept of datastore would be enough.

As a feedback, here’s our use case :

  • We have a separate loadbalancer
  • We want to deploy Kong over Heroku
  • The main pros for Kong (over raw nginx, haproxy, node.js as a proxy) is extensibility (plugins), community, fun, and simple configuration

For now, we’re unfortunately going to make another choice due to 2 reasons :

  • The lack of “config as declarative strategy” forces us to run a script at build time that make sequentail ajax queries to the server to DELETE every APIs and re-create them with some sort of config file of our own, or make some kind of diff then PUT them… As this seems to be the most reliable way (I didn’t test your solution, it looks promising though, but I’m not confident in using core-non-public-features in production)
  • The lack of a fully working, up-to-date Kong-backed buildpack for Heroku. is backed by Heroku, and is non-official. The Kong version there is 0.11 and this seems too bad for us. The release cycle of it seems a bit slow too.

Thanks for your help anyway :slight_smile:

I fully understand your decision, and I am afraid that our product didn’t match your requirements at the moment. I look forward to get you back onboard when we can give better answers to your needs, :wink: — though it might be too late. I am really glad that you did take your time and explained your issues with Kong even when you have decided otherwise, I guess this will help others, and feedback like this is always highly valuable to us. I will point to this comment on our backlog, so that we remember it when we get this work prioritized.

I look forward to get you back onboard when we can give better answers to your needs, :wink: — though it might be too late.

Never too late for agile CTOs :smile:

You’re very welcome, I thank you again, and I look forward too to be able to make that fair use of Kong. That plugin ecosystem seems so juicy :slight_smile:


Have a try on my tools for kong initialization. With:

  • api support
  • route/service support
  • plugin support
  • some useful directives
  • retry(waiting until kong is up)

You can easily bundle your versioned configuration files and the kong-init binary in a tagged docker image for any container management platform.

Can I ask you what did you choose in-place of Kong?

I’ve been researching Kong as a possible gateway candidate at my organization. I’ve loved everything I’ve seen so far, but not being able to version the configuration has stopped me dead in my tracks. Without the ability to preserve the config in source control and easily apply it in various separate environments, I just cannot select it.

Kongfig seems to be behind Kong. I don’t see any support for services/route at this time. Other projects exist, but they have limited community support. They are just too small to rely upon.

Is there a future possibility for this feature to exist in a fully supported, core project manner? Until it does, I can only put Kong on my technology radar.

Yes, we do have such plans on our radar for the first half of 2019.

Is there a public roadmap available or tickets to watch?

Not at this point, sorry.

What if you took this approach?

Use Konga an open source UI that helps you administrate Kong:

Then use the “snapshots” feature. This will let you take scheduled backups(think of this as your hourly/daily w/e have you version control, and apply them to other Kong clusters or to restore your existing Kong node to a prior state. His next branch almost has 100% compatibility with Kong 1.0 minus a few issues Kong is fixing around request-transformation plugin and a few others.