Digdash BI: deployment options¶
The Digdash BI template (category Visualization) exposes its options at deployment (form) and, for most of them, afterwards via Configure → Advanced — see Configuring an application for the general per-category tab mechanism.
General¶
| Field | Role |
|---|---|
| Digdash version | Tag of the bi/digdash-tomcat image. Defaults to the latest stable version of the chosen major release (<major>_latest) — a "bare" tag (e.g. 2026R1) stays frozen on that major's very first build and becomes stale quickly (license rejected in practice). |
| License key | Digdash key to use for this instance. |
| Memory limit, CPU limit | Resources for the main container (Tomcat/JVM). |
Authentication and environment¶
| Field | Role |
|---|---|
| DIGDASH_AUTH_TYPE | Authentication mode: OIDC (default) — platform SSO (Keycloak) plus LDAP directory — LDAP — LDAP directory only, sign-in with a DigDash username and password — or SAML2 — platform SSO over SAML 2.0: a SAML client is created in the platform Keycloak at deployment, and an external identity provider plugs in through relay authentication. SAML2 is chosen at creation: switching from OIDC or LDAP to SAML2, or from SAML2 to another mode, requires reinstalling the application. In every case DigDash users and roles are stored in the OpenLDAP directory of the dedicated sidecar, which is always deployed: DigDash cannot run without it, it is not an option. |
| File Browser | Enables an accessory file manager (upload/download), can be disabled if unused. |
| JVM CATALINA_OPTS, DIGDASH_SYSTEM, DIGDASH_PROPERTIES | Advanced settings (raw JVM flags, Digdash system properties, Digdash.properties) — one setting per line, # to comment out. Reserved for cases with no dedicated field elsewhere in this form. |
Debug mode¶
A toggle reserved for the DigDash team (Environments tab, at the top of the list), available only on this template — see the dedicated page Debug mode (Digdash BI) (enabling, JDWP/LDAP ports, temporary external exposure).
Database¶
| Field | Role |
|---|---|
| Database type (Environments tab, at the top of the list) | cnpg (managed PostgreSQL, default) or an already-existing external engine. Fixed at creation: switching engines requires a reinstall. |
Backup and restore¶
A toggle enables continuous WAL archiving and a scheduled backup (S3, cnpg engine only); restoring happens when creating a new application, from another one's backup — the shared mechanics and fields are detailed in Backup and restore. Digdash BI-specific fields: separate WAL/data compression (gzip/bzip2/snappy), the scheduled backup's owner reference, and an immediate backup at creation.
Environment backup¶
Independently of the database, the DigDash environment itself — users, roles, dashboards, data models, data sources and LDAP directory — is backed up to an S3 bucket with the official backuptools tool: see Environment backup.
Superadmin profile¶
The DigDash superadmin profile, given to the admin account and to whoever deploys the instance, receives every role of the instance, with read, write and execute rights. A role created later in DigDash is added to it automatically:
- right after deployment;
- by the schedulable task Give the DigDash superadmin profile every role of its instance (Settings → Scheduled tasks), for instance every hour;
- on demand, with the card's "Give the DigDash superadmin profile every role of the instance" button (admin role), for instance right after creating a role.
The API compatibility test checks that the superadmin profile does hold every role, as well as the API calls used to give them to it.
Volumes¶
In the Capacity tab, alongside memory and CPU: sizes for the appdata (application data) and openldap (directory of the OpenLDAP sidecar, always present) volumes, plus attaching an already-orphaned existing volume to each. Fixed at creation: resizing or swapping a volume afterwards is done from the Volumes tab, not this form.
Custom CA certificates¶
For an instance that needs to trust an internal certificate authority (e.g. a third-party HTTPS service with a corporate certificate): enables mounting an additional set of CAs into the container's truststore, either as filename: PEM entries (YAML) or from an already-existing Kubernetes Secret.
OpenID¶
SSO_LOGOUT (Environments tab, at the end of the list): redirect URL after logout — defaults to the platform's own, only adjust for a custom logout flow.