Simon, honestly, instead of paying for multiple KVM servers and creating extra points of failure, you’d be better off with a dedicated server at Hetzner.

Comparison:

2x Hostinger KVM 8 – €19.99/month (renews at €49.99/month)

• 8 vCPU
• 32 GB RAM
• 400 GB NVMe SSD
• 32 TB bandwidth

Hetzner Auction Dedicated (Budget option) – €41.29/month

• Intel Core i7-8700
• 2 × 1TB NVMe SSD
• 128 GB DDR4 RAM (4 × 32 GB)
• 1 Gbit Intel NIC unlimited bandwidth

Hetzner Auction Dedicated (Performance / Long-term option) – ~ €103.17/month

• Intel Core i9-9900K
• 2 × 1TB NVMe SSD
• 2 × 3.84TB SATA Datacenter SSDs (huge extra storage)
• 128 GB DDR4 RAM (4 × 32 GB)
• 1 Gbit Intel NIC unlimited bandwidth

👉 For nearly the same price as two KVM 8s, the i7 option gives you far more RAM and storage, with no need to daisy-chain servers.

👉 And if you want something more powerful and future-proof, the i9 option with nearly 9 TB of total SSD storage is still very reasonable at ~€103/month.

I also recommend enabling Hetzner’s backup service then you’ll be fully covered.

• https://www.hetzner.com/sb/#drives_size_from=1000&drives_size_to=22000&driveType=nvme
• https://www.hetzner.com/sb/#drives_size_from=2000&drives_size_to=22000&driveType=nvme&drives_count_from=4&ram_from=128&cpuType=Intel

Hetzner also provides an S3-compatible storage API you can use as a CDN. You can even create internal private networks between servers to scale later.

Honestly, I don’t see any reason to stay stuck with VPS when you’re past the beginner stage. VPS is fine for tuild cheap private cloud , or testing apps, but not for production. Spending time trying to daisy chain VPS instances for storage is, in my opinion, a mistake.

You can read all the documentation you want, but without real power your site will stay in the same place. If you want to grow profesional website, go to dedicated servers, an then plan ahead and build a private cloud, and you’ll be in a much stronger position. If you don't like Hetzner, there are other providers.

Without investment you can't have expectations. From my point of view, this topic is closed. Good luck

Absolutely amazing, What a great asset to una @Romulus

Also a simple setup for Permanent NFS Setup for UNA APP on Debian

NFS Server Setup

1. Install NFS server:

sudo apt update sudo apt install -y nfs-kernel-server 

1. Create shared storage folder:

sudo mkdir -p /mnt/storage sudo chown -R nobody:nogroup /mnt/storage sudo chmod 775 /mnt/storage 

1. Configure exports:

Edit /etc/exports:

/mnt/storage 10.0.0.0/24(rw,sync,no_subtree_check,all_squash,anonuid=33,anongid=33)

• 10.0.0.0/24 → your private network
• all_squash, anonuid=33, anongid=33 → maps all files to www-data (uid 33) for proper UNA APP permissions

1. Export the folder and start NFS:

sudo exportfs -a sudo systemctl enable nfs-server sudo systemctl restart nfs-server 

1. Optional firewall:

sudo ufw allow from 10.0.0.0/24 to any port nfs 

NFS Client Setup (UNA APP Server)

1. Install NFS client:

sudo apt update sudo apt install -y nfs-common 

1. Create mount point for UNA APP:

sudo mkdir -p /var/www/una/storage sudo chown www-data:www-data /var/www/una/storage sudo chmod 775 /var/www/una/storage 

1. Test manual mount:

sudo mount -t nfs <NFS_SERVER_IP>:/mnt/storage /var/www/una/storage 

Check:

df -h | grep storage 

Make NFS Mount Permanent

1. Edit /etc/fstab:

<NFS_SERVER_IP>:/mnt/storage /var/www/una/storage nfs defaults,_netdev,auto 0 0

