Skip to main content

Overview of On-Premises

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 from Kubernetes ingress. The Gateway delegates its handling to the relevant microservice running on a Kubernetes pod.

This page describes how to obtain the Styra Docker images, Styra DAS architecture, and how microservices are integrated.

This installation documentation is for the Styra DAS On-premises release version: 0.9.0.


  1. Confirm Docker is installed.

  2. Download the configuration files using the following link: on-prem-assets.

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

  5. Export the environment variable ON_PREMISES_VERSION to ensure that the commands mentioned in this guide refer to the correct version.


Obtain the Microservice Images

Styra DAS microservices are packaged as Docker images. These images are distributed through a Docker registry hosted at 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. The API token requires path = ".*".

  2. Login to using the standard docker login command.

  3. 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" "agentstatusstore" "analysis-api" "blueprints" "coordinator" "datasources" "environment-configurator" "fetchdb" \
"gateway" "logreplay" "mock-opa" "policies" "stacks" "systems" "tenants" "timeseries" "ui")

docker pull$SERVICE:on-prem-${ON_PREMISES_VERSION}

Re-tag images with your Docker registry hostname and push them to your registry:

  1. Login to your registry.

    export DOCKER_URL="my.registry.internal"
    docker login $DOCKER_URL
  2. Tag the Styra images.

    for SERVICE in "${STYRA_SERVICES[@]}"
  3. Push the Styra images to your internal registry.

    for SERVICE in "${STYRA_SERVICES[@]}"
    docker push $DOCKER_URL/styra/$SERVICE:on-prem-${ON_PREMISES_VERSION}

The following instructions install Elasticsearch and Postgres deployments:

  1. Pull the Elasticsearch and Postgres images.

    docker pull
    docker pull postgres:14.5
  2. Tag the Elasticsearch and Postgres images with your internal registry.

    docker tag $DOCKER_URL/elasticsearch:7.17.5
    docker tag postgres:14.5 $DOCKER_URL/postgres:14.5
  3. Push the Elasticsearch and Postgres images (if using the bundled Elasticsearch and Postgres).

    for f in elasticsearch:7.17.5 postgres:14.5; 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"

Styra DAS can be configured to use AWS storage instead of Postgres.


The Styra DAS architecture splits the functionality across microservices which 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 Styra DAS over the network using OPA and the Styra DAS 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 Styra DAS 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.

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

Figure 1 - Architecture of Styra DAS with MicroservicesFigure 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:

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

Styra DAS Microservices

The following table lists the various Styra DAS microservices:

Table 1 - Styra DAS Microservices
blueprintsBlueprints, required to work with Mock OPA.
gatewayAPI gateway. All API requests are routed through gateway. It enforces authentication, authorization, and records user activity.
gateway-altOptional second API gateway.
uiServes HTML and JavaScript for the Styra DAS UI.
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.
fetchdbConfiguration management APIs.
logreplayAPIs to assess the impact of a policy change to previous decisions.
mock-opaThe Mock OPA service.
policiesAPIs for policy management.
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.
agentstatusstoreStorage for 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.