Skip to content

macOS 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 Background 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 Linux?

This guide covers macOS. For other platforms, see the Windows Installation Guide or the Linux Installation Guide.


System Requirements

Before you begin the installation, ensure that your system meets the following minimum requirements:

Requirement Specification
Operating System macOS 13 (Ventura) or later
Architecture Apple Silicon (arm64) or Intel (x86_64)
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
Command Line Tools Xcode Command Line Tools (required by Homebrew)

digna Engine

Database connections that use the digna Engine as their profiling location are profiled on the digna host itself. Plan additional memory and disk space for them, see the [duckdb] section.

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 Architecture

Several paths in this guide differ between Apple Silicon and Intel Macs. To check which you have, open Terminal and run:

uname -m
  • arm64 — Apple Silicon. Homebrew installs to /opt/homebrew.
  • x86_64 — Intel. Homebrew installs to /usr/local.

Tip

Rather than hard-coding either path, this guide uses $(brew --prefix), which expands to the correct location on both architectures. You can copy the commands verbatim.


Pre-Installation Setup

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

  1. Homebrew – the package manager used to install the components below
  2. PostgreSQL Server – for storing calculated metrics and performance data
  3. Web Server – for hosting the digna Dashboard

If these components are not already set up, follow the sections below to install and configure them.

Installing Homebrew

Homebrew is the standard package manager for macOS and is used throughout this guide to install PostgreSQL and nginx.

Step 1: Check Whether Homebrew Is Already Installed

Open Terminal (press Cmd + Space, type Terminal, press Enter) and run:

brew --version

If a version number is returned, skip to the PostgreSQL Server Setup section.

Step 2: Install Homebrew

If the command was not found, install Homebrew by following the instructions on the official Homebrew site. The installer also installs the Xcode Command Line Tools if they are not already present.

Step 3: Add Homebrew to Your PATH

On Apple Silicon, the installer prints two commands to add Homebrew to your shell environment. Run them as instructed, then confirm:

brew --prefix

This should print /opt/homebrew on Apple Silicon or /usr/local on Intel.


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.

Installation Options

macOS offers two straightforward ways to install PostgreSQL. Choose one:

  • Homebrew — command-line installation, recommended for server deployments
  • Postgres.app — graphical installation, convenient for local evaluation

Installing PostgreSQL with Homebrew

Step 1: Install the PostgreSQL Formula

brew install postgresql@16

Step 2: Add PostgreSQL to Your PATH

Versioned PostgreSQL formulas are keg-only, which means Homebrew does not link their commands into your PATH automatically. Add them yourself:

echo 'export PATH="'$(brew --prefix)'/opt/postgresql@16/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Note

This assumes the default zsh shell used by macOS. If you use bash, append the same line to ~/.bash_profile instead.

Step 3: Start the PostgreSQL Service

brew services start postgresql@16

This starts PostgreSQL immediately and configures it to start again automatically when you log in.

Step 4: Verify the Installation

psql --version

You should see the PostgreSQL version if the installation was successful.

Step 5: Connect to the Server

psql postgres

Important — macOS Differs From Windows Here

The Windows installer prompts you to create a postgres superuser and password. Homebrew does not. Instead it creates a superuser named after your macOS account, with no password, reachable only from the local machine.

This means there is no postgres role on a fresh Homebrew installation. Use your own account name when you need a superuser, and create an explicit digna user as described in Initial Installation.

Step 6: Confirm the Port

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

psql postgres -c "SHOW port;"

Note the value — you will need it when configuring the digna backend.

Installing PostgreSQL with Postgres.app

If you prefer a graphical installation:

  1. Download Postgres.app and drag it into your Applications folder
  2. Open the app and click Initialize to create a new server
  3. Follow the app's instructions to add its command-line tools to your PATH
  4. Verify the installation:
psql --version

Postgres.app also creates a superuser named after your macOS account.


Web Server Configuration

digna requires a web server to host the dashboard. Choose one of the following options:

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

brew install nginx

Starting nginx

brew services start nginx

Verify the Installation

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

Note — Default Port Is 8080, Not 80

Homebrew configures nginx to listen on port 8080 so that it can run without administrator privileges. On macOS, binding to port 80 or any other port below 1024 requires root.

To serve the dashboard on port 80, change listen 8080; to listen 80; in the configuration below and start nginx with sudo brew services start nginx instead.

Configuring a Site for the Dashboard

Homebrew's nginx configuration includes every file in its servers directory. Create a dedicated configuration file for digna there:

nano $(brew --prefix)/etc/nginx/servers/digna.conf

Paste the following, replacing /path/to/digna/dashboard with the actual path to your extracted dashboard folder:

