# Deployment Alternatives

Pick a deployment path based on your scale, availability, and workflow needs. Kubernetes targets high availability and higher scale. The sandbox VM targets a single-machine, all-in-one setup. Local test deployment targets fast runner development without provisioning a full environment.

### Summary: the 3 supported alternatives

#### 1) Kubernetes Deployment (higher scale & high availability)

Use this when you need multi-node scalability, workload isolation, and high availability patterns. This is the typical approach for shared environments and production-grade operations.

* **Best for:** higher-scale production, HA requirements, shared staging/dev
* **What you get:** initial core platform install, then self-service module installs via admin UI
* **Automation options:** fully automated or step-by-step
* **Typical duration:** \~30–60 min (fully automated) or \~2–3 hours (step-by-step), depending on customizations

Continue here: [Kubernetes Deployment](/installation/deployment-alternatives/kubernetes-deployment.md)

{% hint style="info" %}
Both Kubernetes and the sandbox VM are supported paths. Choose Kubernetes when you need HA/higher scale, and choose the sandbox VM when you want a single-VM environment with everything bundled.
{% endhint %}

#### 2) Sandbox VM Deployment (single VM, Docker Compose)

Use this when you want an all-in-one environment on a single VM. It spins up services via Docker Compose.

* **Best for:** evaluation, training, dev/test, small environments
* **Minimum VM size:** 4 vCPU, 16 GB RAM
* **Included components (typical):** Admin UI, controller/runner services, MongoDB, Kafka, Elasticsearch (profiles can disable parts)
* **Config surface:** mostly environment variables in `composite/.env`

Continue here: [Sandbox VM Deployment](/installation/deployment-alternatives/sandbox-vm-deployment.md)

#### 3) Local Test Deployment (run a runner on your machine)

Use this when you’re building or debugging runners, sagas, queries, and business rules. You run a local Spring-based event runner and test through its REST API.

* **Best for:** fast iteration on runner logic, local debugging
* **What you need:** Java, Gradle, sandbox repo, and connectivity to your backing systems (often MongoDB)
* **What you get:** local service process + REST endpoints for health checks and test flows

Continue here: [Local Test Deployment](/installation/deployment-alternatives/local-test-deployment.md)

### Quick decision guide

* Choose **Kubernetes** for higher scale, high availability, and multi-team shared environments.
* Choose **Sandbox VM** for a single-VM “everything included” setup.
* Choose **Local Test** for runner development when you don’t want to deploy infrastructure.


---

# Agent Instructions: 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:

```
GET https://docs.rierino.com/installation/deployment-alternatives.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.