> For the complete documentation index, see [llms.txt](https://docs.lightbeam.ai/lxqobxw6ak7CTnsQjikH/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lightbeam.ai/lxqobxw6ak7CTnsQjikH/getting-started/installer-guides/platform-specific/standalone-virtual-machine.md).

# Standalone Virtual Machine

Installer Guide for Standalone Virtual Machine

***

{% hint style="info" %}
**LightBeam Installation:**

Before proceeding with the steps in this guide, ensure you have gone through the [LightBeam Installation process](https://docs.lightbeam.ai/lxqobxw6ak7CTnsQjikH/installer-guides/lightbeam-installer). Familiarize yourself with the installation prerequisites and steps to ensure a smooth setup.
{% endhint %}

## LightBeam Pre-deployment Checklist 

#### Summary

* We will deploy a **three-node LightBeam Kubernetes v1.30.0 (or above)** cluster requiring *three* dedicated VMs to set up the cluster.
* Internet access is required on all nodes to download LightBeam docker images and to connect with datasources for scanning. 
* A default admin account for LightBeam will get created to access the LightBeam UI. For *multi-user* onboarding, **SMTP server** needs to be configured on LightBeam.
* The LightBeam UI can be accessed using **Master node IP** over http or https as desired. 

{% hint style="warning" %}
LightBeam requires AVX support on the CPU . Please refer to the compatible [processor](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX) details for more information.
{% endhint %}

#### Questions

<table data-header-hidden><thead><tr><th width="633"></th><th></th></tr></thead><tbody><tr><td>Which operating system are we planning to use for VMs? </td><td>Ubuntu</td></tr><tr><td><p>Are there any additional default policies that are already configured (or will get configured) for the Kubernetes services? </p><p></p><p>E.g. Are there any policies configured which stop services automatically? If yes, we will need to exclude it for the VMs of the cluster.</p></td><td><br></td></tr><tr><td><p>Is it possible to get a sub domain for LightBeam endpoint? Yes/No</p><p>Context: To configure LightBeam UI on a known domain. E.g. lightbeam.yourdomian.com</p></td><td>Yes</td></tr><tr><td>In case SMTP server needs to be configured, is the SMTP server reachable from the Kubernetes cluster (both VMs)? </td><td>No</td></tr></tbody></table>

***

## Overview&#x20;

We will set up a **three-worker-node Kubernetes cluster** for the LightBeam cluster deployment where one node will be set up as a **Master (control plane)** with scheduling *disabled* and three nodes as **Worker nodes**. All LightBeam cluster services will be deployed on **Worker nodes**. After the **Master** and **Worker** nodes are provisioned as a Kubernetes cluster, using `helm cli` we can deploy the LightBeam cluster.

<figure><img src="https://682442409-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0FnJiPbEPpkm5U4tiZUM%2Fuploads%2F1GMfXTVja327Xl7xAzIl%2Fimage%20(7).png?alt=media&amp;token=2cc6de1c-532b-4005-a0be-08d4492f6896" alt=""><figcaption><p>Master and Worker node components in a Kubernetes cluster</p></figcaption></figure>

***

### Resource Requirements

LightBeam deployment on Standalone VMs is certified on **Ubuntu OS**. The information below captures the OS version and the resource requirements for the Standalone VM deployments. We need **4 VMs, one as Master node (control plane) and three for Worker nodes. All VMs need to be within the same subnet.**

<table><thead><tr><th width="132.69759114583331"></th><th width="279.7685546875">Master node</th><th>Worker nodes</th></tr></thead><tbody><tr><td><strong>Count</strong></td><td>1 VM</td><td>3 VMs</td></tr><tr><td><strong>Compute</strong></td><td>4 vCPU, 8 GiB Memory</td><td>8 vCPU, 32 GiB Memory **</td></tr><tr><td><strong>Local</strong> <strong>Storage</strong></td><td>200GB on / with &#x3C; 5ms latency</td><td>50 GB / and 500GB on /var with &#x3C; 5ms latency</td></tr><tr><td><strong>OS Flavor</strong></td><td><a href="https://releases.ubuntu.com/24.04/ubuntu-24.04.3-live-server-amd64.iso">Ubuntu 24.04 LTS</a></td><td><a href="https://releases.ubuntu.com/24.04/ubuntu-24.04.3-live-server-amd64.iso">Ubuntu 24.04 LTS</a></td></tr><tr><td><strong>Network</strong></td><td>Static IP with 10Gbps b/w and internet access to install dependent packages</td><td>Static IP with 10Gbps b/w and internet Access to install dependent packages </td></tr><tr><td><strong>User Access</strong></td><td>sudo</td><td>sudo</td></tr><tr><td><strong>OVA</strong></td><td><a href="https://lightbeamai-my.sharepoint.com/:f:/g/personal/mehul_lightbeam_ai/EkZTlroMFNtHjfaXwv8KfyIBUBD9wJprhlgVXztW9vXVCQ?e=zbGcEM">OVA</a> (Master and Worker) </td><td></td></tr></tbody></table>

{% hint style="info" %}
Notes:&#x20;

* For performance configuration, the worker nodes can be sized with 24 vCPU and 64 GiB Memory.
* If deploying VMs in Microsoft Azure, use **VXLAN** as the encapsulation method for **Calico** networking, instead of IPIP, to ensure compatibility and better performance.
  {% endhint %}

***

### Packages Installed

* `Helm (Only on the master node)`
* `kubelet, kubeadm and kubectl`
* `docker-ce docker-ce-cli and containerd.io On Ubuntu`

***

### Setup

A Kubernetes cluster consists of two types of nodes: **master** and **worker** nodes.

The master node hosts the **Kubernetes control plane** and manages the cluster, including scheduling and scaling applications and maintaining the state of the cluster.

The worker nodes are responsible for running the containers and executing the workloads.

#### Master node

The master node hosts the **Kubernetes control plane** and manages the cluster, including scheduling and scaling applications and maintaining the state of the cluster.

The **master node** has several components, such as:

* **API server**: This is the main component that exposes the Kubernetes API and communicates with other components. It is the endpoint that the Kubernetes CLI (kubectl) and other clients talk to when creating or managing resources.
* **etcd**: This is a distributed key-value store that stores the cluster state and configuration data. It is the source of truth for the cluster.
* **Controller manager**: This runs multiple controller processes that watch for changes in the desired state of the cluster and take actions to make it happen. For example, it can create or delete pods, services, or endpoints.
* **Scheduler**: This assigns pods to worker nodes based on various criteria, such as resource requirements, labels, or affinity rules. It works with the API server to schedule the workloads on the cluster.
* **Cloud controller manager**: This runs controllers that are specific to the cloud provider and can manage resources outside of the cluster, such as nodes, load balancers, or routes. This component only runs if the cluster is running in the cloud.

To set up the control plane / master node, execute the script available here:

For Ubuntu:

<https://raw.githubusercontent.com/lightbeamai/lb-installer/master/Ubuntu/master.sh>

For RHEL:

<https://raw.githubusercontent.com/lightbeamai/lb-installer/master/RHEL/master.sh>

Once the above script is executed successfully run `kubectl` to get nodes command to check if the **Master node** is set up successfully. This command will show one node as ready.

#### Worker node

The worker nodes are responsible for running the containers and executing the workloads. The **worker node** has these components:

* **Kubelet**: This is an agent that runs on each worker node and communicates with the API server. It manages the containers and pods on the node, ensuring that they are running and healthy. It also reports the node status and resources to the master node.
* **Container runtime**: This is responsible for working with the containers and executing them. It can be Docker or another container runtime, such as containerd or cri-o. It uses the container runtime interface (CRI) to communicate with the kubelet.
* **Pods**: These are groups of one or more containers that share storage and network resources, and a specification for how to run them. Pods are the smallest units of a Kubernetes application. They can be created and managed by workload resources, such as deployments or statefulsets.
* **Kube-proxy**: This is a network proxy that runs on each worker node and enforces network rules on them. It helps Kubernetes in managing the connectivity among pods and services. It also acts as an egress-based load-balancing controller that monitors the Kubernetes API server and updates node’s iptables subsystem based on it.

To install all required packages on the worker node execute the script available here:

For Ubuntu:

<https://raw.githubusercontent.com/lightbeamai/lb-installer/master/Ubuntu/worker.sh>

For RHEL:

<https://raw.githubusercontent.com/lightbeamai/lb-installer/master/RHEL/worker.sh>

Once the **Master node** is ready, we need to get the `join` token using the command:

`kubeadm token create --print-join-command`

Copy the output of the above command and run it on the **Worker node**. Once the command is successfully completed, once again run the following command from the **Master node**:&#x20;

`kubectl get nodes`&#x20;

This command will now display *three nodes* as a Kubernetes cluster, with *one* serving as the **Master node** and the other *two* as **Worker nodes**.

In this scenario, just the **Worker node** will support all services.

***

## LightBeam Installation

1. Copy **`lightbeam.zip`** file shared by the LightBeam team on the **Master node VM.**
2. Follow the installation instructions in the [LightBeam Installer guide](/lxqobxw6ak7CTnsQjikH/getting-started/installer-guides/core/lightbeam-installation-and-upgrade.md#_w3t1uru6c4f9).
3. Use the `--self_managed` flag in the installer command to specify the platform used is a self-managed kubernetes cluster.

***

## About LightBeam

LightBeam automates Privacy, Security, and AI Governance, so businesses can accelerate their growth in new markets. Leveraging generative AI, LightBeam has rapidly gained customers’ trust by pioneering a unique *privacy-centric* and *automation-first* approach to security. Unlike siloed solutions, LightBeam ties together sensitive data cataloging, control, and compliance across structured and unstructured data applications providing 360-visibility, redaction, self-service DSRs, and automated ROPA reporting ensuring ultimate protection against ransomware and accidental exposures while meeting data privacy obligations efficiently. \
\
LightBeam is on a mission to create a secure privacy-first world helping customers automate compliance against a patchwork of existing and emerging regulations.

For any questions or suggestions, please get in touch with us at: <support@lightbeam.ai>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lightbeam.ai/lxqobxw6ak7CTnsQjikH/getting-started/installer-guides/platform-specific/standalone-virtual-machine.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.