One entry point
An nginx load balancer serves the frontend and round-robins API traffic across every healthy application node. One public port, ready to sit behind the TLS proxy you already run.
Cluster architecture
One application. As many nodes as the day demands.
Iskue starts on a single host and grows sideways: add application nodes when traffic climbs, add database workers when data does. The application doesn't change — only the number of boxes running it.
Watch it grow sideways
Add and remove nodes yourself — watch ticket shards rebalance across workers as the data tier expands. This is the same topology the real cluster deployment runs; in production, redistribution is one Citus rebalance command.
The day you need one more node
What scaling out actually looks like: a real-world week, played out. Follow the steps — or let it run.
Tuesday, 09:00. Two app nodes cruise along under normal load — plenty of headroom.
What's in the cluster
Stateless app nodes
Sessions are token-based, so any node can serve any request — no sticky sessions, no shared session store. Live board and ticket updates stream over Server-Sent Events from whichever node you landed on.
Distributed PostgreSQL
The data tier is Citus: a coordinator routes queries to worker nodes that hold the sharded ticket data. It's still PostgreSQL — same SQL, same drivers, same tooling.
How the data spreads
- Tickets are sharded — the ticket table is distributed across workers by ticket id.
- Children stay with their parent — comments, attachments and SLA timers are distributed by ticket id and colocated, so opening a ticket touches exactly one worker.
- Everything else is everywhere — users, projects, workflows and other lookup data are reference tables, replicated to every node for local joins.
- Migrations run exactly once — a one-shot migrator applies the append-only schema chain, then application nodes boot with migrations disabled.
Orchestrated bring-up
- Coordinator and workers start and report healthy
- Workers register with the coordinator
- Schema migrations run — exactly once
- The sharding scheme is applied
- Application nodes come up, health-checked
- The load balancer opens the door
Dependency-ordered and automatic — one compose command brings up the whole sequence.
Start small. Grow when it's real.
Most teams run Iskue on a single Docker host for a long time — the cluster exists for the day that stops being enough. Because sessions are stateless and the data tier is still PostgreSQL, moving from one box to many is an operations change, not a migration project.
See Iskue on your own screen
A demo takes half an hour. A pilot runs on your servers, with your data, from day one.