Blog
Learn how to connect your repositories to steadybit with our brand new CLI.
We have released the first version of our command line interface (CLI). With the CLI you can connect your repositories to steadybit. In this blog post, we will show you the first implemented features. Be sure - there is much more to come! If you do not have access to our platform yet, feel free to create an account.
Disclaimer
We are currently extending this feature. Some aspects may change and work different than described in this blog. If you need help, you can always check our docs or contact us. We are happy to hear your feedback!
CLI-Installation
Nothing more than a simple
npm install -g steadybit
Authorization
First of all, we need an authorization token. You can grab one from Settings -> API Access Tokens. Make sure to create a token with type "Team".
➜ steadybit config profile add
? Profile name: steadybit
? API access token: [hidden]
? Base URL of the Steadybit server: https://platform.steadybit.io
Describe your Service
Next you need to describe your service and how steadybit can find it. At the moment, only Kubernetes deployments are supported. We are working on other service-types. You can define how steadybit can check the health of your deployment and which Resilience Level you want to achieve. You don't know our Resilience Level feature? You can have a quick look into our documentation. We are heavily working on this feature as well. You will be able to define your service resilience requirements in much more detail in the future.
➜ steadybit service init
? Service name: gateway
? Desired Resilience Level: A - challenges for loose coupling
In order to understand which service you are describing, we need to be able to map it to data collected by the Steadybit agents. Right now, we only support mapping to Kubernetes monitored deployments.
? Kubernetes cluster name: demo-dev
? Kubernetes namespace: steadybit-demo
? Kubernetes deployment: gateway
We need to ensure that the service is still operating as expected when verifying compliance with the desired resilience level. To do so we support various checks. Please define at least one health check that we can use when running resilience checks.
? Health Check Type: HTTP
? URL: http://k8s.demo.steadybit.io/products
...
The CLI created a .yml file containing your service definition in your current working directory. From now on you are able to fine tune your settings either via subsequent CLI calls or by editing the .yml once you understand the format.
id: 9cb2888d-3abf-4ac3-bf8b-40b7eb61d271
name: gateway
desiredResilienceLevel: A
mapping:
kubernetes:
cluster: demo-dev
namespace: steadybit-demo
deployment: gateway
health:
- type: HTTP
url: http://k8s.demo.steadybit.io/products
Sync the service definition with the steadybit platform
You can now upload the service definition by executing
steadybit service apply .steadybit.yml
or even better, you can automatically sync the service definition with every commit using our Github Action
jobs:
apply:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: steadybit/define-service@v1
with:
apiAccessToken: ${{ secrets.STEADYBIT_TOKEN }}
See your Service Definition in Action
You can now use the cli to open steadybit and watch your current state and work on the next steps.
steadybit service open .steadybit.yml
which opens the steadybit platform in your standard web browser. From here, you can inspect the service’s current state, trigger challenges and much more.

As an alternative you can verify your current state directly via the CLI
steadybit service verify .steadybit.yml
which will create the following output

We are working on several new features for our cli. What do you think? We are interested in your ideas!
Curious about steadybit? Just book a personalized demo or try steadybit yourself.