Deploy Freqtrade on Kubernetes

If you’ve searched for a good way to deploy Freqtrade on Kubernetes, you’ve probably seen the same pattern over and over:

You can get something running, but getting something clean, reusable, and easy to understand is another story.

That was the gap we wanted to close.

We built the OTWLD Freqtrade Helm Chart because we wanted a version of Freqtrade on Kubernetes that didn’t feel like a pile of YAML glued together over three late nights. We wanted something you could install fast, understand quickly, and extend without regretting it a week later.

So that became the bar:

• easy to deploy
• easy to read
• easy to adapt
• good examples
• clean FreqUI setup
• persistent storage by default
• support for one bot or a real multi-bot fleet

That’s what this chart is.

Freqtrade Helm Chart dashboard running on Kubernetes

What This Helm Chart Actually Gives You

This is a Helm chart for people who want to run Freqtrade, not spend hours reverse-engineering a chart before they can trust it.

With this chart, you can:

• deploy Freqtrade on Kubernetes with Helm in a few commands
• start from real example files instead of an empty values file
• run a shared FreqUI dashboard
• deploy isolated bots in the same release
• keep bot data on persistent volumes
• expose a public dashboard while keeping bots private
• use image-based strategies, mounted strategies, or Git sync
• add Telegram support per bot

That’s the value. Less setup friction, fewer moving pieces to invent yourself, and a much faster path from “I want to try this” to “it’s running.”

We Optimized for the First 15 Minutes

A lot of infrastructure projects are technically flexible but practically annoying. They give you infinite knobs and no clear starting point.

We went the other way.

The OTWLD Freqtrade Helm Chart ships with example configs for the setups people actually want:

• minimal.yaml for a quick first install
• dashboard-and-bots.yaml for a shared UI plus multiple bots
• recommended-fleet.yaml for a more production-style baseline
• public-dashboard.yaml for graphing and shared visibility
• private-bot-ui.yaml for private operator access
• strategy-init-sync.yaml for Git-based strategy delivery
• external-secret.yaml for secret-manager driven setups

That means you’re not starting from theory. You’re starting from a working pattern.

FreqUI Is a Big Part of the Point

One of the main reasons to run Freqtrade this way is that the dashboard story is much cleaner.

Instead of treating every bot as a one-off service you manually babysit, you can run a shared dashboard for FreqUI and graphing, then manage bots behind it in a more organized way.

That gives you a setup that feels much closer to a real system:

• one place to access the UI
• one Helm release for the fleet
• isolated bot runtimes
• optional recurring data jobs for graph pages
• cleaner ingress decisions

For people running more than one bot, this matters immediately.

We Also Tried to Remove the Annoying Stuff

Good deployment UX is not just about install commands. It’s about not getting tripped up by dumb problems later.

So we hardened the chart around the stuff that wastes time in real deployments:

• persistent storage for user_data
• safer handling of SQLite paths
• render-time validation for common mistakes
• better example coverage
• clearer upgrade flow
• more predictable bot and dashboard behavior

In v0.3.3, we specifically tightened persistence and UI-related behavior so deployments are less likely to fail in confusing ways. That’s not glamorous release-note material, but it’s exactly the kind of work that makes a chart actually usable.

Deploy Freqtrade on Kubernetes in Minutes

If your goal is simply to get started fast, the install flow is straightforward:

helm repo add otwld https://helm.otwld.com/
helm repo update
helm upgrade --install freqtrade otwld/freqtrade \
  --namespace freqtrade \
  --create-namespace \
  -f values.yaml

From there, pick the example closest to what you want and adapt it.

If you just want to see it work, start with the minimal example.

If you want to understand the real value of the chart, start with the recommended fleet example.

Suggested alt text: Recommended Freqtrade fleet deployment on Kubernetes

Why We’re Sharing It

We built this because we wanted it ourselves.

We wanted a Freqtrade Helm chart that felt like it had already done the thinking most users end up doing on their own: storage, examples, FreqUI, bot isolation, secrets, sensible defaults, and a layout that makes sense when you come back to it later.

There’s still plenty we can improve, but the important part is this: it’s already useful.

If you want to run Freqtrade on Kubernetes without building your own chart from scratch, this gets you there faster and with a lot less friction.

Try the Chart

The chart is available here:

• GitHub: https://github.com/otwld/freqtrade-helm-chart
• Helm repo: https://helm.otwld.com/

If you end up using it, copy an example, replace it with your own config, and ship. That’s the whole point.

FAQ

What is the best way to deploy Freqtrade on Kubernetes?

If you want the fastest path without building your own manifests, a Helm chart is the best option. The OTWLD Freqtrade Helm Chart gives you a clean install flow, persistent storage, FreqUI support, and example configs you can use immediately.

Does this Freqtrade Helm chart support multiple bots?

Yes. The chart is built around a shared dashboard and isolated bots[], so you can run one bot or a small fleet in the same Helm release.

Can I use FreqUI with this chart?

Yes. The chart supports a shared dashboard for FreqUI and graphing, which is one of the main reasons to use it instead of managing separate one-off deployments.

Does it include example values files?

Yes. That’s one of the strongest parts of the project. It ships with examples for minimal installs, shared dashboards, recommended fleets, public dashboards, private bot UIs, Git-based strategy sync, and external secret setups.

Is it suitable for production-style deployments?

Yes, especially if you want a cleaner baseline with persistent volumes, isolated bots, private bot APIs, and a more maintainable Helm-based workflow.