Linux Installation Guide for digna Release 2026.06¶
Release: 2026.06
Last Updated: September 5, 2026
Table of Contents¶
- Introduction
- System Requirements
- Pre-Installation Setup
- PostgreSQL Server Setup
- Web Server Configuration
- Initial Installation
- Backend Configuration
- Dashboard Configuration
- Running digna as a systemd Service
- Upgrading to a New Release
Introduction¶
About digna¶
digna is a comprehensive AI-driven platform designed to optimize data quality management across various data environments such as warehouses, lakes, and lakehouses. Built to be highly scalable and adaptable, digna addresses modern data challenges through automation, real-time monitoring, and anomaly detection.
digna consists of two main components:
- digna: The core engine of the application, responsible for processing data and performing quality checks. It combines the backend and the command line interface in a single executable, replacing the separate
dignabackendanddignacliof earlier releases. - dignadashboard: A web-based interface hosted on a web server, providing a user-friendly way to interact with the digna platform and visualize data quality metrics.
What's New in Release 2026.06¶
This release brings data observability capabilities directly into your code, enabling developers to monitor data quality at the source. See the release notes for complete details.
Looking for Windows or macOS?¶
This guide covers Linux. For other platforms, see the Windows Installation Guide or the macOS Installation Guide.
Which Distribution Does This Guide Cover?¶
The instructions are written for the two most common server families. Where the two differ, both commands are given:
- Debian family — Debian, Ubuntu. Package manager:
apt. - RHEL family — Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, Fedora. Package manager:
dnf.
Any modern distribution with systemd will work; only the package names and a few configuration paths change.
System Requirements¶
Before you begin the installation, ensure that your system meets the following minimum requirements:
| Requirement | Specification |
|---|---|
| Operating System | Ubuntu 22.04 LTS or later, Debian 12 or later, RHEL 9 / Rocky 9 / AlmaLinux 9 or later |
| Architecture | x86_64 (amd64) or arm64 |
| Init System | systemd |
| Memory (Minimal Setup) | 16 GB RAM |
| Disk Space | 10 GB available storage |
| Database | PostgreSQL Server 12 or higher |
| Web Server | nginx, Apache httpd, or equivalent |
Database Installation Options¶
If PostgreSQL is already installed: You can add a new database for digna to your existing PostgreSQL Server.
If installing PostgreSQL on the same machine as digna:
Recommended Specifications
- Memory: 32 GB RAM (instead of 16 GB)
- Disk Space: 50 GB available storage (instead of 10 GB)
These higher specifications accommodate both digna and the PostgreSQL database running simultaneously.
Checking Your Distribution and Architecture¶
Several commands in this guide differ between the Debian and RHEL families. To check which you are on, run:
ID=ubuntuorID=debian— use theaptcommands.ID=rhel,rocky,almalinuxorfedora— use thednfcommands.x86_64oraarch64— the architecture of the installation package you need.
Pre-Installation Setup¶
Before installing digna, ensure that two key prerequisites are in place:
- PostgreSQL Server – for storing calculated metrics and performance data
- Web Server – for hosting the digna Dashboard
If these components are not already set up, follow the sections below to install and configure them.
Refreshing the Package Index¶
Update your package lists before installing anything:
Note
Throughout this guide, the first command in a pair is for the Debian family and the second for the RHEL family. Run only the one that matches your system.
PostgreSQL Server Setup¶
If You Already Have PostgreSQL¶
If PostgreSQL is already installed and running on your local machine or if you are using a managed remote PostgreSQL server, you can skip to the next section.
Installing PostgreSQL¶
Step 1: Install the Server Package¶
Tip
Distribution packages may lag behind the current PostgreSQL release. If you need a specific newer version, use the official PostgreSQL apt or yum repository instead.
Step 2: Initialize the Database Cluster¶
On the Debian family, the package creates and starts a cluster automatically — skip to the next step.
On the RHEL family, the cluster must be created explicitly:
Step 3: Start and Enable the Service¶
This starts PostgreSQL immediately and configures it to start again automatically at boot.
Step 4: Verify the Installation¶
You should see the PostgreSQL version and an active (running) service.
Step 5: Connect to the Server¶
A Linux PostgreSQL package creates a postgres system account that owns the cluster. Connect through it:
Note — Linux Differs From Windows Here
The Windows installer prompts you to set a password for the postgres superuser during setup. Linux packages do not. Instead, local connections are authenticated by peer authentication: the postgres operating-system user is allowed to connect as the postgres database user without a password.
This is why the command above uses sudo -u postgres. The digna backend connects over TCP with a username and password, so you will create an explicit digna user in Initial Installation.
Step 6: Confirm the Port¶
The default PostgreSQL port is 5432. To confirm the port your server is listening on:
Note the value — you will need it when configuring the digna backend.
Step 7: Enable Password Authentication for the digna User¶
digna connects to PostgreSQL over TCP as digna_user, which requires password authentication rather than peer authentication. Check that your pg_hba.conf permits it.
Locate the file:
Open it in an editor and confirm that the local TCP lines use scram-sha-256 (or md5 on older servers) rather than ident:
# TYPE DATABASE USER ADDRESS METHOD
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
Reload PostgreSQL after any change:
Important
If digna reports FATAL: Ident authentication failed for user "digna_user", this setting is the cause.
Step 8: If PostgreSQL Runs on Another Machine¶
To accept connections from a different host, set listen_addresses in postgresql.conf and add a matching host line for your network in pg_hba.conf:
Then open the port in the firewall and restart the service:
Web Server Configuration¶
digna requires a web server to host the dashboard. Choose one of the following options:
- nginx — lightweight and recommended
- Apache httpd — widely deployed alternative
You only need to install and configure one of these servers.
Both sections configure two things the dashboard depends on:
- A single-page-application fallback, so that refreshing a dashboard URL does not return a 404
- A
.mdMIME type, so that Markdown files are served correctly
nginx Setup¶
Overview¶
nginx is a lightweight, high-performance web server well suited to serving the static digna dashboard.
Installation¶
Starting nginx¶
Verify the Installation¶
- Open your browser
- Navigate to
http://localhost - You should see the nginx welcome page
Opening the Firewall¶
If the server is reached from other machines, allow HTTP traffic:
Configuring a Site for the Dashboard¶
nginx includes every file in its conf.d directory on both distribution families. Create a dedicated configuration file for digna there:
Paste the following, replacing /opt/digna/dashboard with the actual path to your extracted dashboard folder:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /opt/digna/dashboard;
index index.html;
# Serve Markdown files with the correct MIME type.
types {
text/markdown md;
}
# Single-page-application fallback: unknown paths return index.html
# instead of a 404, so dashboard routes survive a browser refresh.
location / {
try_files $uri $uri/ /index.html;
}
}
Important
Without the try_files directive, reloading any dashboard page other than the root URL returns a 404. This is the nginx equivalent of the URL Rewrite module required by IIS on Windows.
Disable the Default Site¶
Only one server block may be the default_server for a port. On the Debian family, remove the packaged default so it does not conflict:
On the RHEL family, comment out or delete the server { ... } block inside /etc/nginx/nginx.conf.
Apply the Configuration¶
Test the configuration for syntax errors, then reload nginx:
Apache httpd Setup¶
Overview¶
Apache httpd is available in the default repositories of every supported distribution. The package is named apache2 on the Debian family and httpd on the RHEL family.
Installation¶
Starting Apache¶
Verify the Installation¶
- Open your browser
- Navigate to
http://localhost - You should see the distribution's default Apache page
Required: Enable mod_rewrite¶
The dashboard requires URL rewriting.
On the Debian family, enable the module and restart:
On the RHEL family, mod_rewrite is loaded by default. Confirm it:
Required: Allow .htaccess Overrides¶
Open the configuration file for your document root:
Locate the <Directory> block covering your document root (/var/www/html on both families) and change:
to:
Required: MIME Type for Markdown Files¶
In the same file, add the following line so that Markdown files are served correctly:
Important
Without this setting, .md files may not be served properly.
Apply the Configuration¶
Check the configuration for syntax errors, then restart Apache:
Initial Installation¶
Step 1: Set Up the digna Repository¶
The digna repository stores all metrics calculated by digna. It acts as the central database for analytical and performance data.
Create Repository Schema and User¶
Open your PostgreSQL client (psql, pgAdmin, or similar) and execute the following SQL commands:
CREATE SCHEMA <digna_repo_schema>;
CREATE USER <digna_repo_user> WITH PASSWORD '<digna_repo_password>';
GRANT ALL PRIVILEGES ON SCHEMA <digna_repo_schema> TO <digna_repo_user>;
Replace the following placeholders:
<digna_repo_schema>— Your desired schema name (e.g.,dignarepo)<digna_repo_user>— Your desired username (e.g.,digna_user)<digna_repo_password>— A secure password for this user
Example:
CREATE SCHEMA dignarepo;
CREATE USER digna_user WITH PASSWORD 'YourSecurePassword123!';
GRANT ALL PRIVILEGES ON SCHEMA dignarepo TO digna_user;
To run these from the shell in a single step:
Then paste the statements at the postgres=# prompt and type \q to exit.
Best Practice
Use strong, complex passwords for database users. Avoid easily guessable credentials.
Step 2: Extract the digna Installation Package¶
- Locate the digna installation ZIP file provided to you
- Extract it to your desired installation location — for example
/opt/digna - After extraction, you should see the following items:
dashboard/— Web dashboard interfacedigna— Main executable (backend + CLI combined)
The configuration and licence files are not in the package
Neither config.toml nor dashboard/dashboard_config.toml ships with the installation — you create both yourself, in Backend Configuration and Dashboard Configuration. license.toml does not ship either; digna supplies it separately, as Step 3 describes.
To extract from the shell:
Note
If unzip is not installed, add it with sudo apt install -y unzip or sudo dnf install -y unzip.
Make the Executable Runnable¶
Depending on how the archive was transferred, the executable bit may not survive extraction. Set it explicitly:
Create a Service Account¶
Running the backend as a dedicated unprivileged user is recommended for production deployments:
sudo useradd --system --no-create-home --shell /usr/sbin/nologin digna
sudo chown -R digna:digna /opt/digna
Note
On the RHEL family the equivalent shell path is /sbin/nologin.
Step 3: Install the License File¶
Important
The license file is not included in the installation package and will be provided separately by digna.
- Locate the
license.tomlfile provided to you - Copy it into the root digna installation directory (where
config.tomland thedignaexecutable are located)
Why this matters: The license file contains your customer information, license expiration date, and digital signature. Do not modify this file — any changes will invalidate it.
Directory structure after setup:
/opt/digna/
├── config.toml (configuration file)
├── license.toml (YOUR LICENSE FILE - copy here)
├── digna (main executable)
├── bin/ (service management scripts)
└── dashboard/ (web interface)
└── (dashboard files)
Backend Configuration¶
Step 1: Create and Edit the Configuration File¶
The config_template.toml file is provided in your digna installation directory. You only need to rename it to config.toml.
Location: /opt/digna/config.toml
Open config.toml in a text editor and configure each section below.
[app] Section¶
This section configures the digna backend application settings:
[app]
digna_APP_CORS_ALLOW_ORIGINS = ["http://localhost:5173"]
digna_APP_CORS_ALLOW_CREDENTIALS = true
digna_APP_CORS_ALLOW_METHODS = ["*"]
digna_APP_CORS_ALLOW_HEADERS = ["*"]
| Parameter | Value | Notes |
|---|---|---|
digna_APP_CORS_ALLOW_ORIGINS | Frontend URL | If dashboard is on different server, include its URL |
digna_APP_CORS_ALLOW_CREDENTIALS | true | Required for CORS with credentials |
digna_APP_CORS_ALLOW_METHODS | ["*"] | Allow all HTTP methods |
digna_APP_CORS_ALLOW_HEADERS | ["*"] | Allow all headers |
Note
If you serve the dashboard from nginx or Apache on the default HTTP port, the origin to allow is http://localhost — or the server's public URL when the dashboard is reached from other machines.
[repo] Section¶
This section configures the connection to the PostgreSQL database:
[repo]
digna_REPO_HOST = "localhost"
digna_REPO_PORT = 5432
digna_REPO_DB = "postgres"
digna_REPO_SCHEMA = "dignarepo"
digna_REPO_USER = "digna_user"
digna_REPO_PASSWORD = "YourSecurePassword123!"
| Parameter | Value | Notes |
|---|---|---|
digna_REPO_HOST | localhost or IP | PostgreSQL server hostname/IP |
digna_REPO_PORT | 5432 (default) | PostgreSQL port |
digna_REPO_DB | postgres | Database name |
digna_REPO_SCHEMA | dignarepo | Schema created earlier |
digna_REPO_USER | digna_user | User created in PostgreSQL setup |
digna_REPO_PASSWORD | Your password | Password set during schema creation |
Best Practice
config.toml contains a database password in plain text. Restrict its permissions so that only the service account can read it:
[base] Section¶
This section contains security and cookie settings:
[base]
digna_COOKIE_DOMAIN = "localhost"
digna_COOKIE_PATH = "/"
digna_COOKIE_SECURE = false
digna_COOKIE_HTTPONLY = true
digna_COOKIE_SAME_SITE = "lax"
digna_TOKEN_EXPIRES_IN = 86400
digna_MAX_WORKERS = 4
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"
| Parameter | Value | Notes |
|---|---|---|
digna_COOKIE_DOMAIN | localhost | Match your frontend domain |
digna_COOKIE_SECURE | false (local) / true (production) | Use true for HTTPS connections |
digna_COOKIE_HTTPONLY | true | Always enabled for security |
digna_COOKIE_SAME_SITE | lax | Prevents CSRF attacks |
digna_TOKEN_EXPIRES_IN | 86400 (24 hours) | Session timeout in seconds |
digna_MAX_WORKERS | Number of CPU cores - 1 | Number of parallel inspection tasks |
DIGNA_SCHEDULER_MAX_DELAY | 100 | Maximum delay, in seconds, that the scheduler may add before starting a due job |
DIGNA_CLEANUP_TIME | "12:00" | Time of day (24-hour HH:MM) at which the daily cleanup run starts |
Tip
To find the number of CPU cores available on your server, run nproc.
[encryption] Section¶
This section holds the key used to encrypt sensitive values stored in the repository. It is required — config check reports the [encryption] section as FAILED if the key is missing.
| Parameter | Value | Notes |
|---|---|---|
DIGNA_ENCRYPTION_KEY | Base64-encoded key | Encrypts sensitive values stored in the digna repository |
Protect config.toml
This key is a fixed value, identical across all digna installations, and it is what decrypts the sensitive values in your repository. Restrict config.toml to the account that runs digna, keep it out of source control and off shared drives, and exclude it from any backup that is stored less securely than the repository itself.
[logging] Section¶
This section configures logging behavior:
| Parameter | Value | Notes |
|---|---|---|
digna_LOGGING_MODE | INFO or DEBUG | INFO for production, DEBUG for troubleshooting |
digna_LOGGING_BACKUP_COUNT | 10 | Number of daily log backups to retain |
Step 2: Validate the Configuration¶
Before initializing the repository, check that config.toml is complete and well formed. In your digna installation directory, run:
Every section is validated on its own, so a single mistake does not hide the state of the rest:
Configuration validation report (source: config.toml):
- App config: OK
- Repository config: OK
- Base config: OK
- Logging config: OK
- Encryption config: OK
- OIDC config(s): OK
Overall: OK
Fix anything reported as FAILED and run the command again before continuing. See the CLI reference for the full list of options.
Step 3: Initialize the Repository¶
- Open a terminal
- Navigate to your digna installation directory (where
config.tomland thedignaexecutable are located) - Run the connection test:
You should see a confirmation that the connection is established (the repository itself hasn't been initialized yet).
Note
On Linux, the current directory is not on your PATH, so the executable is invoked as ./digna rather than digna. To use the shorter form everywhere, add a symbolic link:
Step 4: Install the Repository Schema¶
In the same directory, run:
This command installs the necessary tables and schema in your PostgreSQL database.
Step 5: Create an Admin User¶
The admin user is created directly against the repository schema, so the server does not need to be running yet. In the digna installation directory, run:
Example:
This creates a user with email admin@example.com and full administrative privileges.
Tip
Wrap the password in single quotes. bash and zsh treat characters such as !, $ and * specially, and an unquoted password containing them will not be passed through as typed.
Best Practice
Use a strong password with a mix of uppercase, lowercase, numbers, and special characters.
Step 6: Start the digna Server¶
In the digna installation directory, start the server with:
Parameters: - --address — Server hostname/IP - --port — Server port
You should see startup messages confirming the server is running:
INFO: Started server process [1234]
INFO: Waiting for application startup.
INFO: Application startup complete
INFO: Uvicorn running on http://localhost:8082
Tip
If the dashboard is served from a different machine than the backend, open the API port in the firewall as well:
The server holds the terminal
serve runs in the foreground and keeps running until you stop it with Ctrl+C. Leave it running while you finish the setup, and see Running digna as a systemd Service to start it automatically at boot instead.
Dashboard Configuration¶
Step 1: Deploy Dashboard to Web Server¶
The digna dashboard reads its own configuration from dashboard/dashboard_config.toml. That file does not ship with the installation — you create it in the dashboard/ directory alongside the dashboard files.
Its contents are described under Single Sign-On, which is also where the file is needed: it carries the login options the dashboard offers and, for multi-instance deployments, the backend connection.
Choose your web server and follow the corresponding deployment steps.
Deploying to nginx¶
If you followed the nginx Setup section, the server block already points at your dashboard folder and no copying is required.
- Confirm the path
- Open
/etc/nginx/conf.d/digna.conf -
Verify that
rootpoints at your extracteddashboardfolder -
Ensure the folder is readable
-
Reload nginx
-
Test the Installation
- Open your browser
- Navigate to
http://localhost(or your configured URL) - You should see the digna dashboard login page
Deploying to Apache httpd¶
-
Copy the Dashboard to the Document Root
-
Add the Rewrite Rules
Create an .htaccess file inside the deployed folder so that dashboard routes survive a browser refresh:
Paste the following:
RewriteEngine On
RewriteBase /digna/
# Serve existing files and directories as-is.
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
# Everything else falls back to the single-page application entry point.
RewriteRule ^ index.html [L]
-
Restart Apache
-
Access the Dashboard
- Open your browser
- Navigate to
http://localhost/digna - You should see the digna dashboard login page
Step 2: SELinux (RHEL Family Only)¶
On RHEL, Rocky, AlmaLinux and Fedora, SELinux is enforcing by default and will block the web server from reading files outside its expected locations. Check whether it is active:
If the result is Enforcing and you are serving the dashboard from /opt/digna/dashboard, label the directory so the web server may read it:
sudo semanage fcontext -a -t httpd_sys_content_t "/opt/digna/dashboard(/.*)?"
sudo restorecon -Rv /opt/digna/dashboard
Note
If semanage is not found, install it with sudo dnf install -y policycoreutils-python-utils.
Important
A dashboard that returns 403 Forbidden on a freshly configured RHEL server is almost always an SELinux labelling problem rather than a file-permission one. Confirm with sudo ausearch -m avc -ts recent.
Running digna as a systemd Service¶
Why Run digna as a Service?¶
Running the digna backend as a systemd service ensures it:
- Starts automatically when the machine boots
- Runs in the background without an open terminal window
- Restarts automatically if it crashes
- Can be managed through
systemctl, the standard Linux service manager
Service Management Files¶
All necessary files are located in the digna installation directory under: bin/
The following shell scripts are available:
install_service.sh— Registers digna with systemduninstall_service.sh— Unregisters the servicestart_service.sh— Starts the registered servicestop_service.sh— Stops the running service
Root Privileges Required
All scripts must be executed with sudo, because registering a service that starts at boot writes a unit file to /etc/systemd/system.
Making the Scripts Executable¶
Extraction may not preserve the executable bit. Before first use:
Installing the Service¶
-
Open a terminal
-
Navigate to the bin Folder
-
Run the Installation Script
The digna server is now registered with systemd with automatic startup enabled. The service does not start immediately — see the next section to start it.
Starting and Stopping the Service¶
To Start the Service¶
- Open a terminal
- Navigate to
/opt/digna/bin - Run:
To Stop the Service¶
- Open a terminal
- Navigate to
/opt/digna/bin - Run:
Tip
Always stop the service before updating application files.
Managing the Service with systemctl¶
Once registered, the service can also be controlled with the standard systemd commands from any directory:
sudo systemctl start digna
sudo systemctl stop digna
sudo systemctl restart digna
sudo systemctl status digna
Verifying the Service¶
To confirm that the service is registered and running:
enabled means the service starts at boot; active means it is running now.
Viewing the Service Logs¶
systemd captures everything the backend writes to the console. To read it:
To follow the log live while reproducing a problem:
Tip
This is the fastest way to diagnose a service that starts and immediately stops. A repository connection failure or a missing license.toml is reported here.
Moving the Service to a New Directory¶
The unit file stores the absolute path to the executable, so relocating the installation requires re-registering the service:
-
Uninstall the Current Service
-
Move the Application Files
-
Reinstall the Service
-
Start the Service
Uninstalling the Service¶
-
Stop the Running Service
-
Uninstall the Service
The digna server is now unregistered from systemd.
Upgrading to a New Release¶
Before You Upgrade¶
Verify All Database Connections First
From Release 2026.06, digna reaches every source technology over ODBC. Earlier releases offered a choice between a per-technology driver and ODBC, selected with a Use ODBC switch. The digna team decided to build on ODBC alone, because a single, standard interface gives you more than a set of bespoke drivers can:
- Authentication — authentication is part of ODBC, so a connection can use whatever its driver supports: passwords, tokens and PATs, Kerberos and Active Directory, MFA and browser-based single sign-on, cloud identity, client certificates and TLS. New methods arrive with a driver update, rather than waiting for a digna release.
- Drivers maintained by the database vendors — the vendor's own driver tracks new server versions and security fixes, and you can update it on your own schedule, independently of digna.
- One way to configure everything — every technology is a list of key/value properties, with the same interface, the same encryption of sensitive values and the same troubleshooting, instead of a different set of fields per source.
- Tuning and reach — driver-level options such as timeouts, TLS settings, proxies and fetch sizes are available for every source, and any technology with a compliant ODBC driver can be connected, including ones digna does not publish a dedicated guide for.
In practice this means the Use ODBC switch and the separate host, port, database, user and password fields no longer exist. Every connection that does not already use ODBC must be changed to ODBC — there is no automatic conversion, so plan for this before you upgrade:
- Review every database connection defined in your installation and list the ones that are not yet using ODBC — each of these has to be reconfigured.
- Install the matching ODBC driver on the digna host — connections are opened from the server that runs the digna backend, not from the browser. See Install the ODBC Driver on the digna Host.
- Have the ODBC properties ready for each affected connection. The technology guides list a known-working property set per source.
After the upgrade, change each affected connection over to ODBC and test it from the dashboard — see Create a Database Connection and Testing a Connection.
Databricks Legacy connections
The Databricks Legacy connector has been removed in this release. Migrate those connections to the Databricks connector.
Creating a digna Repository Backup is Mandatory
Before upgrading digna, back up your repository (PostgreSQL) to protect against data loss. A backup ensures you can recover if the upgrade encounters unexpected issues.
To create a backup from the shell:
Upgrade Process¶
Step 1: Stop the digna Service¶
If digna is running as a systemd service, stop it first:
If digna is running in the foreground, press Ctrl + C in its terminal window.
Step 2: Backup Current Installation¶
In your digna installation directory, rename the folders of your current installation so that the new release can be deployed alongside them:
dignabackend and dignacli are no longer used
Starting with Release 2026.06, dignabackend and dignacli are replaced by the single digna executable, which combines the backend and the CLI. Keep dignabackend_old and dignacli_old only until you have verified the upgrade — afterwards you can delete both folders. Keep dashboard_old until you have restored your configuration files from it (see Step 4).
Step 3: Extract and Deploy New Version¶
- Extract the new digna installation ZIP file
- Copy the new
dignaexecutable anddashboardfolder to your installation directory - Restore the executable bit and the ownership of the service account:
Important
Neither config.toml nor dashboard/dashboard_config.toml is ever included in the installation ZIP — the digna team never ships either file. Your existing configuration is therefore untouched by the upgrade, and the copies in the renamed *_old folders are the only ones you have.
Step 4: Restore Your Configuration Files¶
Release 2026.06 changes config.toml
Three settings are new and required, and two are no longer used. A config.toml carried over from an earlier release does not contain the new settings, and digna will not start until they are present. Add the following to your existing config.toml:
[base]
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"
[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='
Add the two [base] keys to your existing [base] section, and add [encryption] as a new section. Then remove the two settings that are no longer used, digna_APP_HOST and digna_APP_PORT, from [app] — the server now takes its address and port from digna serve.
See Backend Configuration for what each setting does.
Single sign-on: the [oidc_clients] format has changed
Release 2026.06 replaces the array of tables with one table per provider, named after the provider key. DIGNA_OIDC_KEY is gone — the key is now part of the section header.
Before:
[[oidc_clients]]
DIGNA_OIDC_KEY = 'microsoft'
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'
After:
[oidc_clients.microsoft]
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'
Repeat the section for every provider, and keep each key matching the key in dashboard_config.toml. digna config check reports oidc_clients as FAILED while the old form is still in place. Only installations that use single sign-on are affected.
Step 5: Reload the Web Server¶
The dashboard is a set of static files, so your web server — and the browser — may still be serving the previous version. Reload or restart whichever web server hosts the dashboard folder, then reload the page with a hard refresh (Ctrl+F5).
Step 6: Validate the Configuration¶
Confirm that the updated config.toml is complete before touching the repository:
Every section must report OK. Fix anything reported as FAILED and run the command again before continuing.
Step 7: Replace the License File¶
Each release is licensed separately. Copy the license.toml that the digna team provided for this release into the installation directory, replacing the old one:
Do not keep the previous license
A license.toml issued for an earlier release does not cover this one, and every command that checks the license — user, inspection, repo — aborts before touching the repository when the check fails. Verify it before going further:
Step 8: Upgrade the Repository Schema¶
Navigate to your digna installation directory and run:
This updates the PostgreSQL schema to the latest version while preserving all existing data.
Step 9: Restart Services¶
If running as a systemd service:
If running manually, restart the server:
If using nginx or Apache, reload the respective web server:
On the RHEL family, re-apply the SELinux labelling if the dashboard directory was replaced:
Step 10: Verify the Upgrade¶
- Access the digna dashboard
- Verify that the interface loads correctly
- Check the server logs for any errors
- Change every connection that did not already use ODBC over to ODBC, then test all connections — see Testing a Connection: