Infrastructure and Hosting

1. Purpose

This document describes design principles for elyXion-controlled website, Portal, automation, and support infrastructure. It does not describe every Customer environment, which remains governed by its architecture and contract.

2. Architecture Status

Before publication, replace this section with an approved current-state diagram and verified provider list. Do not state a hosting provider or country based on an intended design alone.

3. Hosting Principles

elyXion aims to use reputable European or global cloud providers selected for security, resilience, contractual safeguards, and operational fit. Production and non-production environments should be separated according to risk.

4. Platform Design

Depending on the final implementation, the platform may use containerised workloads, managed databases, object storage, identity federation, reverse proxies, content delivery, monitoring, and automated deployment. Technology names describe components, not third-party endorsement.

5. Network Protection

Controls may include restricted inbound exposure, TLS, firewall rules, segmentation, rate limiting, DDoS protections, web application firewalling, and private management paths. Administrative interfaces should not be publicly exposed without strong protection.

6. Identity

Administrative access should use unique identities, multi-factor authentication, least privilege, and logged role assignment. Customer Portal users should authenticate through approved identity methods and role boundaries.

7. Deployment and Configuration

Infrastructure and application configuration should be version-controlled where practical. Material production changes require review, testing, approval, and rollback planning. Emergency changes are documented after implementation.

8. Secrets and Certificates

Secrets should be stored in approved secret-management systems, rotated according to risk, and excluded from source code and ordinary logs. Certificates should be monitored for expiry and use supported cryptography.

9. Data Stores

Data stores should use encryption, restricted network access, strong authentication, backup where required, and lifecycle rules. Customer Data should be separated logically, and dedicated architecture may be offered where contracted.

10. Backup and Recovery

Backup scope, frequency, retention, immutability, location, and restoration tests must be documented per component. A backup is not a guarantee of recovery. RPO and RTO commitments require explicit contract language and testing.

11. Monitoring

Infrastructure monitoring may cover availability, capacity, errors, certificates, backups, security signals, and unusual behaviour. On-call coverage and response are determined by the SLA.

12. Vulnerability and Patching

Supported base images, operating systems, dependencies, and services are reviewed for relevant vulnerabilities. Remediation is prioritised by exposure and risk. Provider-managed components depend on provider schedules.

13. Tenant and Data Separation

The Portal should enforce tenant-aware authorisation at every data-access layer, not only the interface. Privileged support access should be logged and restricted. Separation testing should form part of release assurance.

14. Development and Testing

Non-production should avoid production personal data. If representative data is needed, use synthetic, masked, or minimised datasets where practical. Developers should not receive production access by default.

15. Physical Security

Physical data-centre security is supplied by the hosting provider and evaluated through provider assurance. elyXion does not claim to operate its own data centre unless that changes.

16. Location and Providers

See the Data Residency Statement and Subprocessor List for verified locations and processing providers.