[Feature]: Have fluxcd documentation and support and more charts

[suse-coder]

📝 Description

Kubara currently seems to be heavily tied to Argo CD. I would like to see official documentation (and ideally first-class support) for using Flux Operator (https://fluxoperator.dev/) instead.

Reasons:

• Argo CD feels too heavy and slow for my use case.
• I want to run Kubara on STACKIT Edge Cloud, where the platform already provides a managed Kubernetes environment. Having everything installed and upgradable automatically via the STACKIT UI/CLI (without needing a full GitOps controller like Argo CD) would be ideal.
  Flux Operator is lightweight, fast, and fits perfectly into environments where the underlying platform already handles a lot of the infrastructure.
• An alternative long-term direction would be to evolve Kubara toward a CUE-based approach similar to Timoni (by the same author as Flux). This would make the experience even more modern and declarative.

🎯 Use Case

• Deploy and manage Kubara on STACKIT Edge Cloud (or similar managed Kubernetes offerings) without pulling in Argo CD.
• Trigger upgrades directly from the STACKIT UI or CLI while still benefiting from Kubara’s opinionated stack.
• Keep the GitOps workflow but with a much lighter controller (Flux Operator).
• Have a clear, documented path for users who deliberately want to avoid Argo CD.

📎 Additional Context

https://fluxoperator.dev/
https://timoni.sh/quickstart/

Please consider adding the following charts to Kubara’s default / recommended catalog (I could provide working helm charts):

Observability & Storage

• VictoriaMetrics (instead of or in addition to Prometheus)
• Mayastor
• Rook Ceph

Productivity & Collaboration

• OpenCloud (https://opencloud.eu/en) – excellent SharePoint replacement
• Forgejo
• GitLab Helm chart
• Matrix (Element Server Suite)
• Coder (https://coder.com) – remote development workspaces
• Keycloak
• OpenLdap (https://github.com/osixia/helm-charts)
• Clamav https://github.com/wiremind/wiremind-helm-charts
• cnpg (potentially also in the above charts integrated like https://truecharts.org/charts/ does it)
• cilium
• cilium gateway api
• web remote rdp desktop to kubevirt vms (kasmvnc like to access via ui in the browser a vm (at best integrated into stackit like aws dvc: https://registry.coder.com/modules/coder/amazon-dcv-windows)

Monitoring & Benchmarking

• LibreSpeed

Backup

• Veeam Kasten K10

Virtualization

• KubeVirt – including ready-to-use examples and documentation for common guest OS images:
  • Windows (Server + Desktop)
  • SUSE Linux Enterprise
  • Ubuntu
  • Fedora

Would love to see any of the above added as first-class, well-documented options. Thanks!

✅ Checklist

• I have searched existing issues
• This is not a duplicate

[tuunit]

@suse-coder we totally agree that ArgoCD is quite heavy and not the perfect one size fits all solution that is why we already have plans in place to make the GitOps integration more agnostic in the future and support flux and sveltos as well. But we don't have a timeline for this yet.

[tuunit]

Regarding your requested charts. We will soonish, in the next couple of weeks, outsource the internal catalog into a separate catalogs repository. Where we will bundle different types of platform architectures and publish the catalogs with all necessary config files, charts, modules, etc. as oci artifacts which are then versioned and distributed independent of the command line tool

[suse-coder]

Yes please also have a way like https://github.com/netbirdio/netbird and coder.com workspaces (on-prem) where one can create a new vm/container fast (via helm operator) and then an agent is installed into the vm (windows/linux) and one can over the local network (company) access via the browser (rdp/ssh) the vm, but also via the stackit ui. And having an easy way to expose services securely like Omni (talos) would be great (so that cilium and cilium gateway-api are strongly connected and working with stackit), like https://docs.siderolabs.com/omni/cluster-management/expose-a-workload-via-service-proxy does it now. At best most management (sso, roles, users) is all done via stackit ui, only (if down or network not available/ faster performance) one can via the local company network reach via the browser the rdp vms.

[fabian-schmitt]

Hi @suse-coder we have our community call tomorrow and would really appreciate if you join,
so we can clarify a lot of things (Link on the bottom). If you can't make time, you could also join our Slack Channel.

For example one thing i would like to mention about the STACKT UI Integrations:
The Project is separate to the cloud platform. So what ever you have in mind, it might be useful as a feature Request for STACKIT - but we won't be able to provide these features by ourselves.

kubara Community Call:
Tomorrow Wednesday, 10th June · 2:00 bis 3:00PM (Berlin (GMT+2))
https://meet.google.com/yki-kbyv-hfe

[suse-coder]

Right now kubara is great at bootstrapping – kubara generate spits out Terraform + a curated Helm umbrella catalog from embedded templates, all wired for GitOps with ArgoCD/Flux.

The pain TrueCharts solved is the same pain we have: every app chart re-implements PVC, ingress, service, probes, secrets, RBAC, CNPG, etc. TrueCharts fixed it by building one common library chart – all 800+ apps are just dependencies: - name: common + a values file. Their site calls it "built on a shared, reusable common-lib foundation" 4.

Why this fits kubara perfectly:

Less template sprawl – kubara already wants opinionated defaults. Move those defaults into a single kubara-common chart (PVC, ExternalSecrets, OAuth2-proxy annotations, NetworkPolicy, ServiceMonitor, CNPG cluster, etc.). App charts become 20 lines of values, not 500 lines of duplicated YAML.

STACKIT as upstream, local remains local – STACKIT (where kubara started as internal/inner-source maintains kubara-common in an OCI registry. Users still run helm / Flux HelmRelease locally – no SaaS lock-in, fully air-gappable. FluxCD operator just pulls the common chart + your values from your git repo.

Keeps kubara's GitOps DNA – kubara generate wouldn't render full charts anymore, it would render values.yaml for the common chart + Flux ApplicationSets. Same workflow, 90% less generated code to maintain.

[tuunit]

We are planning to make kubara more gitops agnostic in the future. So users can select if they want to use ArgoCD/Flux + Sveltos in the future.

Further, we will separate the component catalog from this main repository into kubara-io/catalogs in the near future. This will make it easier to maintain multiple different opinionated platform stacks and make it easier for us to do more regular updates for CVE, releases and integration tests just on the platform contents separate from the CLI.

Therefore we will keep this ticket open for now