Linux Installation Guide for digna Release 2026.11¶

Release: 2026.11

Last Updated: November 7, 2026

Table of Contents¶

1. Introduction
2. System Requirements
3. Pre-Installation Setup
4. PostgreSQL Server Setup
5. Web Server Configuration
6. Initial Installation
7. Backend Configuration
8. Dashboard Configuration
9. Running digna as a systemd Service
10. 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 dignabackend and dignacli of 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.11¶

This release adds digna Data Reconciliation, digna Agentic with the digna MCP Server, and the digna Engine, which can profile data inside digna and check referential integrity between different database technologies. See the release notes for complete details.

For an installation, the release brings a new repository migration mechanism, an optional [duckdb] section in config.toml for the digna Engine, and a new license file. The upgrade section covers each of them.

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:

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:

Checking Your Distribution and Architecture¶

Several commands in this guide differ between the Debian and RHEL families. To check which you are on, run:

cat /etc/os-release
uname -m

• ID=ubuntu or ID=debian — use the apt commands.
• ID=rhel, rocky, almalinux or fedora — use the dnf commands.
• x86_64 or aarch64 — the architecture of the installation package you need.

Pre-Installation Setup¶

Before installing digna, ensure that two key prerequisites are in place:

1. PostgreSQL Server – for storing calculated metrics and performance data
2. 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:

sudo apt update

sudo dnf check-update

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¶

sudo apt install -y postgresql postgresql-contrib

sudo dnf install -y postgresql-server postgresql-contrib

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:

sudo postgresql-setup --initdb

Step 3: Start and Enable the Service¶

sudo systemctl enable --now postgresql

This starts PostgreSQL immediately and configures it to start again automatically at boot.

Step 4: Verify the Installation¶

psql --version
sudo systemctl status postgresql

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:

sudo -u postgres psql

Step 6: Confirm the Port¶

The default PostgreSQL port is 5432. To confirm the port your server is listening on:

sudo -u postgres psql -c "SHOW port;"

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:

sudo -u postgres psql -c "SHOW hba_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:

sudo systemctl reload postgresql

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:

listen_addresses = '*'

Then open the port in the firewall and restart the service:

sudo ufw allow 5432/tcp

sudo firewall-cmd --permanent --add-port=5432/tcp && sudo firewall-cmd --reload

sudo systemctl restart postgresql

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 .md MIME 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¶

sudo apt install -y nginx

sudo dnf install -y nginx

Starting nginx¶

sudo systemctl enable --now nginx

Verify the Installation¶

1. Open your browser
2. Navigate to http://localhost
3. You should see the nginx welcome page

Opening the Firewall¶

If the server is reached from other machines, allow HTTP traffic:

sudo ufw allow 'Nginx Full'

sudo firewall-cmd --permanent --add-service=http && sudo firewall-cmd --reload

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:

sudo nano /etc/nginx/conf.d/digna.conf

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;
    }
}

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:

sudo rm /etc/nginx/sites-enabled/default

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:

sudo nginx -t
sudo systemctl 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¶

sudo apt install -y apache2

sudo dnf install -y httpd

Starting Apache¶

sudo systemctl enable --now apache2

sudo systemctl enable --now httpd

Verify the Installation¶

1. Open your browser
2. Navigate to http://localhost
3. 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:

sudo a2enmod rewrite
sudo systemctl restart apache2

On the RHEL family, mod_rewrite is loaded by default. Confirm it:

httpd -M | grep rewrite

Required: Allow .htaccess Overrides¶

Open the configuration file for your document root:

sudo nano /etc/apache2/apache2.conf

sudo nano /etc/httpd/conf/httpd.conf

Locate the <Directory> block covering your document root (/var/www/html on both families) and change:

AllowOverride None

to:

AllowOverride All

Required: MIME Type for Markdown Files¶

In the same file, add the following line so that Markdown files are served correctly:

AddType text/markdown .md

Apply the Configuration¶

Check the configuration for syntax errors, then restart Apache:

sudo apachectl configtest
sudo systemctl restart apache2

sudo apachectl configtest
sudo systemctl restart httpd

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:

sudo -u postgres psql

