> For the complete documentation index, see [llms.txt](https://doc.wearepatchworks.com/product-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.wearepatchworks.com/product-documentation/developer-hub/self-hosting.md).

# Self-hosting

*Deploy Patchworks Core into a customer-managed Kubernetes environment using Helm. Self-hosting is designed for organisations that need greater control over their infrastructure, hosting location, networking, or security posture - while still using Patchworks Core to build and run integrations.*

***

### Overview

A self-hosted Patchworks deployment runs the full Patchworks application and its supporting services inside Kubernetes. Deployment is delivered using Helm charts, with a split chart approach recommended for most environments - separating infrastructure and application resources into `patchworks-infra` and `patchworks-app`.

***

### Architecture

A self-hosted environment is made up of two layers. The **infrastructure layer** covers the baseline services Patchworks depends on - including MySQL, Redis, RabbitMQ, Elasticsearch, and object storage. The **application layer** covers the Patchworks application itself - gateway, web services, schedulers, workers, and migrations.

***

### Prerequisites

Before deploying, you'll need a working Kubernetes cluster, Helm, kubectl, container registry access, and a plan for DNS, TLS, and secrets management. Local proof-of-concept deployments can use `kind` with all services running in-cluster.

***

### Installation

Installation follows a structured sequence: prepare a shared values file, install the infrastructure chart and confirm services are healthy, then install the application chart and validate migrations, ingress, and dashboard access.

***

### Configuration

Everything is configured through Helm values - covering application URLs, database and cache connections, message broker settings, object storage, ingress, worker configuration, and secrets.

***

### Worker modes

Patchworks supports three worker deployment models - including microservice - each suited to different scaling requirements and operational complexity. The right mode is typically agreed during implementation.

***

### Operational checks

After deployment, a standard set of checks should be completed across pod status, migration and seeder jobs, worker logs, queue health, storage access, search availability, ingress routing, and application login.

***

### Production considerations

Running Patchworks in production requires attention to high availability, backups, monitoring, centralised logging, secrets management, worker scaling, security controls, upgrade processes, and disaster recovery planning.