Unfortunately, Passkeys cannot currently be used as an MFA method in FusionAuth's native hosted MFA flow. There is an open feature request for this functionality.

Workaround

You can implement a step-up authentication pattern using FusionAuth's WebAuthn API:

After the user completes email + password login, your application calls /api/webauthn/start The authenticator produces a signature Your application calls /api/webauthn/assert to verify possession of the passkey Only grant access if the assertion succeeds

You can check whether a user has a registered passkey by calling /api/webauthn?userId={userId}.

Important limitation: This workaround runs in your application code, not inside FusionAuth's hosted MFA screen. Passkeys will not appear alongside email and authenticator app in the same native picker — you would need to build that UI and enforcement logic yourself in your application.

A feature request has been logged for native passkey MFA support in FusionAuth's hosted flow.

Related Documentation Authentication With WebAuthn & Passkeys - Complete guide to implementing WebAuthn/passkeys in FusionAuth WebAuthn API Reference - API endpoints for starting and completing WebAuthn authentication ceremonies Start a WebAuthn Passkey Assertion - Documentation for the /api/webauthn/start endpoint Retrieve a Passkey - How to check if a user has registered passkeys using /api/webauthn?userId={userId} Multi-Factor Authentication (MFA) - Overview of FusionAuth's native MFA methods (TOTP, email, SMS) Step-Up Authentication - General guidance on implementing step-up auth patterns in FusionAuth Can I do a step up authentication with WebAuthn/passkeys? - Community discussion on this exact use case

Unfortunately, the passwordless login code TTL cannot be configured per application—it is only available as a tenant-level setting in FusionAuth. The default TTL is 180 seconds, and this is configured via tenant.externalIdentifierConfiguration.passwordlessLoginTimeToLiveInSeconds.

Here are two potential workarounds:

1. Separate Tenants

Since the setting is per tenant, you could place applications that require different code lifetimes into separate tenants. Note that this means users and configuration will be isolated per tenant, so carefully evaluate whether this trade-off fits your architecture.

2. Build Your Own Passwordless Flow

You can implement custom code expiration logic by using the passwordless API directly:

Start the login with /api/passwordless/start Deliver the code through your own mechanism Track when you issued each code in your application Enforce your desired per-application expiry by rejecting codes that are too old before calling the completion endpoint Complete the login with /api/passwordless/login

With this approach, the tenant-level TTL acts as the maximum lifetime, but your application logic can enforce shorter, application-specific expirations as needed.

This is not a built-in FusionAuth feature, so if per-application passwordless code TTL is important to your use case, consider submitting a feature request on the FusionAuth GitHub issues page.

Related Documentation Passwordless Login Overview - General overview of passwordless authentication in FusionAuth Magic Links Guide - Details on magic links and one-time code customization, including TTL configuration Passwordless API - Complete API reference for building custom passwordless flows Start Passwordless Login API - API to generate a passwordless code Complete Passwordless Login API - API to complete the passwordless login Tenant Configuration - Tenant-level external identifier settings including passwordless login TTL

FusionAuth supports customization for some of these scenarios through themes, but not all:

1. Root Path Customization

This is possible. The Index page can be customized through your FusionAuth theme. You can add a redirect (for example, using JavaScript or a meta refresh tag) to send users to your application's login page.

Important: When FusionAuth can't identify the tenant (including when browsing to / without client_id or tenantId parameters), it uses the default tenant. To theme the root page:

Create a copy of the built-in theme — the default theme is immutable because it ships with FusionAuth Edit the index template in your copy to include your redirect (using JavaScript like window.location.href = "https://yourapp.com/login" or HTML meta refresh) Apply this theme to ALL tenants, including the default tenant Test with tenant specified — try the root URL with tenantId or client_id to confirm your edited theme renders

See the Advanced Themes troubleshooting guide for more details on theme issues.

Related: GitHub Issue #378

2. OAuth Error Handling

This is also possible. The OAuth error page can be customized in your theme, so you can implement the same redirect approach for customers who saved stale or broken login links. The OAuth error template is available for customization and you can add JavaScript or meta refresh redirects to handle these scenarios.