Then paste the statements at the postgres=# prompt and type \q to exit.

Step 2: Extract the digna Installation Package¶

1. Locate the digna installation ZIP file provided to you
2. Extract it to your desired installation location — for example /opt/digna
3. After extraction, you should see the following items:
4. dashboard/ — Web dashboard interface
5. digna — Main executable (backend + CLI combined)

To extract from the shell:

sudo mkdir -p /opt/digna
sudo unzip digna-2026.11-linux-x86_64.zip -d /opt/digna

Make the Executable Runnable¶

Depending on how the archive was transferred, the executable bit may not survive extraction. Set it explicitly:

cd /opt/digna
sudo chmod +x digna

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

Step 3: Install the License File¶

1. Locate the license.toml file provided to you
2. Copy it into the root digna installation directory (where config.toml and the digna executable 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.

cd /opt/digna
sudo mv config_template.toml config.toml

Location: /opt/digna/config.toml

Open config.toml in a text editor and configure each section below.

[app] Section¶

This section configures cross-origin resource sharing (CORS) between the dashboard and the backend:

[app]
DIGNA_APP_CORS_ALLOW_ORIGINS = ["http://localhost:5173"]
DIGNA_APP_CORS_ALLOW_CREDENTIALS = true

[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!"
DIGNA_REPO_SSLMODE = "prefer"
DIGNA_REPO_NUM_CONNS = 16

sudo chown digna:digna /opt/digna/config.toml
sudo chmod 600 /opt/digna/config.toml

[base] Section¶

This section contains security, cookie and inspection settings:

[base]
DIGNA_FERNET_KEY = "DU4a0yJ-OqvbKCL4hNQn_CsknH-V1vWmHZqBUl-AY44="
DIGNA_COOKIE_DOMAIN = "localhost"
DIGNA_COOKIE_SECURE = false
DIGNA_COOKIE_HTTPONLY = true
DIGNA_TOKEN_EXPIRES_IN = 86400
DIGNA_MAX_WORKERS = 4
DIGNA_FRONTEND_BASEURL = "http://localhost/"
DIGNA_SOURCE_QUERY_TIMEOUT_SEC = 3600
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC = 30

[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.

[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='

[logging] Section¶

This section configures logging behavior:

[logging]
DIGNA_LOGGING_MODE = "INFO"
DIGNA_LOGGING_DIR = "logs"
DIGNA_LOGGING_MAX_FILES = 30

[duckdb] Section (Optional)¶

New in Release 2026.11. This section sets the resources of the digna Engine, which profiles data inside digna for database connections whose profiling location is digna Engine, and runs referential integrity checks between data sources on different database connections. See Profiling Location.

The section is optional. Without it, the defaults below apply.

[duckdb]
DIGNA_DUCKDB_MEMORY_LIMIT_MB = 1024
DIGNA_DUCKDB_TEMP_DIRECTORY = "/opt/digna/tmp"

sudo mkdir -p /opt/digna/tmp
sudo chown digna:digna /opt/digna/tmp

Step 2: Validate the Configuration¶

Before initializing the repository, check that config.toml is complete and well formed. In your digna installation directory, run:

./digna config check

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
 - Template overrides: OK
 - Unknown keys: OK

Overall: OK

Fix anything reported as FAILED and run the command again before continuing. A WARNING under Unknown keys lists keys in config.toml that digna does not read; they have no effect, so remove them or correct their spelling. See the CLI reference for the full list of options.

Step 3: Initialize the Repository¶

1. Open a terminal
2. Navigate to your digna installation directory (where config.toml and the digna executable are located)
3. Run the connection test:

cd /opt/digna
./digna repo check

On a new schema, the command connects and then reports that no repository is installed yet:

Error: No repo installed. Use the 'digna repo upgrade' command to install it.

At this point that is the expected result: it confirms that digna reaches PostgreSQL and the schema. A connection or authentication error instead points at the [repo] section or at the PostgreSQL setup.

sudo ln -s /opt/digna/digna /usr/local/bin/digna

Step 4: Install the Repository Schema¶

In the same directory, run:

./digna repo upgrade

This command installs the necessary tables in the repository schema and finishes with:

✅ Repo schema 'dignarepo' is up to date.

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:

./digna user add <email> <password> "<display_name>" --admin

Example:

./digna user add admin@example.com 'AdminPassword123!' "Admin User" --admin

This creates a user with email admin@example.com and full administrative privileges.

Step 6: Start the digna Server¶

In the digna installation directory, start the server with:

./digna serve --address <host> --port <port>

Parameters: - --address — Server hostname/IP (default 127.0.0.1) - --port — Server port (default 8000)

When the server is up, it prints the address it listens on:

Server running on http://127.0.0.1:8082

sudo ufw allow 8082/tcp

sudo firewall-cmd --permanent --add-port=8082/tcp && sudo firewall-cmd --reload

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.

1. Confirm the path
2. Open /etc/nginx/conf.d/digna.conf

3. Verify that root points at your extracted dashboard folder

4. Ensure the folder is readable

   sudo chmod -R a+rX /opt/digna/dashboard
   

5. Reload nginx

   sudo nginx -t
   sudo systemctl reload nginx
   

6. Test the Installation

7. Open your browser
8. Navigate to http://localhost (or your configured URL)
9. You should see the digna dashboard login page

Deploying to Apache httpd¶

1. Copy the Dashboard to the Document Root

   sudo cp -R /opt/digna/dashboard /var/www/html/digna
   

2. Add the Rewrite Rules

Create an .htaccess file inside the deployed folder so that dashboard routes survive a browser refresh:

sudo nano /var/www/html/digna/.htaccess

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]

1. Restart Apache

   sudo systemctl restart apache2
   

   sudo systemctl restart httpd
   

2. Access the Dashboard

3. Open your browser
4. Navigate to http://localhost/digna
5. 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:

getenforce

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

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 systemd
• uninstall_service.sh — Unregisters the service
• start_service.sh — Starts the registered service
• stop_service.sh — Stops the running service

Making the Scripts Executable¶

Extraction may not preserve the executable bit. Before first use:

cd /opt/digna/bin
sudo chmod +x *.sh

Installing the Service¶

1. Open a terminal

2. Navigate to the bin Folder

   cd /opt/digna/bin
   

3. Run the Installation Script

   sudo ./install_service.sh
   

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¶

1. Open a terminal
2. Navigate to /opt/digna/bin
3. Run:

   sudo ./start_service.sh
   

To Stop the Service¶

1. Open a terminal
2. Navigate to /opt/digna/bin
3. Run:

   sudo ./stop_service.sh
   

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:

systemctl is-enabled digna
systemctl is-active digna

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:

sudo journalctl -u digna -n 100

To follow the log live while reproducing a problem:

sudo journalctl -u digna -f

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:

1. Uninstall the Current Service

   cd /old/path/digna/bin
   sudo ./uninstall_service.sh
   

2. Move the Application Files

   sudo mv /old/path/digna /new/path/digna
   

3. Reinstall the Service

   cd /new/path/digna/bin
   sudo ./install_service.sh
   

4. Start the Service

   sudo ./start_service.sh
   

Uninstalling the Service¶

1. Stop the Running Service

   cd /opt/digna/bin
   sudo ./stop_service.sh
   

2. Uninstall the Service

   sudo ./uninstall_service.sh
   

The digna server is now unregistered from systemd.

Upgrading to a New Release¶

This section upgrades an installation of Release 2026.06 to Release 2026.11. If your installation is older, read Upgrading From a Release Before 2026.06 first.

Before You Upgrade¶

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:

pg_dump -h localhost -p 5432 -U digna_user -n dignarepo postgres > digna_repo_backup.sql

Requesting the License File for Release 2026.11

Release 2026.11 needs a new license.toml. Request it from the digna team before you start, and have it ready for Step 7.

Upgrading From a Release Before 2026.06¶

Release 2026.06 brought three changes that still apply when you upgrade an older installation straight to 2026.11:

• ODBC only. digna reaches every source technology over ODBC. Every database connection that does not use ODBC yet must be changed to ODBC after the upgrade; there is no automatic conversion. Install the ODBC drivers on the digna host beforehand, see Install the ODBC Driver on the digna Host, and have the properties of each connection ready from the technology guides. The Databricks Legacy connector no longer exists; move those connections to the Databricks connector.
• One executable. dignabackend and dignacli are replaced by the single digna executable, which combines the backend and the CLI.
• config.toml. The [encryption] section is required, and DIGNA_APP_HOST and DIGNA_APP_PORT are no longer read: the server takes its address and port from digna serve. Compare your file with Backend Configuration.

The steps below point out where an older installation needs something different. The repository upgrade in Step 8 brings a repository of any earlier release straight to 2026.11.

Upgrade Process¶

Step 1: Stop the digna Service¶

If digna is running as a systemd service, stop it first:

cd /opt/digna/bin
sudo ./stop_service.sh

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 executable and the dashboard folder of your current installation, so that the new release can be deployed alongside them:

cd /opt/digna
sudo mv digna digna_old
sudo mv dashboard dashboard_old

Keep digna_old until you have verified the upgrade, and dashboard_old until you have restored your configuration files from it (see Step 4). Afterwards you can delete both.

Step 3: Extract and Deploy New Version¶

1. Extract the new digna installation ZIP file
2. Copy the new digna executable and dashboard folder to your installation directory
3. Restore the executable bit and the ownership of the service account:

sudo chmod +x /opt/digna/digna
sudo chown -R digna:digna /opt/digna

Step 4: Restore Your Configuration Files¶

sudo cp dashboard_old/dashboard_config.toml dashboard/dashboard_config.toml

Release 2026.11 needs no change to config.toml: a file that works with Release 2026.06 keeps working. Two changes are optional:

• Add a [duckdb] section if database connections are to use the digna Engine and its defaults don't suit your host.
• Leave out the [app] section if a reverse proxy serves the dashboard and the backend under one origin.

[[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'

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 config.toml is complete before touching the repository:

./digna config check

Every section must report OK. Fix anything reported as FAILED, remove the keys listed under Unknown keys, and run the command again before continuing.

Step 7: Replace the License File¶

A license file normally carries over from one release to the next. Release 2026.11 is an exception: it adds two licensed modules, digna Data Reconciliation and digna Agentic, and a license issued before 2026.11 does not contain them. Copy the license.toml that the digna team provided for Release 2026.11 into the installation directory, replacing the old one:

sudo cp /path/to/new/license.toml /opt/digna/license.toml

./digna license check

Step 8: Upgrade the Repository Schema¶

In your digna installation directory, run:

cd /opt/digna
./digna repo upgrade

Release 2026.11 manages the repository schema with versioned migrations. The first upgrade from an earlier release brings the schema to the last version of the previous scheme, records that as its starting point, and then applies the migrations of Release 2026.11. It finishes with:

✅ Baseline migration recorded as applied.
✅ Repo schema 'dignarepo' is up to date.

All existing data is preserved. To see the state of the repository at any time, run ./digna repo check: it lists the latest applied migration and any pending ones.

Error: Legacy repo version 3.0.2 installed. Use the 'digna repo upgrade' command to upgrade it.

Step 9: Restart Services¶

If running as a systemd service:

cd /opt/digna/bin
sudo ./start_service.sh

If running manually, restart the server:

cd /opt/digna
./digna serve --address <address> --port <port>

If using nginx or Apache, reload the respective web server:

sudo systemctl reload nginx

sudo systemctl restart apache2

On the RHEL family, re-apply the SELinux labelling if the dashboard directory was replaced:

sudo restorecon -Rv /opt/digna/dashboard

Step 10: Verify the Upgrade¶

1. Confirm the release of the new executable:

   ./digna version
   

   The first line must read Release: 2026.11.

2. Access the digna dashboard and verify that the interface loads correctly.

3. Check the server logs for errors:

   sudo journalctl -u digna -n 100
   

4. Test your database connections — see Testing a Connection. After an upgrade from a release before 2026.06, change every connection that did not already use ODBC over to ODBC first.

To start with the new modules, see digna Data Reconciliation, Connect an AI Agent for the digna MCP Server, and Profiling Location for the digna Engine.