Self-hosting on AWS
This guide provides AWS-specific information for deploying Membrane in your AWS environment.S3 Storage configuration
Create the necessary S3 buckets:
s3.tf
Create CloudFront Distribution:
cloudFront.tf
IAM Role Configuration
Membrane containers support AWS IAM role-based access to S3 and other AWS services. This is the preferred method over providing explicit access and secret keys.Container IAM Configuration
To use IAM roles instead of access keys:- Create an IAM role with appropriate S3 permissions
- Assign this role to your ECS tasks, EKS pods, or EC2 instances
- Omit the
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYenvironment variables
MongoDB on AWS
While AWS DocumentDB is technically compatible with our application, we recommend using native MongoDB (either self-hosted on EC2 or a managed MongoDB Atlas cluster) for better compatibility. Some customers have encountered edge cases with DocumentDB due to differences in MongoDB API implementation. If you choose to use DocumentDB, be prepared for potential compatibility issues.Redis on AWS
For Redis, you can use Amazon ElastiCache. Keep in mind that Redis is only used as a cache in our application and can be safely restarted or cleared. There’s no persistent data stored in Redis that isn’t recoverable from other sources.ElastiCache TLS Configuration
If you’re using ElastiCache with in-transit encryption enabled, set the following environment variable:EKS Deployment
When deploying Membrane on Amazon EKS, you may encounter startup issues due to DNS resolution delays that are common in Kubernetes environments. This section provides recommended configurations and troubleshooting guidance.Common Startup Issues
CrashLoopBackOff due to health check failures: During initial deployment or image upgrades, pods may fail health checks because MongoDB or Redis connections timeout before DNS resolution completes. Symptoms:- Pods entering
CrashLoopBackOffstate shortly after startup - Health check endpoint returning failures
- Logs showing connection timeouts to MongoDB or Redis
Recommended EKS Configuration
Add these environment variables to your deployment to handle slower DNS resolution in Kubernetes:Health Check Retry Configuration
Health checks include built-in retry logic with exponential backoff to handle transient network issues common in Kubernetes environments.| Variable | Default | Description |
|---|---|---|
HEALTH_CHECK_RETRIES | 3 | Number of retry attempts after initial failure |
HEALTH_CHECK_RETRY_DELAY_MS | 1000 | Initial delay between retries (milliseconds) |
HEALTH_CHECK_MAX_RETRY_DELAY_MS | 10000 | Maximum delay between retries (milliseconds) |
- First retry: ~1 second delay
- Second retry: ~2 seconds delay
- Third retry: ~4 seconds delay
- And so on, up to the maximum delay
Health Check Skip Options
If retry logic is insufficient, you can skip specific health checks using theSKIP_HEALTH_CHECKS environment variable:
| Value | Description |
|---|---|
all | Skip all health checks (MongoDB, Redis, storage, custom code) |
mongo | Skip only MongoDB connectivity check |
redis | Skip only Redis connectivity check |
storage | Skip only cloud storage bucket check |
custom_code | Skip only custom code runner check |
mongo,redis | Skip multiple checks (comma-separated) |
Kubernetes Probe Configuration
In addition to the environment variables, consider adjusting your Kubernetes probe settings:Troubleshooting
1. Check pod logs for connection errors:- Ensure security groups allow traffic between EKS nodes and your MongoDB/Redis instances
- Verify VPC peering or PrivateLink configurations if using cross-VPC connections
- Check that IAM roles have appropriate permissions for S3 bucket access