Setting up Qlik Data Gateway - Direct Access in a container

Last updated: 9/21/2026

This topic outlines the how to set up containerized Direct Access gateway. It provides prerequisites and installation instructions, and describes the limitations and considerations you should be aware of when working with containerized Direct Access gateway.

Supported from Direct Access gateway 1.8.0.

What is containerized Direct Access gateway?

You can deploy Direct Access gateway into a Docker container. This type of deployment is called containerized Direct Access gateway. Containerized Direct Access gateway deployments are supported for Linux, macOS, and Windows.

Containerized Direct Access gateway provides portability to your Direct Access gateway environment.

Best practices when using Qlik Data Gateway - Direct Access

For a successful experience when using Qlik Data Gateway - Direct Access, it is strongly recommended to adhere to the following best practices:

Do not use the same Direct Access gateway for development, user acceptance testing, and production, as this will increase the risk of overloading the available resources and impact system stability. From a business perspective, the combination of insufficient resources and decreased stability, might result in delayed updates to production application data.
For optimal performance, install the Direct Access gateway in an environment that is as close as possible to your data source.

System prerequisites

This section describes the requirements for using containerized Direct Access gateway.

Software requirements

Docker Engine version 20.9+ and the Docker Compose plugin (docker compose, v2 syntax) installed on the host.

Required ports and protocols

For required ports and protocols, see Required ports and protocols.

Recommended hardware

Host: 8 cores, 32 GB memory, 5 GB storage available to Docker

Optional: Set matching limits on the container in the compose file so the gateway has dedicated capacity rather than competing with other containers or processes on the host:

direct-access-agent:
    image: ...
    deploy:
      resources:
        limits:
          cpus: "6"
          memory: 24G
...
dcaas:
    image: ...
    deploy:
      resources:
        limits:
          cpus: "2"

Minimum hardware

The minimum hardware is only suitable for specific scenarios using smaller dedicated deployments (development, test, or production), with continuously low data volumes, and a limited number of concurrent reloads.

Host: 4 cores, 8 GB memory, 5 GB storage available to Docker

Optional: Set matching limits on the container in the compose file so the gateway has dedicated capacity rather than competing with other containers or processes on the host:

direct-access-agent:
    image: ...
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 4G
...
dcaas:
    image: ...
    deploy:
      resources:
        limits:
          cpus: "2"

Installing Qlik Data Gateway - Direct Access

Setting up the Direct Access gateway involves procedures that need to be performed both in the Administration activity center and on the Direct Access gateway server.

Data gateway procedures that need to be performed in the Administration activity center require tenant admin permission.

Stage one: Download Qlik Data Gateway - Direct Access

In the Administration activity center, select Data gateways.

Any existing data gateways will be listed in a table showing basic information about each gateway.
Click the Deploy toolbar button.

The Deploy Data Gateway dialog opens.
Select Data Gateway - Direct Access - Containerized Direct Access Gateway, accept the Qlik Customer Agreement, and click Download. The Direct Access gateway setup file (docker-compose.qlik-data-gateway-direct-access.yml) will be downloaded to your machine.

Stage two: Start the deployment by running the Docker Compose file

To start the deployment of the Direct Access gateway, run the following command:

docker compose -f docker-compose.qlik-data-gateway-direct-access.yml up

Stage three: Setting up Direct Access gateway

For detailed setup instructions, see Stage three: Set up Direct Access gateway.

Stage four: Register the data gateway

The next step is to register the data gateway. This can be done either through the Administration activity center or on the command line.

You can register the gateway using the Administration activity center. See Option 1: Via the Administration activity center.

You can also register Direct Access gateway automatically from the command line, without using the Administration activity center. This method uses a short-lived session token generated from an OAuth client.

Automatic registration is supported through the command line only. A REST API for automatic gateway registration is not currently available.

Prerequisites

An API key with tenant admin permission to create and manage OAuth clients.

Registering the gateway with automatic registration

First, you need to set up a Python environment to generate an OAuth client ID, as well as an assertion key (short-lived token) in the direct-access-agent container. Run the following commands separately, in this order:
1. docker exec -it --user root direct-access-agent-1 bash
2. apt-get update && apt-get install -y python3 python3-pip
3. apt install python3.11-venv
4. python3 -m venv .venv
5. source .venv/bin/activate
6. pip install cryptography pyjwt
7. python3 generate_gateway_assertion.py --tenant-url <tenant-url>
For the last command in the list above, follow the interactive prompts and copy the client_id (OAuth client ID) and assertion when provided. Store these details on paper or in a temporary text file for now—they are required for later steps in the process.
When you have written down the client_id and assertion, clean the Python environment with the following command:

deactivate
Set the OAuth client's consent method to trusted.

curl "https://<tenant-url>/api/v1/oauth-clients/<client-id>/connection-configs/me" -X PATCH -H 'accept: application/json' -H 'content-type: application/json' -H 'authorization: Bearer <api-key>' -d '[{"op":"replace","path":"/consentMethod","value":"trusted"}]'
Request an access token. This also triggers automatic creation of the bot user account used by the gateway.

curl "https://<tenant-url>/oauth/token" -X POST -H 'content-type: application/x-www-form-urlencoded' -d "grant_type=client_credentials" -d "client_id=<client-id>" -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" -d "client_assertion=<assertion>" -d "scope=admin.direct-access-gateways:register_gateway admin.direct-access-gateways:delete_gateway"

