📘
This page is partial
The deployment topologies, node roles, environment separation practice, version rule, hardening principles and upgrade posture set out below hold across releases. Two things are deliberately absent. There are no step-by-step installation instructions, because the published installation material describes the previous ledger implementation rather than the one that ships today. And the system requirement figures below are the published figures for that previous implementation, reproduced here because they are the only sourced figures that exist; they have not been confirmed for the current ledger. Treat them as indicative, and confirm sizing with Rayls before provisioning production infrastructure. Contact Rayls for installation support in the meantime.

Overview

Rayls Sovereign is designed to run inside the institution's own infrastructure, whether that is on-premise or in the institution's own cloud tenancy, on commodity hardware. Three deployment scenarios are supported, and they differ in operational commitment rather than in capability.

Scenario	Best for	Method
Local	Testing and development	Containers on a developer machine
Virtual machine	Small deployments and staging	Docker Compose or a service manager
Kubernetes	Production and scalable deployments	Standard Kubernetes workloads

The Rayls Sovereign ledger itself, together with the Relayer, the Cryptographic Trust Suite, the Gnark API and the Relayer state store, are all containerised and deploy as ordinary workloads with their datastores provisioned alongside. Nothing in the deployment model is unusual for an institution that already runs containerised infrastructure.

For component-level sizing across a whole Rayls estate, see System sizing in the Developer Reference. For high availability and disaster recovery, see Business continuity and disaster recovery.

System requirements

These are the requirements for the ledger itself. The supporting services are sized separately, and the sizing page covers them.

Resource	Minimum, for development and testing	Recommended, for production
CPU	2 vCPU	4 or more vCPU
RAM	4 GB	16 GB
Storage	100 GB SSD	500 GB high-performance SSD
Docker	20.10 or later	24.0 or later
Kubernetes, where used	1.20 or later	1.25 or later

These figures are the published requirements for the previous ledger implementation and have not been confirmed for the current one. Treat them as indicative, and confirm sizing with Rayls before provisioning production infrastructure.

Storage is the resource that grows, and it grows with transaction volume and with the retention policy the institution chooses, so it should be provisioned with headroom and monitored rather than sized once.

Node roles

A node in a Rayls Sovereign deployment runs in one of two roles.

A validator participates in consensus, holds a consensus key, and takes part in block production. An observer follows consensus and serves RPC without voting, which makes it the right role for read endpoints and for the integration surface an institution exposes to its own applications.

Separating the two is what allows an institution to scale its read and integration capacity by adding observers without touching the consensus set.

Environment separation

Each environment should have its own chain identifier. An institution running development, staging and production environments should assign a distinct identifier to each, so that a transaction constructed for one environment cannot be accepted by another. This is straightforward to get right at the point of setup and awkward to correct later.

All nodes participating in the same network have to run identical versions and identical genesis configuration.

The version rule

The components of a Rayls Sovereign deployment are released together and have to be at the same release version, or the deployment will not operate correctly.

The ledger versions on its own cadence, separately from the services, so a release is described by two version numbers rather than one. Confirm both against the release notes before installing, and upgrade the components together rather than one at a time.

Interfaces and hardening

The Rayls Sovereign ledger exposes the standard Ethereum JSON-RPC interface over HTTP and WebSocket, and standard Ethereum tooling connects to it without modification. Applications connecting to it need the chain identifier and the RPC endpoint, and the deployment supplies both.

For a production deployment, the guidance is as follows.

Restrict the enabled API modules. Expose only the modules that applications need. The debugging and tracing modules belong in development environments and should not be reachable from outside the deployment.
Restrict cross-origin and virtual host settings to the specific domains the institution's applications use, rather than leaving them permissive as they typically are in a development configuration.
Place the RPC endpoint behind a reverse proxy that terminates TLS and applies rate limiting.
Keep the node in a private network segment, with the key management service reached over a private endpoint rather than the public internet.
Enable archive retention where the deployment has an audit obligation, since pruned state cannot be reconstructed afterwards.

Upgrades

Component versions are bundled and upgraded together, which avoids the partial-version states that cause the hardest failures to diagnose. Before an upgrade, review the release notes for breaking changes, take a full snapshot of data and secrets, rehearse the upgrade in a staging environment, and agree the maintenance window.

Onchain, the contracts use an upgradeable proxy pattern, so contract logic can be upgraded while state is preserved. See Smart contracts in the Rayls Sovereign ledger.

Rollback is a restore from the pre-upgrade snapshot together with a revert to the previous component versions, which is why the snapshot is not optional.

Getting a deployment started

Rayls supports institutions through installation directly. To begin, contact Rayls.