Kong 1.3.0rc1 available for testing!

Hello Kong Nation!

It’s time to start a new release cycle, and we are happy to announce the availability of first release candidate, Kong 1.3.0rc1 that has just gone out and ready for testing!

Kong 1.3.0rc1 is the first release to officially support gRPC proxying!

Additionally, this release includes several highly-requested features such as support for upstream mutual TLS, header-based routing (not only Host), and database export, and configurable upstream keepalive timeouts.

This release is the first version of Kong that is build upon the recently released OpenResty, which itself brings tons of improvements and bug fixes such as better behavior while closing upstream keepalive connections, ARM64 support and LuaJIT GC64 mode.

The highlight of this release are:

  • :fireworks: Native gRPC proxying. Kong gained new ability to proxy gRPC traffic through it and to the upstream gRPC services. #4801
  • :fireworks: Mutual TLS handshake with upstream services. Kong can now present a client certificate while TLS handshake with upstream services. #4800
  • :fireworks: Route by any request header. The router now has the ability to match Routes by any request header (not only Host). #4758
  • :fireworks: Newly open-sourced plugin: the session plugin (previously only available in Enterprise) is now bundled in Kong. It can be used to manage browser sessions for APIs proxied and authenticated by Kong. #4685
  • :fireworks: Least-connection load-balancing. Kong can choose upstream server to connect to based on the amount of connections currently with them. #4528
  • :fireworks: A new section in the kong.conf file describes injected Nginx
    (added to Kong 0.14.0) and specifies a few default ones. This should help user getting rid of most of the customized Nginx templates eventually. #4382
  • :fireworks: New configuration properties allow for controlling the behavior of
    upstream keepalive connections. Which should reduce the number of 502 errors some customers may see. #4382
  • :fireworks: Database export via the new kong config db_export CLI command. Exported file can be used for running Kong in DB-less mode (added to Kong 1.1.0) or be imported back into the database later. #4809
  • The new “CA Certificates” core entity.
  • Support for more listening flags.
  • Improvements on the easiness use of Admin API.
  • New PDK capabilities.
  • :rocket: Tons of bugfixes and performance improvements!

:page_facing_up: There are so many more improvements in this version and we encourage you to read the complete Kong 1.3.0rc1 Changelog.

:package: The distribution packages are available for download in our usual community repositories, and the Docker Images have also been updated!

:arrow_up: The recommended upgrade path is the usual one for major version bumps. They are detailed in 1.3 Upgrade Path

:books: We are still working on bringing our documentation up-to-date, and are asking of you that if you want to test 1.3.0rc1, please refer to the links (Pull Requests or new plugins repositories) which all include some documentation around the new features, thank you. :slight_smile:

:warning: As a release candidate, we discourage the use of 1.3.0rc1 in production environments, but we strongly encourage testers to give it a try and give us your feedback! This forum is a great way to ask questions or post feedback, and the GitHub issues are still the de facto place for bug reports.

:heart: We thank in advance all of the testers for this release candidate and looking forward to hearing back from you!

:calendar: Update Jul 29, 2019: The 1.3.0rc1 Docker Images are now available for download!


Database export via the new kong config db_export CLI command. Exported file can be used for running Kong in DB-less mode (added to Kong 1.1.0) or be imported back into the database later.

So would folks be able to use this as a sort of native Kong backup process if they so choose? And really it has a few good use cases.

My idea would be back up this file (yaml file I am assuming) daily basis to a secure location in the event your C* cluster or Postgres DB host was melted. Then you could restore Kong and the DB to that previous state with an import of that file on a fresh keyspace/db. Am I correct thats a valid use case and supported?

This could replace doing a traditional cassandra-snapshotter tool setup and just be a bit nicer for us.

Other idea obviously would be that for those that wanna go from their db based deploys of kong to full db-less this helps get their data out of the db into yaml file format needed for kong db-less deploy(I would love to go db-less but us using OAuth2.0 plugin heavily prevents it).

Hi @jeremyjpj0916,

That is definitely an intended use case. Just make sure you test the export and restore with your configuration first to make sure it works to your satisfaction.


1 Like