Getting Started with Kiponos.io

Kiponos.io is the only configuration management tool working in True Real-Time. Which means any config item you modify online - in your Kiponos dashboard - is instantly changing your application behavior - while your application keeps running! That works for any variable in your application! in any runtime environment - be it local dev, staging, or CICD inside a container, Kubernetes pods in production... etc. It's all the same - You can modify all of them - in real-time, while they keep running. In DevOps terms that means No redeploys, No restarts, No reloads, Not even clicking refresh! Your application react immediately as you type your config value. Simple as that. (It's like having a Debug Watch - without debugging!) So how does it work? Kiponos magic, in its core, is based on highly secured websockets connection to instantly dispatch only delta changes to all your applications that uses Kiponos SDK and to your team members currently online. Both Kiponos SDK and Kiponos Web Dashboard are subscribed to websockets events about any config change, from any source - whether it's another SDK or any member of your team. Sounds Good! How do I start for free? :) Yes, we know you like free plans so we got you covered! You can signup to the single dev or team starter plans which are always free. Our SDK is available on Maven Central, so you can simply include its name in your build file. For example with Gradle: implementation 'io.kiponos:sdk-boot-3:4.4.0.250319' Let's get you setup with your first config items. The first time you login, you get a wizard to help you define your environments that you want to control in real-time. Kiponos uniquely identify a real-time config by combination of: Application Name Release Environment Config Name For example: Application Name: My-PetShop-Server Release: Ver-3.2.0a Environment: Staging Config Name: Factory-Settings Another config name can be defined for the tests running on the same Staging machine like: Application Name: My-PetShop-Server Release: Ver-3.2.0a Environment: Staging Config Name: My-Tests You can add different releases, more applications, and so forth... Configs are organized like a File System Folders and Items How do I use the SDK? Click: SideBar --> Config SDK Click to generate your API Keys for your SDK on this environment: What you get: 2 Env Variables for your runtime environment KIPONOS_ID KIPONOS_ACCESS Set them according to your operating system syntax for Environment Variables. For example, in Linux: # Replace and with actuals export KIPONOS_ID="" export KIPONOS_ACCESS="" And for Windows: set KIPONOS_ID= set KIPONOS_ACCESS= The Id+Access tokens authorize the SDK to work on a specific environment. This allows you to reuse the same SDK tokens for all your applications in the same environment. For example, you need only one pair of SDK tokens to run your Server on Staging and and also to run CICD pipeline with tests on the same staging machine, and also run a "Branch" version of your server with a different config name but still reuse the same pair of tokens. 1 JVM System Property: -Dkiponos Here is where you tell Kiponos what config path your application wants to work on with the current running SDK and Id+Access tokens. For example: java -Dkiponos="['My-Application']['My-Release']['My-Environment']['My-Config-Name']" MyJavaMain Since we allow reuse of the SDK tokens on the entire environment, it is necessary to provide which config name we need to access. Nevertheless, Kiponos use that to double check you actually access the environment you intended to work with. Working with the SDK API You can initialize the SDK anywhere in your code, including as a static, global variable like: Kiponos cfg = Kiponos.createForCurrentTeam(); Then, you can "reuse" that global anywhere in your code to access the latest config info: String healthApi = cfg.path("Health-Checks", "Services", "Payment-Service").get("health-api"); And Voila! Change online the "health-api". And when your code calls the above get("health-api") it will already have the latest value in it. Furthermore, since Kiponos already knows - instantly - when the value changes - we provide you with a hook that you can tell your SDK what to do - immediately - when a config value changes! So you instantly change your application behavior even without calling get("health-api")! For example: cfg.afterValueUpdated(valUpdated -> { // This code runs instantly! when you // change your config value online! if ("health-api".equals(valUpdated.getKey())) { long period = Long.parseLong(valUpdated.getValue()); // Do whatever you want with the new value... worker.reschedule(period);

Apr 29, 2025 - 03:38
 0
Getting Started with Kiponos.io

Kiponos.io is the only configuration management tool working in True Real-Time.

Which means any config item you modify online - in your Kiponos dashboard - is instantly changing your application behavior - while your application keeps running!

