feat: huge beszel hub and agent helm chart update

[cloudwithdan]

📃 Description

This PR updates and adds a new helm chart for beszel-agent and updates the existing beszel-hub

🪵 Changelog

➕ Added

• Fixed Helm chart for beszel-hub
• Added new helm chart for beszel-agent
• Added helm release-please github actions

Removed

beszel-agent from .gitignore since it was not letting me to git add the helm chart

[cloudwithdan]

I have been cooking this Kubernetes setup for some time, I am happy with the helm charts, I have extensively tested them.
This is screenshot from my setup:

• 1 hub running on my worker node
• 3 agents running on all nodes with DaemonSet

[yukccy]

Do we have an estimation of this PR being merged and chart to release?

[henrygd]

Thanks so much for this! And sorry for the delayed reply, I've been mostly off the computer for a few weeks and still catching up on a lot of stuff.

I took a quick look and it's definitely a huge improvement. I don't have time to go over it line by line at the moment, so I ran the patch through gemini. It picked out few potential issues I'm wondering if we can address before merging. If any of this is wrong or not necessary, just let me know :)

1. Fix the "TO DO" in the Hub README

The beszel-hub/README.md says TO DO under the "Add the Repository" section. This will be the first thing users see, and it makes the chart look unfinished.

2. Restore the Docker Socket Example

Patch 3 accidentally removed the Docker socket volume mount example from the README.md. Without this, the agent can't see containers. Users will deploy it and think it's broken because their dashboard is empty.

Fix: It should be added back to the README and ideally included as a commented-out section in the values.yaml for both charts.

3. Add Validation for the SSH Key (env.KEY)

The agent requires an SSH public key to work. Currently, if a user forgets to set env.KEY, the chart installs silently with an empty secret, and the agent just fails to connect.

Fix: Adding a simple fail check in the template ensures the user gets a helpful error message at install time rather than a mysterious failure at runtime.

4. Consistent Variable Naming

The documentation uses HUB_ADDRESS in some places and HUB_URL in others.

Fix: Standardize on HUB_URL everywhere to prevent users from using the wrong key in their values.yaml.

[cloudwithdan]

Henry, sorry for late contribution but I had to jump in since a lot of people are asking for the helm chart.
Please review my latest changes.

• Added a helm release please GH Action
  • @henrygd your input is needed here to configure gh-pages
• standardized the env variables
• update documentation

Mounting docker socket is not needed since this is a setup for kubernetes.

[tim-krehan]

Hi @cloudwithdan
Nice work on the helm charts! I deployed them on my cluster and they work like a charm!
I would love to use them in my homelab. Since I use the gateway api - is there maybe a chance, the httproute from the agent can also be added to the hub chart?

Also for the agent: maybe we could add an "existingSecret" section. The Helm “existing secrets” pattern lets you point a chart to a pre‑created Kubernetes Secret instead of generating one from values. Charts typically expose a field like existingSecret, and when it’s set, templates skip secret creation and simply reference the named Secret. This keeps sensitive data out of values.yaml and allows external secret managers to control the lifecycle.

something like this:

env:
  PORT: "45876"
  # Hub URL - OPTIONAL (e.g., http://beszel-hub:8090)
  HUB_URL: ""
  # Agent name in the Hub - OPTIONAL (defaults to node name)
  SYSTEM_NAME: ""
  # For GPU support (henrygd/beszel-agent-nvidia only)
  # NVIDIA_VISIBLE_DEVICES: "all"
  # NVIDIA_DRIVER_CAPABILITIES: "compute,video,utility"
secret:
  existingSecret: "" # my-beszel-token
  tokenKey: "token"
  sshKey: "key"

Then within the deployment/daemonset (if the existingSecret value is not empty) mount that secret instead. Also skip the creation of the secret.

Also the HUB_URL could be default the one you specified: "http://beszel-hub:8090" so that is really optional. right now the default value is just empty - which makes the agent log out an error, that it can't connect to the hub.

[cloudwithdan]

@tim-krehan yes totally, thank you for your suggestion, that really is the best helm chart practice. I will update the helm chart, since I am migrating ingress-nginx to Traefik Gateway API, I will need the httproute myself, I will also add support for Gateway API. 🚀

[tim-krehan]

looks good! Secret works, small typo in the httproute file.