Hello @Alex T⚜️ and @Andrey Yasko , thank you for clarifying.

To make it more concrete, I believe it would be extremely valuable for the community if UNA could publish a minimal “reference recipe” for a profesional scalable architecture for self hosted. Specifically, we are interested in what you would recommend as the starting point for a professional deployment that can later scale without requiring a complete re-architecture.

For example, what would you suggest as a baseline Docker Swarm/Kubernetes (or cluster) setup that includes:

• database isolation,
• cache (Redis or memcached),
• proxy / reverse proxy,
• media storage (separate from the main system),
• background workers / job server.

The idea is not necessarily to handle 500K concurrent users from the start, but to have a foundation that can grow towards that without major restructuring. A documented minimal but scalable stack would be very useful for startups adopting UNA in production.

Would you be able to share such a recommended “minimal scalable architecture” so we can all use it as a reference?

Additionally, it would be extremely helpful if the recipe could include concrete sizing and storage recommendations, for example:

• Recommended RAM / CPU per role (example roles: control/masters, app nodes, DB nodes, cache nodes, media/storage nodes, worker nodes). Please provide typical small/medium/large instance profiles or exact vCPU / RAM suggestions.
• Recommended disk type and filesystem for each role (e.g., NVMe SSD, provisioned IOPS SSD, filesystem type for SSDs). Include recommendations on RAID (software vs hardware) if applicable.
• Storage layout for media (storage folder) whether you local storage SAN or NAS and recommend S3-compatible object storage, MinIO, network filesystem, or dedicated block volumes, and how to place CDN in front of media.
• Recommended MariaDB/MySQL cluster configuration — which cluster variant do you recommend for UNA at scale (Galera, Group Replication, Vitess, Percona XtraDB Cluster, or managed DB service), and a sample of key configuration parameters (buffer pool sizing, innodb_io_capacity, connection limits, replication topology, backup settings, etc.).
• If possible, example deployment profiles production with resource sizing per profile.

Any concrete numbers, config snippets, or reference mysqld.cnf tuned for those profiles would be extremely valuable for operators who want to deploy UNA professionally and scale it later with minimal rework.

For example, a minimal reference recipe could look something like this (just as an illustration of the type of guidance we are hoping to see):

• Database cluster (MariaDB/MySQL with Galera):
• Minimum 3 instances for HA
• RAM/CPU per node: 16GB RAM, 8 vCPU
• Filesystem: XFS or ext4, SSD (NVMe if available), RAID 10 recommended
• Example mysqld.cnf tuned for InnoDB buffer pool, replication, and cache
• Storage cluster (for /storage media files):
• Minimum 3 nodes with NFS or object storage (e.g., MinIO, Ceph)
• Filesystem: ext4 or XFS, SSD
• RAM/CPU per node: 8GB RAM, 4 vCPU
• Application nodes (UNA containers):
• At least 2–3 nodes to start, behind a load balancer
• RAM/CPU: 8GB RAM, 4 vCPU per node
• RAID not required (stateless)
• Deployed on Kubernetes with persistent volumes only for configs and logs
• Cache cluster (Redis / Memcached / DragonflyDB):
• Minimum 3 nodes for HA
• RAM/CPU: 4–8GB RAM, 2–4 vCPU per node
• Filesystem: tmpfs or SSD, no RAID needed
• Proxy / reverse proxy layer:
• Nginx or Caddy, 2 instances behind a cloud load balancer
• RAM/CPU: 2–4GB RAM, 2 vCPU
• Cron worker / job server:
• 2 instances for task queues and scheduled jobs
• RAM/CPU: 4GB RAM, 2 vCPU

This way, even a startup deployment begins with a structure that can scale horizontally (adding nodes per role) without needing to completely re-architect later.

Thank you, sharing a community reference like this would help a lot of teams get UNA into production reliably. Also Thank you for NEO timeline clarification.