Deployment Configuration

The Deployment Planning aims to provide in-depth details to RSTUF users to aid in the planning of a more customized deployment.

This document describes all aspects of deploying RSTUF independent of the environment and focuses on the technology stacks required by RSTUF services.

This document also complements the published deployment guides for Docker and Kubernetes with some detailed information.


Required Infrastructure Services

Repository Service for TUF API and Worker infrastructure services.

Message Queue/Broker: Redis or RabbitMQ server

RSTUF API and RSTUF Worker will use the message queue/broker.

RSTUF supports Redis or RabbitMQ server.

RSTUF uses Celery. For more details, see the summary about Celery and these two brokers.


Make sure the Redis or RabbitMQ uses a persistent storage.

RSTUF configuration


Both services, RSTUF API and Worker, must to access the same message queue/broker.


RSTUF API and Worker can use an existing Redis or RabbitMQ server in the host infrastructure. A specific Redis database id or specific RabbitMQ vhost is recommended.

Assign the Redis database id a complete address to the RSTUF_BROKER_SERVER configuration on

RSTUF API and Worker.

  • Example using Redis database id 5: RSTUF_BROKER_SERVER=redis://redis/5

  • Example using RabbitMQ vhost rstuf_vhost: RSTUF_BROKER_SERVER="amqp://guest:guest@rabbitmq:5672/rstuv_vhost"


RSTUF requires Redis server as a result backend.

Selecting Redis over RabbitMQ as the message queue/broker, reduces one technology stack.

Result Backend and RSTUF Settings: Redis server

RSTUF API and RSTUF Worker will use this Redis server as a backend result and to store RSTUF Settings.

Every request to RSTUF API is a unique task. The task result is stored in the backend result for 24 hours.


Be sure the Redis uses a persistent storage.

RSTUF configuration


Both services, RSTUF API and Worker, must access the same Redis.


When using Redis as a message queue/broker, the same

service/instance can be used as the result backend and RSTUF repository settings.

It is recommended to keep the broker, result backend, and RSTUF settings in different Redis database ids.

RSTUF provides optional settings in the container for it

As example, when setting up a deployment that will use Redis as a broker, result backend, and settings, the configuration for RSTUF API and Workers could use respective Redis database ids 5, 6, and 7.


Database: Postgres server

Only the RSTUF Worker uses the Postgres server

It uses the database to perform the TUF metadata management.


Make sure that Postgres uses persistent storage.

RSTUF configuration

[Optional] Content Server: Webserver

The content server is responsible for exposing the TUF metadata managed by the RSTUF Worker(s). This metadata will be used by TUF client implementations such as python-tuf, go-tuf, etc.

It is recommended to use a web server listing for all JSON files stored and managed by RSTUF Worker(s).



RSTUF Worker configuration

Key Vault Backend Service

The Key Vault Backend Service is responsible for storing the Online Key.


DO NOT EXPOSE THIS CONTENT. It must be restricted to the RSTUF Workers.

Storage Backend Service

The Storage Backend Service is responsible for storing TUF Metadata.


This content is the TUF Metadata and must to be exposed to TUF clients.

RSTUF best practices


Do not expose the HTTP REST API if it is not necessary

When integrating RSTUF into a specific content management or distribution platform, restrict the API access to the hosts where this integration is done.

If it becomes necessary to expose public RSTUF API, deploy RSTUF API containers with disabled administrative endpoints.



Use the Authentication/Authorization to restrict scopes

Use an API Gateway to manage API endpoints’ access.

RSTUF API has a built-in authentication service, however this feature is not for production. Using external authentication technology is recommended.


Use HTTPS on RSTUF API (SSL certificates).

RSTUF API supports SSL Certificates. Enabling and using trusted certificates is recommended.



Use secrets always for sensitive configurations.

RSTUF API supports using secrets in the container deployment for sensitive environment variables settings. See RSTUF API and RSTUF Worker Environment variables for more details.


It is possible to deploy multiple RSTUF API and Worker instances/replicas in a distributed environment to support multiple HTTP Requests and increase workloads for processing the TUF Metadata.