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:

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

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:

github.com/FusionAuth/fusionauth-theme-history/tree/main

To use this with the theme-helper repo:

This approach lets you diff your customized theme against the base theme for any FusionAuth version without needing to spin up a local FusionAuth instance.

Alternative approaches:

If you prefer working directly with git, you can clone the theme-history repo and use git's built-in diffing. For example, to generate a patch between two versions:

Then apply it to your theme repository:

You can also use GitHub's built-in diff viewer to compare themes across versions directly in your browser.

For test environments with large user populations, follow this workflow:

Kickstart will only run on an empty instance, so the down -v step is necessary. Configure a Kickstart file with your test environment configuration (tenants, applications, API keys) for reproducible deployments.

Note that tenant deletion is an asynchronous operation (as of FusionAuth 1.22), meaning it runs in the background. For very large tenants (2M users), this will still take time but is considerably faster than bulk deleting millions of users through the API.

If you're also seeing CloudFront timeouts during large batch imports (e.g., 100k users), the same 30-second CloudFront limit applies. Consider reducing batch sizes when users have multiple registrations, as each registration inserts additional rows into related tables (registrations, application role mappings, etc.), significantly increasing processing time. For best import performance, minimize network hops and consider setting validateDbConstraints to false.

So basically whenever you are sending the redirect to the browser (pretty much just the authorize and logout URLs) you use externalFusionAuthURL which references localhost.

When you are communicating with FusionAuth from the application backend (the express app) you use the internalFusionAuthURL which references the docker domain name.

I tested that out and it seems to work fine.

Give that a try.

Thanks for the question. The reason that you are not seeing anything in this view is you need to have a docker logger set up. FusionAuth will write system logs to STDOUT. This output must be picked up by a logger in Docker (which can then be reviewed). By contrast, if you were running FusionAuth in a non-containerized environment, this view would show you current system logs.

Hope this helps!

Thanks,
Josh

I use the default docker-compose.yml, but use this docker-compose.override.yml:

Then I configure the SMTP settings to use the hostname mailcatcher and the port 1025. I can then send email and view it in the mailcatcher interface, at localhost:1080.

Here's the relevant dockerfile: https://github.com/yappabe/docker-mailcatcher/blob/master/Dockerfile

Here's more about mailcatcher: https://mailcatcher.me/

You can also switch to the database search engine and see if removing ES resolves the issue. At that point it might be a resource issue.

https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines/ has instructions on how to change these.

You would probably be better off creating your own index.

It's not responding at the port 9011, like it should.
Is there a way to test or ping the FusionAuth App to make sure its up and running other than using docker ps -a?

Yes, there are several ways to test or ping the FusionAuth App to check if it's up and running without relying on the docker ps -a command. Here are a few alternative methods:

Curl or wget: You can use the curl or wget command-line tools to send a request to the FusionAuth App's endpoint and check the response. For example, you can run curl http://localhost:9011 or wget http://localhost:9011 to send a GET request to the FusionAuth App running on port 9011. If you receive a valid response, it indicates that the app is up and running.

Telnet: You can use the telnet command to establish a connection to the FusionAuth App's port and check if it's open and responsive. Run telnet localhost 9011 to attempt a connection to the FusionAuth App on port 9011. If the connection is successful, it means the app is running and accepting connections.

Browser access: Simply open a web browser and enter the URL http://localhost:9011 to access the FusionAuth App. If the app is running correctly, you should be able to see the login or landing page.

API client: If the FusionAuth App provides an API, you can use an API client like Postman or cURL to send a request to the API endpoints and verify if you receive the expected responses.

These methods allow you to test the availability and responsiveness of the FusionAuth App without relying on the docker ps -a command or using Docker-specific tools.