Multi-Tenant Extensions

Before an SDK extension is deployable, the code is placed in a docker container, and then that docker container is deployed to a server. An extension is considered single-tenant when a new docker container is deployed per install and is the typical install type for extensions specifically built for a lone customer. But, when an extension is built for a wider consumer audience, a multi-tenant installation is used and preferred. This involves multiple, different, customer environments pointing to a single code deployment.

Multi-tenant solutions do allow for easier installation, and better scalability controls. There are some development practices to consider while building the code:

  • Customer-specific values should either be moved to the database configurations, or some other method should be used to easily set these values from FI to FI.

  • Unique identifiers need to account for multiple Q2 environments. A customer ID or user ID is unique to a single Q2 environment.

Warning

If the extension does any caching of values, make sure that the values are not FI specific. If FI specific values should be cached, please make sure that the caching key include a value to identify the FI.

example:

  • Bad cache key for FI specific values: my_extension_cache

  • Good cache key for FI specific values: my_cextension_cache_{self.hq_credentials.aba}

This will prevent any unfortunate caching collisions.

To identify a repository as multi-tenant, set the MULTITENANT configuration value to True in the configuration/settings.py file. Setting this to true will also aid in development by changing some local environment logic to better match a multi-tenant experience. There is more information about this configuration value on the Configuration page in the documentation.