Add-ons
Add-ons are ready-to-use infrastructure pieces — databases, cache, authentication, connectivity, etc. — that you deploy inside an environment with just a few clicks, without needing to provision or configure the infrastructure manually.
1. Overview
The Add-ons screen is available inside an environment and has two tabs:
- Catalog — lists all add-ons available for deployment, with search by name/tag.
- My Add-ons — lists the add-ons already deployed in that environment, with access to manage each one.
At the top of the screen, two selectors define the context in which add-ons will be deployed:
| Selector | What it defines |
|---|---|
| Squad | The squad (team) that owns the deployed add-on |
| Environment | The environment (e.g. test, production) where the add-on will be deployed |
2. Add-on Catalog
Each card in the catalog shows:
- Name and version of the add-on (e.g. FusionAuth
v1.59.0). - Short description of what the add-on does.
- Tags that help identify the category (e.g.
Auth,Database,Cache). - Deploy button, which opens the deployment wizard.
Add-ons currently available:
| Add-on | Category | What it is |
|---|---|---|
| FusionAuth | Authentication | Authentication and authorization platform (SSO, MFA, OAuth2/OIDC) |
| PostgreSQL | Database | Advanced relational database |
| Cache (Valkey) | Cache | In-memory key/value store, open-source fork of Redis |
| Cloudflare ZTNA | Connectivity | Zero-trust tunnel via cloudflared to expose flows/apps/add-ons without opening ports |
3. Deploying an Add-on
Clicking Deploy on a catalog card opens a step-by-step wizard. The number and content of the steps vary from add-on to add-on, but follow a common pattern:
- General — the add-on name (a unique identifier within the environment, lowercase, with numbers and hyphens) and general settings specific to the add-on (e.g. enabling Elasticsearch, CORS, session timeout, panel visibility).
- Specific configuration — one or more steps with settings specific to that add-on (e.g. admin user, SMTP).
- Resources — the last step, always present: defines the infrastructure resources allocated to the add-on (memory and CPU) and, when applicable, to the database used internally by it (memory, CPU, and disk size). Each field shows the maximum allowed limit.
At the end, the Deploy Add-on button confirms the deployment. You can go Back to review previous steps, or Cancel to discard.
See the detailed step-by-step for each add-on:
4. Managing Deployed Add-ons
On the My Add-ons tab, each add-on deployed in that environment can be accessed for status checks, configuration, and, depending on the add-on, direct access to its admin panel.
5. FAQ
Who can deploy an add-on? TODO: confirm permission rule (squad, user role).
Can resources (memory/CPU) be changed after deployment? TODO: confirm whether there's post-deploy editing or whether the add-on must be recreated.
What happens to the data if I remove an add-on? TODO: confirm deletion behavior (data loss, backup, etc.).