• _netdev → ensures mount waits for network
• auto → mounts automatically on boot

1. Test fstab:

sudo mount -a 

No errors → mount will survive reboots.

Summary

• NFS storage mounted permanently at /var/www/una/storage
• Fully compatible with UNA APP
• Permissions mapped to www-data
• No other services included – simple, scalable, and persistent

💡 Recommendations for NFS Setup

1. Use a dedicated disk

• Always allocate a separate, empty disk for NFS storage.
• Avoid using the same disk as the operating system.
• This prevents I/O bottlenecks and ensures better performance.

1. Keep workloads separate

• Do not mount NFS on the OS disk.
• Mixing operating system and storage workloads will slow down the entire system.

1. Configure file descriptor limits

• NFS and applications like UNA may open thousands of files simultaneously.
• Increase nofile limits to avoid errors such as “Too many open files”.

1. Use a private network

• Isolate NFS traffic from public traffic (VLAN, VPN, or dedicated NIC).
• This prevents slowdowns for your users and improves security.

1. Plan for scalability

• NFS is suitable for temporary or small-scale setups.
• For long-term growth and higher performance, migrate to OpenStack Cinder or another distributed storage backend.

⚠️ Note:

NFS is a simple and functional solution for temporary storage or basic setups. However, it does not scale well with multiple volumes or high traffic. If you want a cloud-ready setup, NFS can be a starting point, but the recommended long-term approach is OpenStack with a dedicated storage backend for performance and scalability.

👉 In short: dedicate hardware for NFS, configure limits, isolate storage traffic, and use NFS as a stepping stone toward a scalable cloud infrastructure.

⚠️ IMPORTANT NOTICE

• 🚨 These commands and configuration changes are for informational purposes or development.
• 💾 They DO NOT represent an official setup guide.
• ⚙️ Run them ONLY if you fully understand what they do.
• ❗ Use at your own risk. Adjust if necessary.
• 👉 This example is intended for advanced users only.

✨ Happy coding!

https://www.youtube.com/watch?v=2dyWztiKECg

@Romulus I thank you for your input I really do and knowledge is king. So thank you, We do have trouble using some services due to the nature of out business " I will let you work that out" for this reason many services will not handle our content, we are big in the area we service and growing fast, I would really prefer a method of using a second server just to use the disk space if this is possible within the archtecture of simplicity. I know its not perfection in any way, I have studied your posts in detail and this would be great of course to impliment the Amazon s3 but I have spoken with them in person and they would not handle our content. We probably have around 14 days of space left, so it is paramount to find a solution . Just to give you the picture in brief we have 2 una sites and a range of other sites including TV & Radio an other servers. I do enjoy your posts they are always full of knowledge that I appreciate your time and effort. Simon

How much disk space, RAM, and CPU do you need in total?

You can set up a cloud-native infrastructure using OpenStack with Block Storage (Cinder) over NFS, deployed on dedicated servers, and scale out infinitely.

Since most cloud providers use OpenStack, building your own private cloud is the most cost-effective solution for long-term growth. To get started, you need at least three dedicated servers, though some services can run together or on cloud VMs depending on load and redundancy. This setup is ideal for hosting the UNA APP on one or more sites. Affordable dedicated servers from providers like Hetzner can be used to build such an infrastructure.

Minimal server setup for a functional OpenStack cluster

1. Controller node

• Services: Keystone, Glance, Neutron-server, Nova API, RabbitMQ, MariaDB, Cinder API
• CPU: 8–16 cores
• RAM: 32–64 GB
• Disk: 500 GB+ SSD
• Notes: Handles control plane and management services. Horizon (dashboard) and databases can optionally run on compute VMs.
• Servers required: 1 (can scale to 2–3 for HA)

2. Compute node

• Services: Nova compute, optionally Cinder-volume
• CPU: 16–32 cores
• RAM: 64–128 GB
• Disk: 1–2 TB SSD/NVMe
• Notes: Runs VMs; optional services like Horizon or lightweight databases can be hosted here.
• Servers required: 1–2 to start; more can be added to scale VM capacity

