The way this works is that you first build a CLI, which is a container and then you publish it to us so that it also runs in Slack. It's shared code that runs in both environments.
So if Slack is ever down, you still have the CLI.
The big benefit here is that you build once and it runs in both places which means don't need a separate runbook or even infra to make your CLI run in Slack - it's 100% serverless.
For our users the Ops engineers obviously prefer the CLI, but the Dev's really love Slack - this creates a nice balance in the DX that works on both sides, on top of existing CI/CD.
Comments
Founder here - great question.
The way this works is that you first build a CLI, which is a container and then you publish it to us so that it also runs in Slack. It's shared code that runs in both environments.
So if Slack is ever down, you still have the CLI.
The big benefit here is that you build once and it runs in both places which means don't need a separate runbook or even infra to make your CLI run in Slack - it's 100% serverless.
For our users the Ops engineers obviously prefer the CLI, but the Dev's really love Slack - this creates a nice balance in the DX that works on both sides, on top of existing CI/CD.