Flight Deck Standalone Deployment

Overview

Purpose
This document describes how to deploy Flight Deck Web as a standalone application using Docker Compose.

Scope
Covered: - Standalone deployment of Flight Deck Web - Required configuration via environment variables - Start, update, and basic verification procedures

Not covered: - nginx or reverse‑proxy configuration (customer-specific) - Network security zoning (DMZ, firewalls) - Integration into shared / multi-service Docker environments

Audience - Operations engineers (OPS) - System administrators - Technical support / TSQA

Prerequisites

Software requirements

Docker Engine installed on the host
Docker Compose version 2.35.1 or later
Verify with: docker compose version

Access requirements

Network access from the host to the customer environment backend endpoints
Permission to pull images from:
dockerregistry.quintessence.de

Configuration inputs

You must define the following placeholders before deployment:

FDW_TAG – Flightdeck image version tag
ENV_DNS – customer environment DNS name (hostname)
REALM – Keycloak realm name

Deployment

Deployment name and port convention

Application	Deployment Name	Port
midgard	flightdeck	8881
portal	portal	8882
kronos	kronos-flightdeck	8883
top-client	top-client-flightdeck	8884
eos	eos-flightdeck	8885

Docker Compose configuration

Create or adapt a docker-compose.yml file with the following service definition.

Customer Project Integration

Once the docker-compose.yml is created, it must be added to the appropriate customer project repository. Example for AIDA: aida-environment.

Synchronization

The configuration must be kept synchronized at all times.

Docker Image Selection

Depending on the Flight Deck type currently deployed alongside Midgard, Kronos, EOS, or Top-Client, a different Docker image must be used.

Available images: - flightdeck/quintessence-client-flightdeck-eos - flightdeck/quintessence-client-flightdeck-eosportal - flightdeck/quintessence-client-flightdeck-top-midgard - flightdeck/quintessence-client-flightdeck-top-client - flightdeck/quintessence-client-flightdeck-rescount-portal - flightdeck/quintessence-client-flightdeck-midgard - flightdeck/quintessence-client-flightdeck-kronos - flightdeck/quintessence-client-flightdeck-dayreturns - flightdeck/quintessence-client-flightdeck-basic - flightdeck/quintessence-client-flightdeck-asgard-portal - flightdeck/quintessence-client-flightdeck-asgard

Note: Host port selection is owned by OPS.
The example below exposes port 8080;
host port must follow local conventions;
change it as it is required by local policy (see Deployment Conventions).

services:
  flightdeck:
    container_name: fd
    image: dockerregistry.quintessence.de/flightdeck/quintessence-client-flightdeck-asgard:{{ FDW_TAG }}
    user: "1000:1000"
    ports:
      - "8080:8080"
    environment:
      - TZ=Europe/Berlin

      # Required configuration
      # Format: Display Name->https://<ENV_DNS>/<path>/->true
      - QC_FD_SERVER_LOCATIONS=Midgard EW Dev->https://{{ ENV_DNS }}/midgard-service-gateway/->true
      - QC_FD_SUB_SYSTEMS=https://{{ ENV_DNS }}/asgard
      - QC_FD_KEYCLOAK_URL=https://{{ ENV_DNS }}/auth/realms/{{ REALM }}/.well-known/openid-configuration

      # Optional; remove if not used
      - QC_FD_MAIN_MENU_GROUPS

    entrypoint: ["/usr/local/tomcat/bin/catalina.sh", "run"]
    restart: unless-stopped

Installation and Update Procedure

Initial deployment

docker compose pull
docker compose up -d

Updating Flight Deck

Update FDW_TAG to the desired version
Pull the new image:
```
docker compose pull
```
Restart the service:
```
docker compose up -d
```

Pre-Verification Configuration

Before verifying the Flight Deck deployment, the following configuration steps must be completed:

HTTPS Redirect Configuration

An HTTPS redirect for Flight Deck must be created in the bastion host by the Infrastructure team. This configuration will define the final URL for accessing Flight Deck.

Note: Contact the Infrastructure team to request the HTTPS redirect setup. The resulting URL will be required for the Keycloak configuration below.

Keycloak Valid Redirect URIs

The Flight Deck URL must be added to the Keycloak valid redirect URIs before users can authenticate:

Log in to the Keycloak Admin Console
Navigate to the appropriate realm
Select Clients and locate the Flight Deck client
In the Valid Redirect URIs field, add the Flight Deck URL (e.g., https://<FD_URL>/*)
Save the configuration

Verification

Container status

docker ps --filter name=fd
docker logs -n 200 fd

Application access

Open in browser: https://<FD_URL>/<DEPLOYMENT-NAME>
Ensure the URL is added to the valid redirect URIs in Keycloak (see Pre-Verification Configuration)
Verify login and backend connectivity

Note: The <DEPLOYMENT-NAME> refers to the application context path exposed by Flight Deck (for example flightdeck), not the Docker container or service name.

Monitoring & Maintenance

Monitor container logs via docker logs
Ensure backend endpoints remain reachable from the host
Review authentication errors after Keycloak or realm configuration changes

References & Links

Docker documentation: https://docs.docker.com/
Docker Compose v2: https://docs.docker.com/compose/
OpenID Connect discovery specification: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig

Change Log

Version	Date	Description	Author
1.0	2026-01-13	Initial standalone deployment	vgogilchyn

Changelog

Date	Author	Message
2026-03-10	Viktor Gogilchyn	QC-50171 Fixed link
2026-03-06	Viktor Gogilchyn	QC-50171 Clarified FD deployment document
2026-03-06	aresnikowa	qc-0: postediting
2026-02-25	aresnikowa	QC-50171: in Keycloak folder, adjusted admonitions