3. Storage / NFS node

• Services: Cinder backend, NFS
• CPU: 8–16 cores
• RAM: 32–64 GB
• Disk: Depends on block storage needs (high disk count, optionally RAID)
• Notes: Provides block storage volumes; can be combined with a compute node in small deployments, but dedicated storage servers are recommended.
• Servers required: 1 to start; more can be added as storage demand grows

Additional notes

• Trove (databases) can run on a dedicated DB server, controller, or compute VM depending on size and HA requirements.
• Minimal functional OpenStack requires at least 3 servers.
• For redundancy or high availability, additional nodes are recommended: extra controllers, extra compute nodes, and extra storage nodes.

OpenStack services and flexibility (open-source)

• Compute: Nova – creates and manages VMs; requires ≥1 compute node; scales horizontally.
• Block Storage: Cinder – creates virtual volumes attachable to instances; requires ≥1 storage server, can share with compute in small deployments.
• Databases: Trove – DBaaS; can run on controller, dedicated DB server, or compute VM.
• Dashboard / Management: Horizon – can run on controller or compute VM.
• Identity / Authentication: Keystone – must run on controller.
• Image service: Glance – runs on controller; can combine with other controller services.
• Networking: Neutron – runs on controller; minimal agents on compute nodes.
• Messaging & DB backend: RabbitMQ and MariaDB/MySQL – typically on controller; can be separated for performance.

Summary

• Minimum servers: 3 (1 controller, 1 compute, 1 storage)
• Flexible options: Horizon, Trove, and some databases can run on compute VMs or combined nodes.
• Scalability: Add more compute nodes for VMs, storage nodes for block storage, and controller nodes for HA.
• Scaling strategy: Start with horizontal scaling using multiple small servers for redundancy. Once you have 10–12 servers, vertical scaling (more CPU/RAM per node) can be considered.

Advantages of this setup

• Cost-effective: Dedicated servers for storage and compute reduce long-term expenses.
• Scalable: Easily add compute or storage nodes; you can create as many virtual disks, cloud servers, CDN , DB, or services as needed.
• Flexible: Horizon, Trove, and databases like MySQL, PostgreSQL, MongoDB can run on VMs, optimizing resource usage.
• Redundancy & High Availability: Extra nodes can be added to ensure HA.
• Cloud-native: Fully compatible with OpenStack, portable and compatible with most cloud providers.
• Optimized performance: Dedicated storage and compute nodes provide better I/O and CPU performance.
• Rich ecosystem: OpenStack offers a wide array of services; the best solution for an open-source private cloud.
• Future-proof: Start small and expand infrastructure as your UNA APP grows.

Estimated Monthly Cost per Server

• Controller Node: €37.30 – €42.00
• Compute Node: €37.30 – €42.00
• Storage / NFS Node: €37.30 – €42.00

Notes:

• Prices are based on Hetzner’s dedicated server offerings and may vary.
• Setup fees, additional storage, and extra bandwidth may increase costs.
• When scaling horizontally, each additional server will have a similar monthly cost.

More info: https://www.openstack.org/

If you need help, I can set up the infrastructure for you, including migration from your existing services. This can be done without downtime by running multiple versions of the UNA APP:

• Site replication: Replicate your existing sites in the private cloud, creating three instances for each site.
• Database replication: Set up a MySQL/MariaDB cluster for each site to replicate your existing databases and migrate them to the cloud.
• Reverse proxies: Replicate three Nginx reverse proxies for each current Nginx session.
• Caddy proxy: Deploy a Caddy proxy in front of all Nginx instances to ensure your sites remain online at all times.
• Database caching: Add a Memcached or DragonflyDB cluster to cache database queries and improve performance.
• HTTP request caching: Add a Redis instance using Valkey Fork (open-source) on Caddy to cache HTTP requests, reducing load and improving response times.

