The separation of concerns
Multi-tenant platforms fail in two different places. One is who may ask for work and how that request is validated, recorded, and observed. The other is when the cluster can accept that work given quotas, queues, and scarce accelerators.
Kueue addresses the second problem as a Kubernetes-native job queueing and admission controller. Building a private half-version of that inside an application control plane is a common way to create a second source of truth for capacity—and then lose to production edge cases.
What Hammrly owns instead
- Authenticated submission (gateway) and read models (query API).
- Durable handoff and orchestration around submission lifecycle.
- Interactive session kinds and access URLs once workloads are ready.
- A Web UI on the same contracts tenants and automation already use.
When Kubernetes execution is enabled, Hammrly can submit Jobs intended for Kueue to admit. Fair sharing and GPU-aware placement stay in the scheduling/admission layer that is designed for them.
Why this matters to evaluators
If you already standardized on Kueue, Hammrly is additive: a product and API surface for tenants. If you do not want Kueue, Hammrly’s local Compose path still lets you explore submission and lifecycle without pretending a toy queue is a cluster scheduler.
Hammrly’s bet: do not compete with Kueue—stand on it, and make the front door safe.