Note that OAuth errors can also be returned as redirect parameters to your application's callback URL (depending on the OAuth flow), which allows your application to handle errors directly rather than showing the FusionAuth-hosted error page.

3. 404 Pages for Invalid URLs

This is NOT currently customizable. The 404 page cannot be customized, including on Cloud deployments. Requests to invalid paths (like /whatever) will show the default error page. This is a known limitation tracked in GitHub Issue #404, which requests additional themed error pages (including 404 and 500 pages).

Summary

You can handle root path and OAuth error redirects through theme customization by adding JavaScript redirects to the index and OAuth error templates. However, true 404 pages remain uncustomizable. CloudFront configuration is not exposed to customers on cloud deployments, so there's no workaround at that layer.

Related Documentation Advanced Themes Documentation - Complete guide to customizing FusionAuth themes Theme Templates - Full list of available templates including Index and OAuth error Theme Template Variables - Variables available in each template Index Template Variables - Specific to the root page OAuth Error Template Variables - Specific to OAuth error page OAuth Error API Documentation - How OAuth errors are returned Default Tenant Configuration - Understanding the default tenant

Hiya @florent-bossuyt ,

Thanks for using FusionAuth.

The upgrade to 1.59.0 added support for phone number as a first class identity. While I don't know for sure, it is possible that impacted lastLoginInstant. I'm not aware of any bug filed.

It's also possible you can find the data previously in the lastLoginInstant in the user.identities[x].lastLoginInstant value, available when you retrieve a user.

Since this is not a known issue, there's no documented procedure for reconciling the data, unfortunately.

Here's one approach, though.

If you have a database backup of the 1.57.0 release, you could stand up a FusionAuth instance pointing to that, and find all the users with a lastLoginInstant that is not null (set A). You'd then run the same query against your prod instance (set B). Then find the folks in set A who are not in set B (call them set C). Set C are the people you need to update.

Unfortunately, you can't update their lastLoginInstant directly. But you can fake a login using the passwordless APIs, which should set it. That is outlined here.

So you'd want to perform that for all the users in set C.

Hope that helps.

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

The rate limiting you're encountering is applied at the WAF (Web Application Firewall) level on FusionAuth Cloud, not from the FusionAuth application itself. These rate limits protect customers and are standard across all FusionAuth Cloud deployments.

Rate Limit Configuration

FusionAuth does not publish rate limits publicly and they are subject to change.

Please open a support ticket to obtain more guidance.

Whitelisting for Performance Testing

Since these are network-level rate limits, they cannot be configured within your deployment. However, IP allow listing is available to bypass rate limiting for performance testing if your IP address meets these requirements:

