Raynet One On-Premises Installation and Operations Guide

This guide provides a complete walkthrough for organizations choosing the on-premises deployment of Raynet One. It covers everything needed to get the system up and running securely and to operate it reliably in your own environment.

After successful deployment you will find practical instructions on how to:

•verify that everything works correctly,

•fix common issues,

•back up and restore data,

•monitor and observe the system.

The guide covers:

•Deployment of Raynet One using Docker Compose on a single host or supported Docker environment.

•Baseline configuration via .env for secrets, passwords, tokens, etc.

•Certificate options (self-signed vs. corporate PKI).

•Operational guidance including validation, troubleshooting, backup/restore, upgrades, and monitoring.

Intended Audience

This documentation is intended for:

•Infrastructure and platform administrators: deploying Raynet One on-premises.

•Internal delivery/ implementation teams: responsible for operating and supporting the deployment.

Coverage

This guide defines the deployment model for Raynet One on-premises.

Supported Docker environment:

•Architecture: Single-host deployment on a single server using Docker Compose.

•Orchestration: Docker Compose (≥ v2).

•Composition Scope: All components of the stack (Frontend, Backend, PostgreSQL, RabbitMQ, Vault, reverse proxy and other infrastructure services) must be defined in a single Docker Compose project.

Configuration & Security Concept (On-Premises)

Overview

This guide follows the principle of Separation of Concerns, Infrastructure is the blueprint; Environment is the instance. They must never merge.

•Infrastructure (docker-compose.yml): Declarative structure. Public.

•Environment (.env): Runtime configuration. Critical.

Configuration Mechanism

The deployment is based on two distinct file types. A clear understanding of their respective responsibilities is mandatory for secure and reliable operation.

Component	File	Responsibility	Security Level	Git Policy
Infrastructure	•docker-compose.yml	•service topology, networks, volumes, logic	•Public	•Commit
Environment	•.env	•FQDNs, API keys, passwords, Vault tokens	•Critical	•Forbidden

.env File Logic

The .env file defines environment-specific configuration values and serves as the authoritative input for Docker Compose at instantiation time. It does not replace Docker Compose; instead, it parameterizes the service definitions during Compose parsing. In short: Docker Compose defines what runs, while the .env file defines how it is specifically configured for your environment.

•Scope: One .env file per environment (e.g. for a department like.env.prod, env.test, env.dev).

•Activation: Can be automatically loaded when placed next to docker-compose.yml.

•Persistence: Any change to the .env file requires container recreation (docker compose up -d --force-recreate) to become effective.

Critical Security Warning:

In production, it is fundamentally important to externalize sensitive data (API keys, passwords, Vault tokens) and store them securely. Direct storage in the configuration or as simple environment variables poses a security risk.

For secure operation, you must use an external secret manager like HashiCorp Vault. Secrets are simple text files that are manually created on the host server and securely mounted into the container. The responsibility for implementing and operating this secure deployment method lies with the deploying organization.

Mandatory Security Requirements

The following requirements are non-negotiable in production environments to follow common security best practices:

•HTTPS/TLS mandatory (TLS 1.2 or higher).

•Trusted certificates only (self-signed only for testing).

•Complete certificate chain (root + intermediates).

•No plaintext secrets on disk.

•External secret management (e.g. HashiCorp Vault).