Hi Liwan team,
I maintain charts in the HelmForge ecosystem and wanted to share that Liwan is available as a third-party Helm chart for Kubernetes users:
Example installation:
helm repo add helmforge https://repo.helmforge.dev
helm repo update
helm install liwan helmforge/liwan
OCI installation:
helm install liwan oci://ghcr.io/helmforgedev/helm/liwan
The chart uses the official ghcr.io/explodingcamera/liwan image and is intentionally modeled around Liwan's lightweight embedded-DuckDB architecture. It supports persistence, Service, Ingress, probes, resource/security settings, scheduling options, and extra manifests. The chart documents the single-instance limitation explicitly because DuckDB is embedded and should not be treated as a horizontally scalable multi-writer database.
Would you be open to adding this to the Liwan documentation as an unofficial / third-party Kubernetes installation method? This could help users who already run self-hosted apps on Kubernetes discover a maintained Helm-based deployment path, while keeping ownership clear that the chart is maintained by HelmForge and not by the upstream Liwan project.
If preferred, I can open a small documentation PR with a short third-party Kubernetes/Helm section linking to the HelmForge chart.
Hi Liwan team,
I maintain charts in the HelmForge ecosystem and wanted to share that Liwan is available as a third-party Helm chart for Kubernetes users:
oci://ghcr.io/helmforgedev/helm/liwanExample installation:
OCI installation:
The chart uses the official
ghcr.io/explodingcamera/liwanimage and is intentionally modeled around Liwan's lightweight embedded-DuckDB architecture. It supports persistence, Service, Ingress, probes, resource/security settings, scheduling options, and extra manifests. The chart documents the single-instance limitation explicitly because DuckDB is embedded and should not be treated as a horizontally scalable multi-writer database.Would you be open to adding this to the Liwan documentation as an unofficial / third-party Kubernetes installation method? This could help users who already run self-hosted apps on Kubernetes discover a maintained Helm-based deployment path, while keeping ownership clear that the chart is maintained by HelmForge and not by the upstream Liwan project.
If preferred, I can open a small documentation PR with a short third-party Kubernetes/Helm section linking to the HelmForge chart.