That works for any variable in your application! in any runtime environment - be it local dev, staging, or CICD inside a container, Kubernetes pods in production... etc. It's all the same - You can modify all of them - in real-time, while they keep running.

In DevOps terms that means No redeploys, No restarts, No reloads, Not even clicking refresh!

Your application react immediately as you type your config value.
Simple as that. (It's like having a Debug Watch - without debugging!)

So how does it work?

Kiponos magic, in its core, is based on highly secured websockets connection to instantly dispatch only delta changes to all your applications that uses Kiponos SDK and to your team members currently online.

Both Kiponos SDK and Kiponos Web Dashboard are subscribed to websockets events about any config change, from any source - whether it's another SDK or any member of your team.

Sounds Good! How do I start for free? :)

  1. Yes, we know you like free plans so we got you covered!
    You can signup to the single dev or team starter plans which are always free.

  2. Our SDK is available on Maven Central, so you can simply include its name in your build file.

For example with Gradle:

implementation 'io.kiponos:sdk-boot-3:4.4.0.250319'

Let's get you setup with your first config items.

The first time you login, you get a wizard to help you define your environments that you want to control in real-time.

Kiponos uniquely identify a real-time config by combination of:

  • Application Name
  • Release
  • Environment
  • Config Name

For example:

Image description

  • Application Name: My-PetShop-Server
  • Release: Ver-3.2.0a
  • Environment: Staging
  • Config Name: Factory-Settings

Another config name can be defined for the tests running on the same Staging machine like:

  • Application Name: My-PetShop-Server
  • Release: Ver-3.2.0a
  • Environment: Staging
  • Config Name: My-Tests

Image description

You can add different releases, more applications, and so forth...

Configs are organized like a File System

Folders and Items

Image description

How do I use the SDK?

Click:

SideBar --> Config SDK

Image description

Click to generate your API Keys for your SDK on this environment:

Image description

What you get:

2 Env Variables for your runtime environment

  • KIPONOS_ID
  • KIPONOS_ACCESS

Set them according to your operating system syntax for Environment Variables.

For example, in Linux:

# Replace  and  with actuals
export KIPONOS_ID=""
export KIPONOS_ACCESS=""

And for Windows:

set KIPONOS_ID=
set KIPONOS_ACCESS=

The Id+Access tokens authorize the SDK to work on a specific environment.

This allows you to reuse the same SDK tokens for all your applications in the same environment.

For example, you need only one pair of SDK tokens to run your Server on Staging and and also to run CICD pipeline with tests on the same staging machine, and also run a "Branch" version of your server with a different config name but still reuse the same pair of tokens.

1 JVM System Property: -Dkiponos

Here is where you tell Kiponos what config path your application wants to work on with the current running SDK and Id+Access tokens.

For example:
java -Dkiponos="['My-Application']['My-Release']['My-Environment']['My-Config-Name']" MyJavaMain

Since we allow reuse of the SDK tokens on the entire environment, it is necessary to provide which config name we need to access. Nevertheless, Kiponos use that to double check you actually access the environment you intended to work with.

Working with the SDK API

You can initialize the SDK anywhere in your code, including as a static, global variable like:

  Kiponos cfg = Kiponos.createForCurrentTeam();

Then, you can "reuse" that global anywhere in your code to access the latest config info:

  String healthApi = cfg.path("Health-Checks", "Services", "Payment-Service").get("health-api");

And Voila!

Change online the "health-api". And when your code calls the above get("health-api") it will already have the latest value in it.

Furthermore, since Kiponos already knows - instantly - when the value changes - we provide you with a hook that you can tell your SDK what to do - immediately - when a config value changes!

So you instantly change your application behavior even without calling get("health-api")!

For example:


        cfg.afterValueUpdated(valUpdated -> {

            // This code runs instantly! when you 
            // change your config value online!
            if ("health-api".equals(valUpdated.getKey())) {
                long period = Long.parseLong(valUpdated.getValue());

                // Do whatever you want with the new value... 
                worker.reschedule(period);
            }
        });

Configuration? Forget about it!
Enjoy the revolution!

Kiponos.io Team