Clace currently is single-node. It uses a SQLite database for app metadata (which is what allows it to support atomic updates across multiple apps). I will be

Clace currently is single-node. It uses a SQLite database for app metadata (which is what allows it to support atomic updates across multiple apps). I will be adding multi-node support soon. The user will have to bring their own Postgres database and load balancer. Multiple Clace instances will run in parallel, each spinning up containers locally using Docker/Podman. For the internal tools use case, I think that should scale to support most workloads. There will be cases where delegating container management to Kubernetes might make sense. Container management in Clace is a thin layer, it should be possible to use a K8S service/deployment wrapper instead of using local Docker or Podman. The auto-idle feature might cause latency for services with a high startup cost. For most apps, it should be fine. It can be disabled individually for apps.