Skip to main content
This chapter defines the platforms and component versions Aletyx supports for the current release of Decision Control Tower. The compatibility matrix reflects what is tested and supported by Aletyx; running on a configuration outside this matrix is technically possible in many cases but not covered by support agreements.

​
Container runtimes

The container image is built and published as a multi-architecture manifest via Container Buildx and signed with cosign. All architectures supported by Buildx are covered (linux/amd64, linux/arm64, linux/arm/v7, etc.); the container runtime selects the variant matching the host transparently. Validate the cosign signature before promoting an image into a production registry.

​
Orchestration platforms

Single-node evaluation deployments via Container / Podman are also supported (see chapter 3) but are not recommended for production use.

​
Java runtime

The application is built and tested against:

​
Database engines

In production, the Tower and Sidecar databases must be separate. Sharing a database is not supported and would conflict on Flyway migration history.

​
Identity providers

Both providers must support OpenID Connect Authorization Code Flow with PKCE optional, the standard set of scopes (openid, profile, email), and a configurable claim path for user roles.

​
Reverse proxy / ingress controllers

The application has no requirements on the reverse proxy beyond:
  • Forwarding Host, X-Forwarded-Proto, and X-Forwarded-For headers
  • Terminating TLS upstream (the application speaks plaintext HTTP to the proxy)
  • Permitting WebSocket upgrades (used by select diagnostic endpoints)

​
Browser support (end-user)

​
Network requirements

Outbound connectivity from the Tower pod / container: Inbound connectivity to the Tower pod:

​
Compatibility matrix at a glance

​
Out-of-scope configurations

Configurations explicitly not supported for production use:
  • Sharing a database between Tower and the Sidecar.
  • Running Tower as root inside the container, or with privilege-escalation enabled.
  • Cross-tenant deployments where a single Tower instance serves multiple Entra tenants.
  • Tower without a sidecar (some workflow features will silently no-op).

​
Versioning and release cadence

  • Patch releases: bug fixes and security patches. Backwards-compatible with the previous patch’s configuration. No database migrations beyond what the corresponding minor release shipped.
  • Minor releases: may introduce additional configuration variables. Existing configuration remains valid; new variables either have safe defaults or fail-fast at startup with a clear log message.
  • Database migrations: forward-only via Flyway. Downgrade requires restoring a database backup taken before the upgrade.
Customers under support receive release notes detailing exactly which environment variables are added, deprecated, or whose default has changed in any given release.

​
Where to verify the matrix for your release

Each released image carries the deployment guide that applies to it under /docs/deployment in the package. If you are reading this guide outside the image, confirm the version at the top of README.md matches the version of the image you intend to deploy.