Information note
If the assertion has expired, re-run the script from the virtual environment.
Look up the auto-created bot user.

curl "https://<tenant-url>/api/v1/users" -H 'accept: application/json' -H 'authorization: Bearer <API-key>'
Copy the ID of my-bot-client.
Create a "DAG Registration" role.

curl "https://<tenant-url>/api/v1/roles" -X POST -H 'accept: application/json' -H 'content-type: application/json' -H 'authorization: Bearer <API-key>' -d '{"name":"DAG Registration","description":"Role for registering a gateway","assignedScopes":["admin.direct-access-gateways:register_gateway", "admin.direct-access-gateways:delete_gateway"]}'
Assign tenant-level roles to the bot user.

curl "https://<tenant-url>/api/v1/users/<bot-user-ID>" -X PATCH -H 'accept: application/json' -H 'content-type: application/json' -H 'authorization: Bearer <API-key>' -d ' [ { "op": "replace", "path": "/assignedRoles", "value": [ { "name": "DAG Registration" } ] } ]'
Get the Direct Access Gateway space.

curl "https://<tenant-url>/api/v1/spaces" -H 'authorization: Bearer <API-key>'
Copy the Direct Access Gateway space ID.
Add the bot user to the space with Can edit permission.

curl "https://<tenant-url>/api/v1/spaces/<DAG-space-ID>/assignments" -X POST -H 'accept: application/json' -H 'content-type: application/json' -H 'authorization: Bearer <API-key>' -d '{"assigneeId": "<bot-user-ID>","roles": ["consumer","dataconsumer","producer"], "type": "user"}'
In case the existing assertion has expired, generate a new one. Run the following command:

python3 generate_gateway_assertion.py --tenant-url <tenant-url>
Follow the needed steps in the command prompt. Since the OAuth client is already created, there is a need to update JWK using this API call:

curl "https://<tenant-url>/api/v1/oauth-clients/<client-ID>" -X PATCH -H 'accept: application/json' -H 'content-type: application/json' -H 'authorization: Bearer <API-key>' -d '[{"op":"replace","path":"/publicKeys/0/y","value":"<Y-value-from-JWK>"},{"op":"replace","path":"/publicKeys/0/x","value":"<X-value-from-JWK>"},{"op":"remove","path":"/publicKeys/0/use"},{"op":"replace","path":"/publicKeys/0/kid","value":"<kid-value-from-JWK>"}]'
Register the gateway:

dotnet ConnectorAgent.dll qcs register_gateway --tenant_url <tenant-url> --gateway_name <DAG-name> --gateway_description <DAG-description> --space_name <space-name> --client-id <client-ID> --assertion <assertion>

Removing an automatically registered gateway

Use the following steps to unregister a gateway that was registered using the automatic, session token-based method described above. These steps also remove the OAuth client, bot user, and role that were created for it.

Generate an assertion, as described in the section above.
Delete the gateway:

dotnet ConnectorAgent.dll qcs delete_gateway --tenant_url <tenant-url> --gateway_name <gateway-name> --client-id <client-ID> --assertion <assertion>
Look up the bot user account that was created for the gateway.

curl "https://<tenant-url>/api/v1/users" -H 'accept: application/json' -H 'authorization: Bearer <api-key>'
Copy the bot ID.
Delete this bot user account.

curl -X DELETE "https://<tenant-url>/api/v1/users/<bot-user-ID>" -H "Authorization: Bearer <api-key>"
Look up the “DAG Registration” role that was created for the gateway.

curl "https://<tenant-url>/api/v1/roles?limit=1&filter=(name%20eq%20%22DAG%20Registration%22)" -H "Authorization: Bearer <api-key>"
Copy the role ID.
Delete this role.

curl -X DELETE "https://<tenant-url>/api/v1/roles/<role-ID> -H "Authorization: Bearer <api-key>"
Delete the OAuth client.

curl -X DELETE https://<tenant-url>/api/v1/oauth-clients/<OAuth-client-ID> -H "qlik-confirm-delete: <OAuth-client-ID>" -H "Authorization: Bearer <api-key>

Stage five: Start the Qlik Data Gateway - Direct Access service on the Direct Access gateway server

To start the Qlik Data Gateway - Direct Access service, start the dcaas-dg and direct-access-agent containers.

Stage six: Add a connection to your data source

See Stage six: Add a connection to your data source.

Environment settings

This section lists specific environment variables from the docker-compose.qlik-data-gateway-direct-access.yml file which you might need to configure to properly connect your data sources via the gateway.

ALLOW_SOURCES: A comma-separated allowlist of hostnames and IPs. When the gateway agent needs to connect to something on your own server or another host in the local or private network (for example, a database on localhost, a Docker service name, or a private-IP host), you add that address to ALLOW_SOURCES — otherwise the connection attempt is refused.

Supported data sources

The following ODBC connectors are supported for containerized installations:
- PostgreSQL
- SQL Server
- Oracle
For more information about ODBC connectors, see ODBC databases ‒ Qlik Cloud.
REST connector (REST via Direct Access gateway). For more information about REST data sources, see REST sources ‒ Qlik Cloud.

Learn more

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!

Leave your feedback here