Krino runs on your own infrastructure and ships as containers.

​
Components

Two databases is a deliberate choice. PostgreSQL carries the transactional side, ClickHouse the high-volume event data. Keeping them apart stops a heavy dashboard from slowing the decision path.

​
Environment variables

Each service needs a .env. The ones that matter most:
TIMEZONE must match the timezone your applications use for updated_at. A mismatch shifts velocity windows and looks perfectly healthy — the most dangerous kind of bug.

​
Bring-up order

1

Start the infrastructure

PostgreSQL, ClickHouse and NATS. Wait for health checks to pass.
2

Apply migrations

Schema migrations run at application start; the first boot can take a while.
3

Start the worker

It creates the queue streams and binds the consumers. It must be up before the API.
4

Start the API and UI

Server.Api and Server.Blazor.
5

Sign in as the administrator

Use the account created on first boot, and change its password immediately.

​
Health checks

The verbose form reports each dependency separately; use the plain one for your load balancer.

​
Backups

PostgreSQL holds every decision, case and rule — regular backups are essential. The event data in ClickHouse can be reloaded from your source systems, but reloading takes a long time; backing up both is cheaper.

​
Upgrades

Version upgrades are included in the licence. Take a PostgreSQL backup first, and move the worker to the new version before the API.