Self-Hosted Supabase on AWS EKS
A private, scalable Supabase deployment on AWS EKS, built with Terraform, Helm, CloudNativePG, EBS, and S3.
Fig. 1 — End-to-end architecture: ALB is the only public entry point into the private EKS cluster.
Overview
Designed and deployed a self-hosted Supabase platform entirely within AWS to meet internal security and infrastructure requirements.
The complete Supabase stack runs on Amazon EKS inside private subnets, with an Application Load Balancer as the only public entry point. PostgreSQL is managed through CloudNativePG with encrypted EBS storage, while uploaded objects and database backups are stored in Amazon S3.
The infrastructure is fully reproducible using Terraform and Helm, providing a minimal starting architecture with a clear path toward multi-node, multi-AZ, and highly available deployments.
Key Highlights
- 01Deployed the complete Supabase stack on Amazon EKS
- 02Kept all workloads private with no public IPs
- 03Used CloudNativePG to manage PostgreSQL inside Kubernetes
- 04Stored database data on encrypted EBS volumes
- 05Used Amazon S3 for object storage and database backups
- 06Provisioned the AWS infrastructure entirely with Terraform
- 07Managed Kubernetes services and configuration through Helm
- 08Designed the architecture to scale without requiring a complete rebuild
Architecture Gallery
What I Learned
This project gave me a deeper understanding of Supabase beyond its SDKs, including how authentication, REST APIs, Realtime, Storage, Kong, connection pooling, and PostgreSQL work together.
It also strengthened my experience with stateful Kubernetes workloads, Helm chart management, private EKS networking, AWS storage integrations, IAM permissions, and infrastructure provisioning with Terraform.
Technology Stack
Source Code
Terraform modules and Helm charts for the full deployment — VPC, EKS, CloudNativePG, S3/EBS wiring, and ALB ingress. Reproducible end to end.