Dawiso Integration Runtime: security overview

Dawiso Integration Runtime (DIR) is an on-premises agent that scans metadata from customer systems and sends the result to Dawiso cloud. It is distributed as both a .NET 10 console application (Windows or Linux) and a Docker image, and is the alternative to Dawiso cloud connecting to the metadata source directly.

When DIR is necessary

DIR is the right choice when at least one of the following applies:

• The metadata source sits behind a firewall and inbound access from Dawiso cloud cannot be opened.
• Source credentials cannot leave the customer’s infrastructure under the customer’s security policy.
• The volume of metadata is large enough that local scanning improves performance over remote scanning from Dawiso cloud.

If none of these apply, the cloud-level connector is the simpler option — see the relevant connector documentation for the target metadata source.

Architecture and trust boundary

DIR runs entirely inside the customer’s infrastructure. The trust boundary between customer and Dawiso cloud is crossed only by outbound HTTPS calls that DIR initiates. Dawiso cloud never opens connections into the customer’s network.

flowchart LR
    subgraph Customer["Customer infrastructure"]
        DIR["Dawiso Integration Runtime<br/>(.NET 10 app or Docker image)"]
        Sources[("Metadata sources<br/>(databases, APIs, files)")]
        Storage[("Local storage<br/>(JSON, gzip)")]
        DIR -->|"Properties & credentials<br/>from local config"| Sources
        Sources -->|"Metadata"| DIR
        DIR --> Storage
    end

    subgraph Dawiso["Dawiso cloud"]
        API["Integration API"]
        Repo[("Metadata repository")]
        API --> Repo
    end

    DIR -->|"Gzipped metadata files<br/>over HTTPS (port 443)"| API

Component	Runs in	Operated by
DIR agent (.NET 10 application or Docker image)	Customer infrastructure	Customer
Local working folder & delta files	Customer infrastructure	Customer
Dawiso Integration API	Dawiso cloud	Dawiso
Metadata repository	Dawiso cloud	Dawiso

Data flow

The flow is one-directional and customer-initiated:

1. Extraction. DIR reads connection properties and credentials from its local configuration, connects to each configured metadata source, and extracts metadata.
2. Local staging. Extracted metadata is written to local JSON files compressed with gzip. The files remain on the customer’s host until step 3 completes. The customer can inspect the staged content before it leaves their network.
3. Upload. DIR sends the gzipped files to the Dawiso cloud Integration API over HTTPS on port 443. The connection is initiated by DIR; Dawiso cloud never calls back.
4. Ingestion. Dawiso cloud processes the received files and imports the metadata into the target Space and Application repository.

DIR exchanges metadata with the source, not the underlying data. Row values, document contents, and other payloads are never read or transmitted.

Network surface

Direction	Source	Destination	Protocol	Purpose
Outbound (customer-internal)	DIR	Each configured metadata source	Varies per source	Metadata extraction
Outbound (customer → Dawiso)	DIR	Dawiso cloud Integration API	HTTPS / port 443	Upload gzipped metadata
Inbound to DIR	—	—	—	None — DIR exposes no listening port

This profile lets a customer firewall DIR’s outbound traffic to a single Dawiso endpoint over HTTPS, and otherwise keep the DIR host fully isolated.

Credential handling

• Source credentials are stored in DIR’s local configuration on the customer’s host. They never leave the customer’s network and are never transmitted to Dawiso cloud.
• Source authentication uses whatever mechanism the metadata source requires (database accounts, API keys, certificates, etc.). DIR is the only system that needs to authenticate to the source.
• Credential rotation is the customer’s responsibility — rotate in the source system, update the DIR configuration, restart DIR.

Data at rest

DIR writes two kinds of local state on the customer’s host:

• Configuration files (DawisoIntegrationRuntime.*) — contain connection properties and credentials.
• Working folder — contains gzipped metadata JSON and delta state used to detect changes between runs.

Both live on a path the customer controls. Encryption at rest and backup of the working folder are the customer’s responsibility. The working folder must be preserved across DIR upgrades; deleting it forces a full reload on the next run.

Operational responsibilities

Concern	Owner
Hosting (VM, container, OS)	Customer
.NET 10 runtime (when running the console app) or container runtime (when running the Docker image)	Customer
Network access (to sources and to Dawiso cloud)	Customer
DIR configuration and credentials	Customer
Scheduling, monitoring, alerting	Customer
DIR upgrades	Customer (Dawiso publishes new builds)
Dawiso cloud Integration API	Dawiso
Metadata repository	Dawiso

Because DIR runs unattended on the customer side, the customer is responsible for treating it like any other production agent: log retention, alerting on failed runs, patch management for the host and .NET runtime, and access control to the configuration directory.