External/ergo
1
0
Fork 1
mirror of https://github.com/ergochat/ergo.git synced 2025-12-20 02:00:11 -08:00
Code Issues Projects Releases Packages Wiki Activity Actions

Clarify Ergo deployment options with Kubernetes

Browse source 
Updated the deployment description for Ergo to clarify automatic failover capabilities using Kubernetes. Also add the helm chart I published.
This commit is contained in:
Geert-Johan Riemer 2025-10-18 12:55:50 +02:00 • committed by GitHub
parent e200e9fd8f
commit 4a44a45c2e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/MANUAL.md
View file

@ -95,7 +95,7 @@ In addition to its unique features (integrated services and bouncer, comprehensi
We believe Ergo should scale comfortably to 10,000 clients and 2,000 clients per channel, making it suitable for small to medium-sized teams and communities. Ergo does not currently support server-to-server linking (federation), meaning that all clients must connect to the same instance. However, since Ergo is implemented in Go, it is reasonably effective at distributing work across multiple cores on a single server; in other words, it should "scale up" rather than "scaling out". (Horizontal scalability is [planned](https://github.com/ergochat/ergo/issues/1532) but is not scheduled for development in the near term.)
Even though it runs as a single instance, Ergo can be deployed for high availability (i.e., with no single point of failure) using Kubernetes. This technique uses a k8s [LoadBalancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) to receive external traffic and a [Volume](https://kubernetes.io/docs/concepts/storage/volumes/) to store the embedded database file. See [Hashbang's implementation](https://github.com/hashbang/gitops/tree/master/ircd) for a "worked example".
Even though Ergo runs as a single instance, it can be deployed with automatic failover using Kubernetes. Meaning that if a (virtual) machine fails, ergo will quickly be started on a different node. Allowing users to quickly reconnect without having to wait for an operator to fix/reboot the underlying server. This technique uses a k8s [LoadBalancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) to receive external traffic and a [Volume](https://kubernetes.io/docs/concepts/storage/volumes/) to store the embedded database file. See [Hashbang's Kustomize manifests](https://github.com/hashbang/gitops/tree/master/ircd) or [GeertJohan's Helm chart](https://github.com/GeertJohan/ergo-helm-chart).
If you're interested in deploying Ergo at scale or for high availability, or want performance tuning advice, come find us on [`#ergo` on Libera](ircs://irc.libera.chat:6697/#ergo), we're very interested in what our software can do!