The Helm chart for FusionAuth 1.53.4 has been released and should now be available in the FusionAuth charts repository.

In the meantime, if you need to deploy a specific FusionAuth version before the corresponding Helm chart is released, you can override the image tag in your Helm values file:

image: tag: "1.53.4"

This allows you to use the latest Helm chart while specifying the exact FusionAuth Docker image version you need.

Related Documentation Deploy with Kubernetes - Helm Chart Configuration - Complete guide on configuring and deploying FusionAuth using Helm charts Deploy FusionAuth to the Cluster - Instructions for installing and verifying your Helm deployment Kubernetes Overview - Overview of FusionAuth on Kubernetes with architecture diagrams Upgrade FusionAuth - General guidance on upgrading FusionAuth installations

When you override the image tag in your values.yaml file, you can verify the correct version is deployed by checking the IMAGES column in your Kubernetes deployment:

kubectl get deployments -o wide

There are a couple of things to check:

make sure that you've updated the issuer at the tenant screen: https://fusionauth.io/docs/v1/tech/core-concepts/tenants#general make sure you are using an asymmetric keypair to sign the id token. If you are using HMAC, which is the default for FusionAuth, you have to share a secret. Asymmetric algorithms like RSA256 are what proxies typically need (so they don't have to have the signing secret). More here: https://fusionauth.io/docs/v1/tech/core-concepts/applications#jwt and here: https://fusionauth.io/docs/v1/tech/core-concepts/key-master

Hope that helps.

No. Our cloud is a fully managed system, so you shouldn't care about the underlying technology.

It isn't built with Kubernetes so when we launch a deployment in it, it's constructed using a different approach.

If you want to run FusionAuth with kubernetes, that is supported, but you must self-host. More details here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/

Proxy servers can store cached copies of sites. You will get the data from the proxy when you access a particular location.

Sorry, no kub expert here. I'm not sure how to teardown just the database, but I assume you could write a script to connect to the backing database and drop the tables/schema, etc. That might be quicker than dropping the entire cluster.

If you figure out a better way, please share!

As of q4 2021, FusionAuth officially supports Kubernetes.

You can read the docs here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/