> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unoverse.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployment Options

There are three sizes. They scale the machine and the data stores, not the shape of the
system, so a small universe and a large one run the same images in the same arrangement.

Changing size is a variable, a re-apply, and a redeploy.

## The sizes

|            | **small**                          | **medium**                  | **large**                   |
| ---------- | ---------------------------------- | --------------------------- | --------------------------- |
| For        | Demos, POCs, development universes | First production            | High-traffic production     |
| VM         | 4 vCPU, 16 GB                      | 8 vCPU, 32 GB               | 8 vCPU, 64 GB               |
| Postgres   | Smallest managed tier              | Mid tier                    | Large tier, HA available    |
| Redis      | Single node, TLS                   | Single node, larger         | Single node, larger         |
| Backups    | 7 days, self-purging               | 14 days, restore tested     | 35 days, restore tested     |
| Log viewer | On, operator address only          | Off, ship to your own stack | Off, ship to your own stack |

Capacity, stated honestly. A small universe suits demos and small pilots, and its real
ceiling is usually the rate limits of the AI provider rather than the box. A medium
universe is sized for roughly 2,500 connected users and low hundreds of concurrent
executions. A large one is sized for roughly 10,000 connected users and one to two thousand
concurrent executions.

Treat those as planning figures. They are derived from comparable systems and adjusted for
a single engine instance, and they are not measurements of your workload.

## Why large is not simply a bigger machine

The engine is one Node process with one event loop. Cores beyond about eight sit idle as far
as it is concerned, and only serve the containers beside it. So the large tier spends its
budget on memory, on bigger data stores, and on giving **Spatial ML** its own machine when
embeddings grow.

**Large is the vertical ceiling.** Past it the answer is engine work, not a bigger box. That
work is session affinity across instances, and the connection budget in
[Data and State](/architecture/data) is its prerequisite.

## What is deliberately not offered

Being clear about this is worth more than a menu of tiers nobody has run.

**No multi-VM active/active.** A universe runs one engine instance today. Two would need
session affinity at the entry point and a session registry outside the process, and neither
exists yet. Documents that promised 20,000-user active/active tiers were describing a plan,
not a product, and they have been withdrawn.

**No Kubernetes or ECS today.** One VM with Docker Compose is the deployment, and a
customer's operations team can read it in an afternoon. A KVM image and a Kubernetes option
are coming soon, and both wait on the multiple-instance work above.

**No auth-off mode in a deployment.** `AUTH_ENABLED=false` exists for local testing, and it
injects a fixed identity carrying no roles and no permissions. The service refuses to start
if that flag is set while `NODE_ENV=production`. Letting anonymous visitors reach a workflow
is a per-workflow decision made on the trigger, not a property of the deployment.

**No pipeline at POC tier.** Provisioning is `terraform apply` and deployment is a CLI
command. Wiring those into CI is a decision a customer makes later, on their own terms.

## Where the platform can grow

Two seams exist for real, and they are worth knowing about because they answer most
"what if" questions in a review.

**The identity provider is a variable.** Auth0 today, Entra or Cognito tomorrow, without a
code change. See [Provisioning](/architecture/terraform).

**Postgres can be yours, on DigitalOcean.** An existing managed cluster, or a database
somewhere else entirely. **[AWS](/architecture/aws) always creates its own** and cannot be
pointed at a database you already run. See [Data and State](/architecture/data).

## Running it on your own hardware

Nothing about the platform requires a cloud. The images run on a VM you already own, and the
only things the cloud modules were providing are a TLS terminator, a Postgres, and a Redis.

You bring your own entry point, which is the one place an on-premises deployment differs. The
platform ships a requirement rather than a proxy: terminate TLS, forward to `:4105`, and
honour the settings in [Networking](/architecture/networking). Any of nginx, HAProxy or
F5 does the job, and because the authentication gate is in the application, none of them is
load bearing.

***

**Next**: [Provisioning with Terraform](/architecture/terraform)