Skip to main content

Overview of On-Premises


This installation documentation is for the Styra DAS On-Premises release version: 0.5.5.

Styra Declarative Authorization Service (DAS) is composed of multiple microservices running on a Kubernetes cluster. Styra DAS has a single microservice responsible for receiving the incoming network requests called Gateway. A Gateway runs a single Kubernetes pod and receives the requests after they make their way past Kubernetes ingress. Now, the Gateway delegates its handling to the relevant microservice that is running on a Kubernetes pod.

This page describes how to obtain the Styra Docker images, DAS architecture, and responsibilities of the microservices involved, and how they fit together.


  1. Check if Docker is installed.

  2. Download the configuration files from the following URL:

  3. Once saved, extract the files to a local directory using tar xzf on-premises.tar.gz.

  4. Set up the credentials to pull the images for Styra's Docker registry.

Obtain the Microservice Images

Styra DAS microservices are packaged as Docker images. These images are distributed through a Docker registry hosted at You may configure your Kubernetes cluster to pull the images directly from Styra or you can download, re-tag, and push them to an internal Docker registry.

The registry at requires authentication.

  1. Generate a token.

The generated token should not have any path restrictions. Make sure the API token with path = ".*".

  1. Login to using the standard docker login command.

  2. Enter your credentials:

  • Username: <das-id>

  • Password: Use the token secret (previously generated)

For example:

> docker login
Username: <das-id>
Password: <paste token secret>

To use the images directly from, you will need to configure Kubernetes to use a private registry using those authentication credentials. Now, set the REPOSITORY_URL environment variable as follows for the rest of the Styra DAS installation.


(Optional) Push Styra Images to an Internal Registry

Once authenticated, use the following command to pull the Styra images to your local Docker registry.

export STYRA_SERVICES=(activity agentbundle agentloader agentstatus analysis-api coordinator datasources docs environment-configurator fetchdb gateway logreplay stacks sysinspector systems tenants timeseries ui)

docker pull$SERVICE:on-prem-0.5.5

Now, use the following instructions to re-tag images with your Docker registry hostname and push them to your registry:

1. First, log in to your registry.

export DOCKER_URL="my.registry.internal"
docker login $DOCKER_URL

2. Tag the Styra images.

docker tag$SERVICE:on-prem-0.5.5 $DOCKER_URL/styra/$SERVICE:on-prem-0.5.5

3. Push the Styra images to your internal registry.

docker push $DOCKER_URL/styra/$SERVICE:on-prem-0.5.5

Use the following instructions for the example Elasticsearch and Postgres deployments:

1. Pull the Elasticsearch and Postgres images.

docker pull
docker pull postgres:11.2

2. Tag the Elasticsearch and Postgres images with your internal registry.

docker tag $DOCKER_URL/elasticsearch:7.8.0
docker tag postgres:11.2 $DOCKER_URL/postgres:11.2

3. Push the Elasticsearch and Postgres images (if using the bundled Elasticsearch and Postgres).

for f in elasticsearch:7.8.0 postgres:11.2; do docker push $DOCKER_URL/$f; done

4. Set the REPOSITORY_URL environment variable with the repository URL. If your $DOCKER_URL does not contain "/" characters then REPOSITORY_URL can be set to $DOCKER_URL; otherwise REPOSITORY_URL will be defined with the / properly escaped.

export REPOSITORY_URL="my.registry.internal\/library"

You can also configure DAS to use AWS storage instead of Postgres.


The Styra DAS architecture splits the functionality across microservices that enables the Styra backend to scale individual components and adapt to varying workloads.

Figure 1 shows Styra microservices (in blue) that are made available by the Gateway API and how they relate to different entities talking to the DAS over the network using OPA and UI.

  • OPA: Supported system-types act as clients of the Styra DAS API. When you create and install a system, the gateway provides the API for the OPA to operate. It also provides the bundle API to OPA containers running on the cluster, and the APIs for the DAS to receive status updates and decisions from the OPAs. These interactions and APIs are designed based on the availability after OPA has successfully downloaded the initial bundle, it can continue serving authorization requests even if the Styra DAS becomes temporarily unavailable.

  • UI: All the UI interactions go through the gateway. The UI frontend downloads both its JavaScript through the gateway from the UI microservice. It also interacts with the other APIs through the gateway, inorder to implement and facilitate the actions users take on the UI. Internally, the DAS system relies on controllers (like environment-configurator) to converge the platform to a desired state. These interactions between the microservices don't require the involvement of the gateway.

Architecture of Styra DAS with Microservices

Figure 1: Architecture of Styra DAS with Microservices

The communication between microservices occurs over the following protocols:

  • External communication towards (for example: bundle downloads) Styra DAS occurs over HTTPS. However, the TLS is terminated with the Kubernetes ingress.

  • Service to service communication occurs over HTTP, with the exception of the coordinator that uses gRPC with the other services.

  • Communication with storage subsystems uses their preferred protocols as follows:

  1. Using PostgreSQL, the protocol is PostgreSQL.
  2. Using Elasticsearch communication occurs using HTTP.

Styra DAS Microservices

The following table lists the various Styra DAS microservices:

Table 1: Styra DAS Microservices

gatewayAPI gateway. All API requests are routed through gateway. It enforces authentication, authorization, and records user activity.
uiServes HTML and JavaScript for the GUI.
docsServes documentation.
timeseriesComputes metrics over decision log APIs.
systemsSystem configuration and management APIs, OPA configuration bundle APIs used for discovery.
stacksStack configuration and management APIs.
fetchdbJSON and Rego database management APIs and configuration management APIs.
logreplayAPIs to assess the impact of a policy change to previous decisions.
activityProvides user activity log APIs.
analysis-apiAPIs to search decision logs.
agentbundleConstructs and serves policy bundles.
agentstatusAPIs for OPAs to send status updates and decision logs.
agentloaderLoads decision logs from OPA to Elasticsearch for indexing.
environment-configuratorManages storage resources for the environment.
coordinatorShards work across service replicas.
datasourcesExecutes data sources that require pulling data.
tenantsConfigures and manages the tenant internal state.
elasticsearchSearch engine for decision logs.
storagePostgreSQL for all internal, persisted states.