Ways to run
Ways to run Kanbus
Kanbus starts as files in your repository. Pick the setup that fits who needs to see the board and where the issues should live.
Pick by who needs the board
Most teams start with local files and stay there: the board is in the repository, every developer and agent already has it, and git carries every change. Push it to a hosted repository when a team or a fleet of agents shares it, and move it into S3 and DynamoDB when it belongs inside a product.
| Local files | Files in the cloud | S3 and DynamoDB in the cloud | |
|---|---|---|---|
| Status | Available now | Preview | Preview |
| Where issues live | JSON files in your working tree | The same files, in a hosted git repository | S3 objects, with a DynamoDB catalog |
| Who changes them | You and the agents on your machine | Everyone with a clone: people, agent sandboxes, CI | Your application's users, through the Kanbus API |
| How changes travel | Instantly, on disk | Git push and pull, plus optional live updates over MQTT | Every write goes straight to S3 |
| What you run | kbs or kanbus, and kbsc for the board |
The same tools in every clone, and optionally a hosted board on AWS | The Kanbus API service and the @kanbus/ui components |
All three setups
Available now
Issues are JSON files in your repository, read and written by the CLI, your agents and a local board. This is how Kanbus is used every day.
Preview
The board lives in a hosted git repository. Every clone uses the same commands, git carries the changes, and an optional broker and hosted board make it feel live.
Preview
The Kanbus API and board components inside your own app, with issues stored in S3 and a DynamoDB catalog.