HomeGuidesAPI ReferenceChangelogDiscussions
Log In

Sizing

Suggest Edits

Sizing Guide for RegScale Infrastructure

RegScale is designed to support a variety of compliance use cases from ultra-small deployments (i.e. an auditor on a single laptop) up to tens of thousands of concurrent users for a large Corporation or government agency. As such, up-front planning is necessary to determine both the best installation approach as well as the size of the supporting infrastructure for hosting the application. This document will provide guidance to assist RegScale customers with appropriately sizing their IT infrastructure based on their use case.

Component Sizing based on Use Case

There are three major areas where sizing is important:

  • Web Server/Container
  • Database
  • Back-End Storage

In addition, there are several use cases that should be modeled to determine sizing:

  • Development, Testing, and/or Evaluation (1 - 50 users)
  • Small to Mid-Sized Production Deployment ( 50 - 500 users)
  • Large Scale Production Deployment (or Mid-Sized Production deployment with a large number of automated integrations)

Each of the trade-offs on sizing are described below by component and use case.

Web Server/Container Sizing

For a Development or Testing/Evaluation system, we recommend:

  • 2 CPU, 8 GB of RAM, and 10 GB of expandable storage
  • This could run on a laptop or a small Virtual Machine (VM)
  • Database can be SQL Server Express (free) and run on the same machine

For a Small to Mid-Sized Production Deployment, we recommend:

  • 4 CPU, 16 GB of RAM, and 10 GB of expandable storage
  • This should run on a mid-sized Virtual Machine (VM)
  • Database should be a licensed instance of SQL Server in a cloud database or existing SQL Server cluster (not on the same VM)

Large a Large Scale Production Deployment, we recommend:

  • Minimum of a 3 node Kubernetes cluster with 3 pods for high availability (ideally set for auto-scaling)
  • Database should be a licensed instance of SQL Server in a cloud database or existing SQL Server cluster (not on the same VM)
  • Storage should be expandable, backed up, and allow read-write many operations from the pods

Updated 5 months ago