System Requirements

Hardware Requirements

The hardware requirements for Cafe Variome V4 depend on the expected load and usage patterns. Below are the minimum and recommended specifications for a basic setup. The minimum specifications assume no optional features are enabled, and a small number of users and datasets.

Component	Minimum Specification	Recommended Specification
CPU	1 core (2.0 GHz)	4 cores (2.5 GHz or higher)
RAM	2 GB	4 GB or more
Disk Space	20 GB	100 GB or more

Operating System

Cafe Variome V4 is developed and tested on Linux-based systems. We cannot guarantee compatibility with other operating systems. The following Linux distributions are recommended:

• Ubuntu 22.04 LTS or later
• Rocky Linux 9.5 or later
• Debian 11 or later

If you are using a different Linux distribution and encounter issues, please include details about your OS, installed packages, Python/Node.js versions, and any error messages when seeking support.

MacOS compatibility

The backend system contains several CFFI modules that are not compiled for MacOS. Therefore, on MacOS it falls back to pure Python implementations which are significantly slower and not suitable for production use.

Windows compatibility

The backend system uses CairoSVG for processing SVG files. This library relies on Cairo, which is troublesome to install on Windows. We cannot provide support for how to install Cairo on Windows, but it usually involves either using pre-compiled libraries like from GTK or building from source using tools like MSYS2.

Software Requirements

Cafe Variome V4 requires the following software components:

Database

The primary database for Cafe Variome V4 is used to store both application data and user data. The database support status is as follows:

Database	Status	Version
MongoDB	Supported	6.0 or later
MariaDB	Work in Progress	N/A
PostgreSQL	Work in Progress	N/A
Elasticsearch	On Roadmap	N/A

MongoDB is the primary supported database, which is designed into the system architecture. Other databases are supported via an abstraction layer, so they may experience performance or feature limitations.

On Linux, you can install MongoDB by downloading the packages from the official MongoDB website. They provide both packages and tarballs for various distributions. The community edition is free to use, subject to their license, and is usually sufficient for most use cases. For scaling and high availability, consider using MongoDB Atlas, their managed cloud database service, or a compatible service like Cosmos DB on Azure.

Cache / Message Broker

A cache or message broker is recommended for better performance and scalability, especially in multi-process deployments. The supported options are:

Cache / Broker	Status	Version
Redis	Supported	6.0 or later

Currently, there are no plans to support other cache or message broker systems. On Linux, you can install Redis by downloading the packages from the official Redis website.

Key Management Service (KMS)

A Key Management Service (KMS) is required for managing encryption keys and storing sensitive data securely. The supported options are:

KMS	Status	Version
Vault by HashiCorp	Supported	1.20 or later
Azure Key Vault	On Roadmap	N/A

Vault by HashiCorp is slightly more difficult to set up, so in this section we provide brief instructions to use it on Linux. For more detailed instructions, please refer to the official Vault documentation.

Assuming using Rocky Linux 9.5, and installing Vault 1.20 with binary release:

Install Vault on Rocky Linux 9.5

# Download and unzip the binary
wget https://releases.hashicorp.com/vault/1.20.0/vault_1.20.0_linux_amd64.zip
unzip vault_1.20.0_linux_amd64.zip
rm vault_1.20.0_linux_amd64.zip

# You should now have a `vault` binary and a license file
# This assumes a file backend. In production, consider using database backends like MySQL
cat >> vault.hcl << EOF
ui = true
storage "file" {
  path = "/somewhere/to/store/vault/data"
}
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}
EOF

# Run the vault server in the background
./vault server -config=vault.hcl &

# Connect to the vault server, initialize and unseal it
export VAULT_ADDR='http://127.0.0.1:8200'
vault operator init

# Repeat till you unseal the vault with enough keys
vault operator unseal

# Enable the engines
export VAULT_TOKEN='the-root-token-from-init'
vault secrets enable -path=secret kv-v2
vault secrets enable -path=transit transit
vault secrets enable -path=totp totp

# Create a policy for Cafe Variome
cat >> cafe-variome-policy.hcl << EOF
path "secret/data/cafe-variome" {
  capabilities = ["create", "update", "read", "delete", "list"]
}
path "secret/data/cafe-variome/*" {
  capabilities = ["create", "update", "read", "delete", "list"]
}
path "secret/metadata/cafe-variome" {
  capabilities = ["read", "list", "delete"]
}
path "secret/metadata/cafe-variome/*" {
  capabilities = ["read", "list", "delete"]
}
path "transit/*" {
  capabilities = ["create", "update", "read", "delete", "list"]
}
path "totp/*" {
  capabilities = ["create", "update", "read", "delete", "list"]
}
EOF

vault policy write cafe-variome cafe-variome-policy.hcl
rm cafe-variome-policy.hcl

# Create an approle for Cafe Variome
vault auth enable approle
vault write auth/approle/role/cafe-variome bind_secret_id=true secret_id_num_uses=0 secret_id_ttl=0 token_no_default_policy=false token_policies="cafe-variome"
vault read auth/approle/role/cafe-variome/role-id
vault write -f auth/approle/role/cafe-variome/secret-id

This should give you a role_id and secret_id which you can use to configure Cafe Variome to connect to Vault. The above is only a demonstration setup. In production, you should consider using TLS, a more robust storage backend, proper unsealing mechanisms, and secure handling of tokens and secrets (like using CI to inject the credentials and set the maximum use and TTL).

Vector Database

A vector database is recommended for enabling free text search and RAG (Retrieval Augmented Generation) for LLMs (Large Language Models). The supported options are:

Vector Database	Status	Version
qdrant	Supported	1.2 or later