It is static It is owned by your company (not shared infrastructure like a CDN) It is associated with a production server (not a developer's laptop)

If you can provide a static IP address that meets these criteria, you can open a support ticket to get it allow listed. Note that allow list changes typically take two to three business days to implement.

Best Practices for Performance Testing

When planning load or performance tests against FusionAuth Cloud:

Open a support ticket before testing to notify the FusionAuth team of your planned stress test window Don't use Basic cloud deployments for performance testing, as they run on limited infrastructure and results won't be representative. Use a Business or High-Availability plan instead, which you can spin up, test, and tear down as needed Implement exponential backoff when you receive a 429 response - this is the recommended approach for handling rate limits gracefully Distribute requests over time rather than sending bursts of traffic Alternative Testing Approaches

If you cannot obtain an allow-listable static IP address (such as for developer machines or CI/CD pipelines), consider:

Running a self-hosted FusionAuth instance for automated testing, which gives you full control over rate limiting configuration Using smaller-scale testing that stays under the rate limits Related Documentation FusionAuth Cloud - CAPTCHA and Rate Limits FusionAuth Cloud - Load Testing Troubleshooting FusionAuth Cloud API Calls User Search API Documentation Advanced Threat Detection - Customizable Rate Limiting (for application-level rate limits within FusionAuth)

The postMethod variable can be null or missing in certain scenarios (such as when a verification link is clicked multiple times), causing the FreeMarker template to fail.

To fix this, you need to provide a safe fallback for the postMethod variable. Update line 16 in your registration/verify.ftl template from:

[#if verificationId?? && postMethod]

To:

[#if verificationId?? && (postMethod!false)]

The !false syntax provides a default value of false when postMethod is null or missing, preventing the FreeMarker exception.

Steps to apply the fix:

Navigate to Customizations → Themes in the FusionAuth admin UI Edit your theme Locate the registration/verify.ftl template Update the conditional check as shown above Save the theme

This pattern can be applied to other templates where variables might be null or missing in certain execution paths.

Why this happens:

According to the FusionAuth documentation, the postMethod variable is not a standard template-specific variable for the /registration/verify template. It is typically available on other verification templates like /email/verify (where it defaults to true). The registration verify template is rendered when a user clicks the URL from the verification email and the verificationId has expired or is invalid. In these scenarios, postMethod may not be set in the template context, which causes the FreeMarker error when attempting to evaluate it as a boolean.

Related Documentation Theme Template Variables - Verify Registration - Documents the variables available in the registration verify template Theme Template Variables - Email Verification - Shows that postMethod is documented for email verification but not registration verification Theme Template Variables - Complete reference for all template variables across different templates

This issue was caused by a bug that existed prior to version 1.68.0. In earlier versions, there was a problem where LDAP connectors scoped to specific domains could incorrectly be called (or not called) for users outside those domains. This could result in the connector appearing to stop functioning entirely after an upgrade.

Solution:

Recreate the LDAP connector configuration. When doing so, verify the Domains field:

If you need the connector to apply to all users, use a wildcard (*) for the domains. If you need domain-specific scoping, explicitly configure the same domains you had previously.

This bug was fixed in FusionAuth 1.68.0. See the release notes for details:

Fixed an issue where Connectors configured for a specific domain in a Tenant could be called for users outside of that domain.

If you encounter this issue after upgrading to 1.68.0 or later and recreating the connector does not resolve it, verify:

Debug mode is enabled for both the connector and the reconcile lambda. The LDAP server is reachable from the FusionAuth instance. Event log and system log (fusionauth-app.log) for any connection or authentication errors.

The user.login.suspicious webhook event requires the Client Risk Configuration to be enabled at the tenant level. Even though Risk Signals are evaluated by default, the webhook event itself won't fire unless this configuration is explicitly turned on.

To enable it:

Navigate to Tenants → Select your tenant → Edit → Security tab Find the Client Risk Configuration section Ensure it's enabled for your tenant

Additionally, verify that the user.login.suspicious event is enabled in the tenant's webhook settings:

Go to Tenants → Select your tenant → Edit → Webhooks tab Confirm user.login.suspicious is checked/enabled

Once both are configured, your webhook should start receiving user.login.suspicious events along with details about which Risk Signals triggered the suspicious login determination.

About Risk Signals and Email Volume

If you're seeing a significant increase in suspicious login emails after upgrading to 1.68.0 or later, this is because FusionAuth introduced comprehensive Risk Signals in version 1.68.0. Previously, only Impossible Travel was tracked. Now additional signals are evaluated including:

Untrusted Device Unrecognized Device Recent Password Change Recent Identity Change Dormant Password Suspicious Agent

All Risk Signals are enabled by default without any configuration changes.

Managing Email Volume

You can tune which Risk Signals trigger suspicious login alerts:

Go to Tenants → Select tenant → Edit → Security tab → Client Risk Configuration Disable specific Risk Signals that are generating too many false positives for your use case Monitoring Without Sending Emails

You can monitor webhook events while tuning your Risk Signals without sending emails to users:

Go to your tenant/application settings → Identities tab Change the Suspicious Login template to "No Template Selected" Monitor your webhook endpoint to see which Risk Signals are triggering Fine-tune your Risk Signal configuration Re-enable the email template once you're satisfied with the detection accuracy

The webhook fires whenever a Risk Signal threshold is met, independent of whether an email template is configured. This allows you to observe and tune the system before alerting end users.

Yes, you need to create two separate applications within the same tenant in FusionAuth. Here's how to configure this:

Configuration Steps

Create both applications in the same tenant - Users are scoped at the tenant level, so applications in the same tenant can share authentication state through FusionAuth's SSO session.

Enable self-service registration on the second application - This ensures a seamless login experience. When a user navigates to the second application while already authenticated to the first, they will be automatically registered and logged in.

How It Works User logs into the first application at your registration URL to create their account. Make sure the rememberDevice parameter is true or checked. You can modify your theme to hardcode that value. While that session is valid, they navigate to the second application's login URL They are automatically registered and authenticated to the second application without manual intervention

The key to this working is that FusionAuth creates an SSO session at the tenant level when a user logs in and rememberDevice is checked. When the authenticated user tries to access the second application, FusionAuth recognizes the existing SSO session and automatically creates a registration for that user in the second application (when self-service registration is enabled).

Password Reset Behavior

Because users are scoped at the tenant level, a password reset applies to all applications under that tenant. Users can utilize the password reset page for the first application and will be able to log in at the second application with the new password.

Sharing Templates

Both applications can share the same theme and templates. Themes are assigned at the tenant level (though you can also assign application-specific themes if needed starting with FusionAuth 1.27+). This means you can configure one set of templates - including password reset, login, and user management pages - that will be used by both applications.

Pre-creating User Accounts

If you create user accounts ahead of time, you can automatically include the registration for the second application when creating the users. This would mean adding that application to their registrations when you create the account initially using the Create a User and Registration API.

Related Documentation Implementing Single Sign-On - Complete guide to configuring SSO between applications Self-Service Registration - How automatic registration works when SSO is enabled Create a User Registration API - Programmatically register existing users to additional applications Application Themes - Configure application-specific themes if needed Themes Documentation - Customize and share login pages and templates across applications

FusionAuth tenants provide logical isolation, not physical isolation. While users, applications, groups, and configuration are logically separated per tenant, all tenants in an instance share the same FusionAuth nodes, database, and search index.

This means that while importing data into one tenant will not impact the data integrity in another tenant, it does draw on the same compute and database capacity that other tenants' logins and profile updates use. Large imports can potentially affect performance across all tenants.

Recommendations to minimize impact:

Serialize imports: Do not run multiple imports simultaneously. Even when migrating multiple clients, avoid having two clients in the initial import phase at the same time.

Pre-hash passwords: Since you're already sending passwords with hash, salt, factor, and encryption scheme, this will significantly reduce load during imports. If passwords were sent as plaintext, FusionAuth would need to hash each one on import (which can take several hundred milliseconds per user).

Start with smaller batches: Rather than immediately using 100k user batches, start smaller to monitor system performance during imports. If performance is acceptable, gradually increase the batch size until you find the right balance between performance and import speed.

Avoid transactional webhooks: You mentioned using Kafka integration instead of custom webhooks, which is good. Ensure you are only using the Kafka integration for events and not using any transactional webhooks, as these can add additional load during imports. Transactional webhooks block the operation until the webhook completes, which can significantly slow down bulk imports. Non-transactional events (like those sent to Kafka) are fire-and-forget and don't block the import process.

Limit concurrent operations: You mentioned planning to run only one import call at a time from one worker, which is the right approach. Updates using the PATCH endpoint can occur in parallel as they should be infrequent.

Monitor database performance: Keep an eye on your database connection pool and query performance during imports. The shared database is typically the bottleneck in multi-tenant scenarios under heavy load.

By following these practices, you can minimize the impact of bulk imports on other tenants in your multi-tenant FusionAuth deployment.

Related Documentation Multi-tenancy Guide - Overview of FusionAuth's multi-tenant architecture and concepts Levels of Isolation - Explanation of logical vs. physical isolation in FusionAuth Import Users API - API documentation for bulk user imports Password Hashes - Details on importing pre-hashed passwords to improve performance Transactional vs. Non-Transactional Events - Understanding event types and their performance impact Kafka Integration - Using Kafka for non-blocking event processing Scaling Your Auth - Best Practices - Performance and scaling considerations for authentication systems

At this time, FusionAuth Cloud does not support customizing HTTP security headers on individual tenant deployments. There is an existing GitHub feature request tracking this capability, but it is not currently on the roadmap and no ETA is available for when this might be added.

If you are running a self-hosted FusionAuth instance, you can configure these headers using a reverse proxy (nginx, Apache, etc.) in front of FusionAuth. For FusionAuth Cloud customers, this configuration is managed at the infrastructure level and cannot be modified per-tenant.

You may want to subscribe to or comment on the relevant GitHub issue to track progress on this feature request.

This is a known bug in FusionAuth 1.69.x that affects the System Logs page when viewing logs from multiple nodes in a cluster.

The issue has been confirmed and logged with the FusionAuth development team. The 401 errors occur when the UI attempts to fetch log content from other nodes in the cluster, causing the tab-switching functionality to fail intermittently.

Unfortunately, there is no workaround available at this time. The bug will be addressed in a future release.

As a temporary measure, you may need to:

Refresh the page multiple times when checking logs across nodes Navigate away from and back to the System Logs page to trigger a reload Access logs directly from individual nodes if you have that capability in your deployment

Once this issue is resolved in a future version, the System Logs page should reliably display logs from all nodes without authentication errors.

FusionAuth does not have a direct passthrough option to prevent storing user data from social login providers. However, there are several approaches to handle this:

Option 1: Use a Reconcile Lambda (Recommended for Social Login)

For social login providers like Google, you can use a reconcile lambda to intentionally overwrite the user data with placeholder values before it's permanently stored:

function reconcile(user, registration, idToken) { // The idToken is the response from the tokeninfo endpoint // https://developers.google.com/identity/sign-in/web/backend-auth#calling-the-tokeninfo-endpoint user.firstName = "Purposely not set"; user.lastName = "Purposely not set"; user.fullName = "Purposely not set"; user.imageUrl = "http://www.notset.com"; }

This ensures that personal data from the social provider is replaced immediately during the reconciliation process.

Option 2: Minimal Registration Form

For new user registrations (non-social), configure your registration form to collect only email and password, avoiding the collection of first/last name entirely.

Option 3: Use Webhooks to Clear Data

Implement a user.create.complete webhook that listens for new user creation events, then use the FusionAuth User API to clear the personal data fields and move them to your profile service. Note that this approach means user data will briefly exist in FusionAuth before being cleared.

Option 4: Lambda with External Fetch (Advanced)

You could use lambdas with fetch calls to move data to your profile service and set FusionAuth fields to null. However, this introduces latency due to network calls during authentication flows.

For Existing Users

If you already have users with stored data, use the User API to programmatically clear the values for all existing users.

You can use the linked APIs, and that’s the option most people find first. The step-up flow in the API docs works, but means your app owns the challenge. It has to start it, collect the code, and handle the result. That’s a lot for what is basically “make the user log in again because they are about to do a sensitive thing.”

There’s another way that’s a little different, and it leverages login. Since version 1.60 the authorize endpoint supports the standard OIDC prompt and max_age parameters.

When your app hits a sensitive action, don't call any specific APIs. Instead, it can redirect the user to /oauth2/authorize with prompt=login and/or with a max_age small enough that their existing SSO session doesn’t satisfy it. FusionAuth shows the hosted login page, the user authenticates, and you get a fresh token back. Same code you already wrote for login, with one query parameter added.

Make sure you put the current page/location in the state so you can deliver the customer back to where they were. Here's a video on deep linking.

Using either max_age=0 and prompt=login end up in roughly the same place. I’d use max_age if you want a window like “re-auth if it’s been more than five minutes,” and prompt=login if you want it every time.

A successful redirect doesn’t prove everything. Your app still has to decide whether the token it’s looking at came from a recent authentication.

That’s what the auth_time claim is for. It’s a reserved claim in the JWT body (it moved there in 1.60, and lambdas can’t override it), so your resource server compares it against the clock and rejects beyond your threshold. If it’s too old, send the user back through authorize.

That’s basically the max_age half of RFC 9470, just without FusionAuth issuing the WWW-Authenticate challenge for you. You’d write that 401 yourself.

Caveats:.

This forces a re-login, not necessarily a stronger one. If the user re-authenticates with a password and nothing else, you’ve proven recency and nothing about strength. If you need the second factor on that re-auth, you need MFA to actually fire. A static policy of Required will do it. On Enterprise, the MFA Requirement Lambda can make the decision per request. There’s no acr-style “this was step-up” claim. You get “authenticated at time T,” not “authenticated with a second factor at time T.” If your auditors need the latter, this approach won’t give it to you cleanly, and falling back to the step-up auth API is a better option. It’s a full redirect. For a banking-style “confirm this transfer” flow where bouncing the user to another page is a non-starter, the step-up API approach is still right. This only works when you are using the hosted login pages, not the Login API.

The short version: if sensitive actions are coarse-grained (“view the billing page,” “change the email address”), the redirect approach might work for you. It’s less code, the hosted pages handle the UI, and you’re not maintaining a custom MFA challenge.

But if you need per-operation binding or proof of which factor was used, look at the step-up API.

This behavior occurs when the client sends an Accept-Encoding header that includes compression algorithms, but FusionAuth's response handling doesn't support the requested encoding method in certain configurations.

The solution is to explicitly use Accept-Encoding: identity in your API requests. The identity value indicates that no encoding transformation should be applied, which FusionAuth handles correctly.

If you're using an HTTP client library that automatically adds Accept-Encoding: gzip or similar headers, you should:

Override the default Accept-Encoding header to use identity Or configure your HTTP client to not send compression-related headers automatically

Example:

GET /api/user/search HTTP/1.1 Host: your-fusionauth-instance.com Authorization: <your-api-key> Accept-Encoding: identity

This ensures consistent API responses without encountering 406 errors related to content encoding negotiation.

@chatteberg I just saw your post. If you have a paid support plan you can open a ticket. If you do not have a paid support plan, are you still experiencing the issue?

You can avoid the fresh local install by pulling the theme files directly from the fusionauth-theme-history repository:

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

To use this with the theme-helper repo:

Download your current customized theme using download.sh from the theme-helper repo Grab the new target version's theme files from fusionauth-theme-history Run diff-themes.sh from theme-helper against the two folders to see what changed

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:

git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch

Then apply it to your theme repository:

git am --3way update-themes.patch

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

Related Documentation Upgrade an Advanced Theme - Complete guide for upgrading custom themes Theme History Repository - Official documentation on using the fusionauth-theme-history repo (available back to version 1.23.0) Theme Helper - Documentation for the fusionauth-theme-helper tool Advanced Theme Upgrade Notes - Version-specific upgrade requirements and breaking changes Themes API - API reference for programmatically retrieving theme files

FusionAuth 1.69.0 introduced changes to how Apple identity provider keys are handled. If your Apple identity provider was configured before upgrading to 1.69.0, you may need to update the key configuration.

To resolve this issue:

Review the 1.69.0 migration guide for specific details about Apple identity provider key changes Navigate to your Apple identity provider configuration in the FusionAuth admin UI Verify that the signing key is properly configured and valid If needed, re-import or reconfigure the Apple private key used for the identity provider Test the Sign in with Apple flow after making these changes

The migration guide contains detailed steps for addressing key-related issues introduced in this version.

When submitting a custom password hasher plugin (or any plugin JAR) for installation on FusionAuth Cloud, you should:

Open a support ticket through the account portal as normal (text-only is fine) Reply to the ticket conversation in Slack with the plugin JAR file attached

The account portal does not accept file attachments during ticket creation, but replying via Slack to an open ticket thread allows you to send files directly to the support team.

Note: Some file-sharing platforms (like Slack) may block .jar files for security reasons. If this happens, you can zip the JAR file first and attach the .zip instead.

Installation considerations

When requesting plugin installation, be sure to specify:

Which specific Cloud deployments/tenants need the plugin installed Whether users are actively logging in (there may be 1-2 minutes of downtime during deployment) Your preferred time window for the installation if downtime is a concern Any considerations for dev/test environments if you have ongoing testing

The support team will handle uploading and rolling the deployment with the new plugin.