<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with limits]]></title><description><![CDATA[A list of topics that have been tagged with limits]]></description><link>https://fusionauth.io/community/forum/tags/limits</link><generator>RSS for Node</generator><lastBuildDate>Sun, 07 Jun 2026 20:33:52 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/limits.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Limiting sessions to one IP address]]></title><description><![CDATA[<p dir="auto">No, this isn't currently possible.</p>
<p dir="auto">I think that would fall into the threat detection bucket of features we are planning. Feel free to add any notes, comments or suggestions here: <a href="https://github.com/FusionAuth/fusionauth-issues/issues/905" rel="nofollow ugc">https://github.com/FusionAuth/fusionauth-issues/issues/905</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/516/limiting-sessions-to-one-ip-address</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/516/limiting-sessions-to-one-ip-address</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Limit on tenants]]></title><description><![CDATA[<p dir="auto">No hard limits, we have some clients running somewhere between 5-10k.</p>
<p dir="auto">If you encounter any performance degradation, you can open a <a href="https://github.com/fusionauth/fusionauth-issues/issues" rel="nofollow ugc">GitHub issue</a> and we will take a look. We do have some work in plan to <a href="https://github.com/FusionAuth/fusionauth-issues/issues/374" rel="nofollow ugc">improve the UI for this type of scale</a>.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/464/limit-on-tenants</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/464/limit-on-tenants</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How many applications and tenants can I have in FusionAuth?]]></title><description><![CDATA[<p dir="auto">Ah, yes, thanks for explaining.</p>


<p dir="auto">Yes</p>


<p dir="auto">You have two options</p>



use the API to integrate with the current login/reg flow with FusionAuth. This lets you keep your existing html pretty much untouched, you're just calling out to FusionAuth instead of the database.
remove them and use the FusionAuth provided pages with OIDC. This lets you use the theming and localization capabilities of FusionAuth, including super simple social signon.

<p dir="auto">It's your choice based on what your needs are, either way will work.</p>
<p dir="auto">I'd only recommend using SAML if you have an application which only supports SAML, not OIDC.</p>
<p dir="auto">You'll also want to make sure that when someone registers with one of your applications in FusionAuth, they register with all three. I'd probably use a webhook to ensure that.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/295/how-many-applications-and-tenants-can-i-have-in-fusionauth</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/295/how-many-applications-and-tenants-can-i-have-in-fusionauth</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Restrictions on redirect URIs?]]></title><description><![CDATA[<p dir="auto">Support for wildcards in redirect URIs just landed in 1.43.</p>
<p dir="auto">We don't recommend using these because they are against the OAuth specification (you could look at using the state parameter instead).</p>
<p dir="auto">But we listened to the community feedback on this issue: <a href="https://github.com/FusionAuth/fusionauth-issues/issues/437" rel="nofollow ugc">https://github.com/FusionAuth/fusionauth-issues/issues/437</a> and implemented it.</p>
<p dir="auto">It is still being documented, but you can read about it here: <a href="https://fusionauth.io/blog/2023/02/16/announcing-fusionauth-1-43#support-for-wildcards-in-redirect-urls" rel="nofollow ugc">https://fusionauth.io/blog/2023/02/16/announcing-fusionauth-1-43#support-for-wildcards-in-redirect-urls</a></p>
<p dir="auto">Hope that helps, <a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/139">@davidmw</a> !</p>
]]></description><link>https://fusionauth.io/community/forum/topic/226/restrictions-on-redirect-uris</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/226/restrictions-on-redirect-uris</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How large can the data field be for any of the FusionAuth resources?]]></title><description><![CDATA[<p dir="auto">If you're using PostgreSQL the size is essentially unlimited. With MySQL it is 16 MB.</p>
<p dir="auto">There are few exceptions to this rule where we may be using a 64 KB column if you're on MySQL.</p>
<p dir="auto">I wouldn't recommend storing that much data however. If you're using Elasticsearch, the custom data on the User will be indexed, and Elasticsearch will eventually hit a limit as well.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/89/how-large-can-the-data-field-be-for-any-of-the-fusionauth-resources</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/89/how-large-can-the-data-field-be-for-any-of-the-fusionauth-resources</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>