Skip to main content

​
Registry Access

You’ll need credentials from our support team to access Membrane artifacts: Registry Credentials
  • Username format: robot$<your-company-name>
  • Access to: harbor.getmembrane.com

​
Setting Up Registry Access

  1. Login to Helm registry
helm registry login harbor.getmembrane.com \
  --username <registry-username> \
  --password <registry-password>
  1. Pull and unpack the Integration.app Helm chart:
# See Versions section at the bottom of this page for available versions
helm pull oci://harbor.getmembrane.com/helm/integration-app --version <version> --untar

​
Prerequisites

Before installing Membrane using Helm, ensure you have the following components set up:

​
Prometheus Stack

The kube-prometheus stack provides Prometheus, Grafana dashboards, and necessary Prometheus rules: 
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring
helm install prometheus-stack prometheus-community/kube-prometheus-stack --namespace monitoring
For advanced configuration options, refer to the kube-prometheus stack documentation.

​
KEDA

If you plan to use autoscaling features, install KEDA: 
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
kubectl create namespace keda
helm install keda kedacore/keda --namespace keda
For advanced KEDA configuration, consult the official KEDA documentation.

​
Installation

  1. Configure Container Registry Access
Create a Docker registry secret using your container registry credentials: 
kubectl create secret docker-registry integration-app-harbor \
  --namespace <your-namespace> \
  --docker-server=harbor.getmembrane.com \
  --docker-username=<registry-username> \
  --docker-password=<registry-password>
  1. Prepare Configuration
Populate or provide override to values.yaml file with the values for your setup:
yaml
serviceAccount:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:role/<YOUR_ROLE_NAME>

config:
  NODE_ENV: production
  MONGO_URI: MONGO_URI
  REDIS_URI: REDIS_URI
  # Self-hosting token (required) - generate from https://console.getmembrane.com
  SELF_HOSTING_TOKEN: SELF_HOSTING_TOKEN
  # URI where `api` service will be available
  API_URI: API_URI
  # URI where `ui` service will be available
  UI_URI: UI_URI
  # URI where `console` service will be available
  CONSOLE_URI: CONSOLE_URI
  # Bucket for storing custom connectors
  CONNECTORS_S3_BUCKET: CONNECTORS_S3_BUCKET
  # Bucket for storing temporary files (like logs)
  TMP_S3_BUCKET: TMP_S3_BUCKET
  # Buckets for storing static files that should be available in user's browser (like images)
  STATIC_S3_BUCKET: STATIC_S3_BUCKET
  # Base URI where files stored in STATIC_S3_BUCKET will be available
  BASE_STATIC_URI: BASE_STATIC_URI
  # Auth0 Settings
  AUTH0_DOMAIN: AUTH0_DOMAIN
  AUTH0_CLIENT_ID: AUTH0_CLIENT_ID
  AUTH0_CLIENT_SECRET: AUTH0_CLIENT_SECRET
  # Secret key used for signing JWT tokens
  SECRET: SECRET
  # Secret key used for encrypting data at rest
  ENCRYPTION_SECRET: ENCRYPTION_SECRET
  1. Validate Chart
Before deploying, make sure that chart is rendering correctly: 
helm template integration-app ./path-to-your-chart --namespace <your-namespace>
  1. Select Cluster Context
Make sure to switch to desired cluster context: 
kubectl config use-context <your-desired-context>
  1. Deploy
Install the chart to cluster: 
helm install integration-app ./path-to-this-folder --namespace <your-namespace> --create-namespace
To update an existing installation: 
helm upgrade integration-app ./path-to-this-folder --namespace <your-namespace>

​
Autoscaling Configuration

The following components support autoscaling:
  • API
  • Instant Tasks Worker
  • Queued Tasks Worker
  • Custom Code Runner
Each component that supports autoscaling accepts these parameters:
ParameterTypeDescription
.autoscaling.enabledBooleanEnables/disables autoscaling for the component. If autoscaling is a number of replicas will taken from.replicas property. IF autoscaling is enabled, .replicas is ignored.
.autoscaling.minReplicaCountNumberMinimum number of replicas
.autoscaling.maxReplicaCountNumberMaximum number of replicas
.autoscaling.cooldownPeriodNumberCooldown period between scaling operations
.autoscaling.pollingIntervalNumberHow often to check scaling metrics
These properties are part of KEDA’s core functionality. For more detailed information, please refer to the official KEDA documentation.

​
Component-Specific Scaling

Each component has specific scaling parameters that control its autoscaling behavior:
ParameterTypeDefaultDescription
api.autoscaling. scalingTargets. cpuUtilizationPercentNumber50Defines the target CPU utilization percentage. Adjusting this value will influence how aggressively the API scales in response to CPU load
instantTasksWorker. autoscaling. scalingTargets. utilizationRateNumber0.75Defines the expected percentage of time (0.0-1.0) that workers should be actively processing tasks. Higher values minimize worker idle time but can cause processing delays during high load periods
customCodeRunner. autoscaling. scalingTargets. capacityRateNumber0.45Defines the capacity rate of available to total slots. A higher value increases the likelihood of custom code execution waiting for a slot, potentially slowing down API requests. A lower value ensures that custom code requests are processed promptly, but it may result in a higher number of idle pods.
queuedTasksWorker. autoscaling. scalingTargets. utilizationRateNumber0.85Defines the expected percentage of time (0.0-1.0) that workers should be actively processing tasks. Higher values minimize worker idle time but can cause processing delays during high load periods

​
Versions and Changelog

​
Latest Version: 0.2.4

VersionRelease DateChanges 0.2.42025-12-04Simplified autoscaling for instant-tasks-worker and queued-tasks-worker to use utilizationRate-based metrics with Prometheus queries. Added Prometheus scraping annotations and service for instant-tasks-worker.0.2.32025-10-21Optimized graceful shutdown timing and improved health check reliability for better pod lifecycle management0.2.22025-10-09Added startup probe configuration with 5s period and 60s failure threshold across all services for improved container initialization handling. Updated deployment strategy with maxSurge: 50% and maxUnavailable: 25% for better control during rolling updates.0.2.12025-06-01Initial release of the Helm chart Support for all core services KEDA autoscaling configuration Prometheus metrics integration