Note: The only data you might lose is cached memory in Memcached, if used, because we will set up Redis for web requests and DragonflyDB/Memcached for database caching. Some active sessions may be lost, and users will need to log in again.

Pricing and service details:

• Complete setup includes: OpenStack cluster deployment, UNA APP migration, site replication, MySQL/MariaDB clusters, Nginx and Caddy proxies, Redis (Valkey Fork), and Memcached/DragonflyDB caching.
• One-time fee: €1,500
• Includes: Configuration, testing, and migration with minimal or no downtime.
• Additional services: Extra sites, high-availability setups, or custom services can be quoted separately.
• Delivery: Service can be completed in 7 business days.
• Small private cloud: To set up three servers, you need to purchase this service three times: Coozila Small Business UNA CMS

Service Requirements

To be able to offer this service safely and without interruptions, you must migrate your domain name to Coozila Small Business:

👉 https://smallbusiness.coozila.com/

This step ensures full integration, better reliability, and seamless migration during setup.

If you feel confident doing it yourself, I wish you the best of luck!

Its looking at all options that are one workable without down time or limited and 2 cost effective .

I am running on Hostinger vps cloud servers . I run it with TMD before for 2 years on a dedicated server we just kep mounting more disks, It ran fine but was costing around 1400 dollars a month with the growth. and I have 2 una sites on seperate servers.

Well, there is already a CDN guide and a complete manual published by the UNA team:

1. https://unacms.com/wiki/global-settings#storage
2. https://github.com/unacms/UNA/wiki/Remote-Storage

I recommend keeping a copy on a local cloud storage server. Mount that folder on your UNA compute cloud server as /una/storage, and then integrate your CDN solution so that files are delivered from there onward.

Do not rely on the local storage folder directly on the UNA application server in production this can significantly slow down the system. That setup is only practical for testing, not for a live environment.

For production, you should ideally run at least three separate cloud servers: one for the UNA application, one for storage, and ideally a third one dedicated to databases. For testing purposes, however, it’s fine to run everything on a single server.

It’s not recommended to run UNA on a single VPS or even on a single dedicated server. In fact, running separate VPS instances for each application still introduces multiple points of failure.

Instead, you should rely on cloud infrastructure or dedicated server clusters. A proper production system should have at least three servers in a cluster in order to minimize failure risks and ensure redundancy.

Any production system without redundancy is destined to fail, it’s not a question of if, but when.

Guidance on Moving Media Files to CDN / External Storage @LeonidS @Andrey Yasko and the other unacms team members.

We are exploring options to move our media files (uploads, user content, assets) off the local VPS storage into a CDN-style or external storage solution. The goal is to reduce disk usage on our current KVM VPS instances while keeping performance and reliability high.

We’d appreciate guidance on the following points:

1. Recommended Approach:

• Should we consider object storage (S3-compatible services like MinIO, Backblaze, or AWS S3) integrated with UNA? (Could be a bit to late, but who knows)
• Is there native UNA support for external storage or CDN offloading for media files, or would this require custom development/plugins?

1. Integration Considerations:

• What is the best practice for serving media files externally while maintaining URLs, permissions, and access control?
• How do we handle existing media migration so that current uploads remain available without breaking existing links?

1. Performance / Caching:

• Do you recommend pairing the storage solution with a CDN for fast global access?
• Are there UNA configurations to automatically serve files via a CDN?

1. Minimal Downtime:

• We aim to move files with minimal disruption to the platform. Any advice on migration strategy that avoids downtime would be very helpful.

Our setup: multiple KVM8 VPS instances at Hostinger, with growing user uploads quickly consuming available storage.

We look forward to your suggestions and best practices for safely offloading media to a CDN or object storage backend.

Now, I know many of you will reply in conjunction with previous responses, but just to cover all angles and yes, let the response come from the architect themselves...

Thank you for your guidance and input..unacms team etc..