server {
    listen       8080;
    server_name  localhost;

    root   /path/to/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.

Apply the Configuration

Test the configuration for syntax errors, then reload nginx:

nginx -t
brew services restart nginx

Apache httpd Setup

Overview

macOS includes Apache httpd, so no installation is required. It is disabled by default.

Starting Apache

sudo apachectl start

Verify the Installation

  1. Open your browser
  2. Navigate to http://localhost
  3. You should see the message "It works!"

Required: Enable mod_rewrite

The dashboard requires URL rewriting. Open the Apache configuration:

sudo nano /etc/apache2/httpd.conf

Find the following line and remove the leading # to uncomment it:

LoadModule rewrite_module libexec/apache2/mod_rewrite.so

Required: Allow .htaccess Overrides

In the same file, locate the <Directory "/Library/WebServer/Documents"> block and change:

AllowOverride None

to:

AllowOverride All

Required: MIME Type for Markdown Files

Still in httpd.conf, add the following line so that Markdown files are served correctly:

AddType text/markdown .md

Important

Without this setting, .md files may not be served properly.

Apply the Configuration

Check the configuration for syntax errors, then restart Apache:

sudo apachectl configtest
sudo apachectl restart

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 Terminal in a single step:

psql postgres

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

  1. Locate the digna installation ZIP file provided to you
  2. Extract it to your desired installation location — for example /opt/digna or ~/digna
  3. After extraction, you should see the following items:
  4. dashboard/ — Web dashboard interface
  5. digna — 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 Terminal:

unzip digna-2026.11-macos.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
chmod +x digna

If macOS Blocks the Application

Files downloaded through a browser or mail client are tagged with a quarantine attribute. If macOS reports that the app "cannot be opened because the developer cannot be verified", clear the attribute from the installation directory:

xattr -dr com.apple.quarantine /opt/digna

Alternatively, open System Settings → Privacy & Security, find the blocked item near the bottom of the page, and click Open Anyway.

Note

This step is only needed if macOS actually blocks the executable. Packages transferred over SSH or from internal file shares are usually not quarantined.

Step 3: Install the License File

Important

The license file is not included in the installation package and will be provided separately by digna.

  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
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
Parameter Value Notes
DIGNA_APP_CORS_ALLOW_ORIGINS Dashboard URLs The URLs the dashboard is served from. Browser requests from any other origin are rejected
DIGNA_APP_CORS_ALLOW_CREDENTIALS true Required, so that the browser sends the session cookie with each request

Note

If you serve the dashboard from Homebrew's nginx on its default port, the origin to allow is http://localhost:8080.

The [app] section is optional

From Release 2026.11, both keys, and the whole [app] section, may be left out. This is the right setup when a reverse proxy serves the dashboard and the backend under one origin: the browser then makes no cross-origin requests, and none is allowed by default.

[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
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
DIGNA_REPO_SSLMODE prefer (default) Optional. PostgreSQL SSL mode: disable, allow, prefer, require, verify-ca or verify-full
DIGNA_REPO_NUM_CONNS 16 (default) Optional. Number of connections digna keeps open to the repository

[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
Parameter Value Notes
DIGNA_FERNET_KEY Value shown above Key of the encryption used by earlier releases. It must be present; keep the value shown
DIGNA_COOKIE_DOMAIN localhost Host the dashboard is reached under. "" sets no domain, which is right behind a proxy that serves the dashboard and the backend under one origin
DIGNA_COOKIE_SECURE false (HTTP) / true (HTTPS) Must be true whenever digna is served over HTTPS
DIGNA_COOKIE_HTTPONLY true Keeps the session cookie out of reach of scripts
DIGNA_TOKEN_EXPIRES_IN 86400 (24 hours) Session timeout in seconds
DIGNA_MAX_WORKERS Number of CPU cores - 1 Number of inspections that may run at the same time
DIGNA_FRONTEND_BASEURL Dashboard URL Required. Used for the links in notification messages, so it must be a URL the recipients can open
DIGNA_SOURCE_QUERY_TIMEOUT_SEC 3600 (default) Optional. Seconds a single query against a source database may run before it is aborted; 0 disables the timeout
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC 30 (default) Optional. Seconds to wait for a connection to a source database; 0 waits indefinitely

Tip

To find the number of CPU cores available on your Mac, run sysctl -n hw.ncpu.

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

[logging]
DIGNA_LOGGING_MODE = "INFO"
DIGNA_LOGGING_DIR = "logs"
DIGNA_LOGGING_MAX_FILES = 30
Parameter Value Notes
DIGNA_LOGGING_MODE INFO or DEBUG INFO for production, DEBUG for troubleshooting. TRACE, WARN and ERROR are accepted as well
DIGNA_LOGGING_DIR logs (default) Optional. Directory for the rotating log files, relative to the working directory
DIGNA_LOGGING_MAX_FILES 30 (default) Optional. Number of rotated log files to keep

[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"
Parameter Value Notes
DIGNA_DUCKDB_MEMORY_LIMIT_MB 1024 (default) Memory, in MB, that one digna Engine run may use. Up to DIGNA_MAX_WORKERS runs can be active at the same time
DIGNA_DUCKDB_TEMP_DIRECTORY Default: the system's temporary directory ($TMPDIR of the account that runs digna) Directory for temporary files when the data does not fit into memory

Sizing the digna Engine

Plan for up to DIGNA_MAX_WORKERS × DIGNA_DUCKDB_MEMORY_LIMIT_MB of memory on the digna host, on top of what digna itself uses, and for enough free disk space in the temporary directory to hold the largest inspected date of the data sources that use the digna Engine. Point DIGNA_DUCKDB_TEMP_DIRECTORY at a disk with that space, writable by the account that runs digna:

mkdir -p /opt/digna/tmp

You only need this section if at least one database connection uses the digna Engine, or a referential integrity check compares data sources on different connections.


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

Note

On macOS, commands in the current directory are not on your PATH, so the executable is invoked as ./digna rather than digna. To use the shorter form everywhere, add the installation directory to your PATH:

echo 'export PATH="/opt/digna:$PATH"' >> ~/.zshrc
source ~/.zshrc

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.

repo upgrade installs and upgrades

From Release 2026.11, repo upgrade installs a new repository and upgrades an existing one. repo install still works as another name for the same command.

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.

Tip

Wrap the password in single quotes. zsh treats 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:

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

Tip

The first time you start the server, macOS may ask whether you want the application to accept incoming network connections. Click Allow, otherwise the dashboard will not be able to reach the backend.

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

  1. Confirm the path
  2. Open $(brew --prefix)/etc/nginx/servers/digna.conf
  3. Verify that root points at your extracted dashboard folder

  4. Ensure the folder is readable

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

  5. Reload nginx

    nginx -t
    brew services restart nginx
    

  6. Test the Installation

  7. Open your browser
  8. Navigate to http://localhost:8080 (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 /Library/WebServer/Documents/digna
    

  2. Add the Rewrite Rules

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

sudo nano /Library/WebServer/Documents/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 apachectl restart
    

  2. Access the Dashboard

  3. Open your browser
  4. Navigate to http://localhost/digna
  5. You should see the digna dashboard login page

Running digna as a Background Service

Why Run digna as a Service?

Running the digna backend as a background 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 launchctl, macOS's 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 launchd
  • uninstall_service.sh — Unregisters the service
  • start_service.sh — Starts the registered service
  • stop_service.sh — Stops the running service

Administrator Required

All scripts must be executed with sudo, because registering a service that starts at boot writes to /Library/LaunchDaemons.

Making the Scripts Executable

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

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

Installing the Service

  1. Open 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 launchd 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 Terminal
  2. Navigate to /opt/digna/bin
  3. Run:
    sudo ./start_service.sh
    

To Stop the Service

  1. Open Terminal
  2. Navigate to /opt/digna/bin
  3. Run:
    sudo ./stop_service.sh
    

Tip

Always stop the service before updating application files.

Verifying the Service

To confirm that the service is registered and running:

sudo launchctl list | grep digna

A line beginning with a process ID indicates the service is running. A - in the first column means it is registered but stopped.

Moving the Service to a New Directory

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


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 Terminal:

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 background 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
mv digna digna_old
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.

Upgrading from a release before 2026.06

Rename the dignabackend and dignacli folders instead of the executable: mv dignabackend dignabackend_old and mv dignacli dignacli_old. Neither is used by Release 2026.11.

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, if necessary, clear the quarantine attribute:
chmod +x /opt/digna/digna
xattr -dr com.apple.quarantine /opt/digna

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

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.

Settings that digna does not read

Earlier versions of this guide showed some settings that digna does not read. They have no effect, and config check lists them under Unknown keys in Step 6. Remove or correct them:

  • DIGNA_SCHEDULER_MAX_DELAY, DIGNA_CLEANUP_TIME, digna_COOKIE_PATH, digna_COOKIE_SAME_SITE, digna_APP_CORS_ALLOW_METHODS, digna_APP_CORS_ALLOW_HEADERS and digna_LOGGING_BACKUP_COUNT don't exist. Remove them.
  • Setting names are case-sensitive. digna reads DIGNA_REPO_HOST, not digna_REPO_HOST. Write every name in upper case, as in Backend Configuration.

Single sign-on: keep [[oidc_clients]]

digna reads single sign-on providers as a list of [[oidc_clients]] entries, each with its own DIGNA_OIDC_KEY. If you changed your providers to [oidc_clients.<key>] sections, as an earlier version of this guide showed, change them back. config check reports OIDC config(s) as FAILED while that form is in place:

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

Repeat the entry for every provider, and keep each DIGNA_OIDC_KEY matching the key in dashboard_config.toml. 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 (Cmd+Shift+R).

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:

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

Do not keep the previous license

With the previous license, digna still starts, but digna Data Reconciliation and the digna MCP Server stay switched off. Every command that checks the license — user, inspection, repo — aborts before touching the repository when the check fails. Verify the new license before going further:

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

digna does not start on an outdated repository

From Release 2026.11, the server refuses to start while the repository needs an upgrade, and says so, for example:

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

Run repo upgrade before you start the server or the service.

Step 9: Restart Services

If running as a background 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, restart the respective web server:

brew services restart nginx
sudo apachectl restart

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 output and the files in the logs directory for errors.
  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.