Huzaifa Muhammad

01 · Cloud platform

Running E-Commerce on Kubernetes.

Saleor E-Commerce on Amazon EKS

Deployed Saleor on Amazon EKS using Terraform-provisioned infrastructure, HTTPS ingress, Amazon RDS PostgreSQL, and a monitoring stack with Prometheus and Grafana.

Deployed on AWS EKS · Helm chart validated in CI

  • AWS EKS
  • Terraform
  • Kubernetes
  • Docker
  • Helm
  • ALB
  • ACM
  • Amazon RDS
  • Prometheus
  • Grafana
  • Alertmanager
  • GitHub Actions
View repository

01Overview and objectives

This project demonstrates how to deploy and operate an e-commerce application on Amazon EKS. The infrastructure was provisioned using Terraform, while Kubernetes manages the application workloads. AWS Application Load Balancer and ACM provide HTTPS access, and Amazon RDS provides managed PostgreSQL storage.

Prometheus, Grafana, and Alertmanager provide monitoring, dashboards, and email alerting.

02Architecture

Saleor on AWS EKS architectureUsers reach Saleor through an Application Load Balancer secured with an ACM certificate, then a Kubernetes Ingress that routes the dashboard, API and monitoring hostnames to services on EKS. The API uses Valkey and an RDS PostgreSQL database over SSL. Prometheus, Alertmanager and Grafana monitor the cluster and Alertmanager sends email alerts.UUsersbrowser / APIACMTLS certificateApplication LBHTTP → HTTPSAMAZON EKS CLUSTERIngresshost-based routingDashboarddashboard hostSaleor APIapi hostWorkerbackground jobsMonitoring proxymonitoring hostValkeycache / queuePostgreSQLAmazon RDSSSLMONITORINGAmAlertmanageralert routingPrometheusmetrics + rulesGrafanadashboardsalertsqueries@Email alerton firing alerts
Request path and monitoring plane of the Saleor deployment on EKS.

The AWS deployment uses:

  1. Amazon EKS to run Saleor's API, dashboard, and worker workloads
  2. Terraform to provision the VPC, IAM resources, EKS cluster, and managed node group
  3. AWS ALB and ACM for HTTPS ingress and HTTP-to-HTTPS redirection
  4. Amazon RDS PostgreSQL for managed database storage with SSL
  5. Valkey for caching
  6. Prometheus, Grafana, and Alertmanager for monitoring, visualization, and alerting

03How it was built

  1. Infrastructure: Provisioned the VPC, networking, IAM roles, EKS cluster, and managed node group using Terraform.
  2. Application deployment: Deployed Saleor's API, dashboard, and worker using Kubernetes manifests.
  3. Secure ingress: Configured ALB ingress with ACM certificates, HTTPS, and HTTP-to-HTTPS redirection.
  4. Database: Connected the application to Amazon RDS PostgreSQL using SSL and Kubernetes Secrets.
  5. Monitoring: Configured Prometheus, Grafana, and Alertmanager with resource limits.
  6. Helm and CI validation: Maintained a separate Helm chart and used GitHub Actions to run `helm lint` and `helm template` on pushes and pull requests.

04Decisions and trade-offs

  • Used managed Amazon RDS PostgreSQL instead of running the production database inside the Kubernetes cluster
  • Restricted access to the EKS API using CIDR-based access controls
  • Terminated HTTPS at the ALB using ACM certificates
  • Applied resource limits to monitoring components to keep resource usage controlled
  • Kept the AWS manifests separate from the Helm chart, so both approaches are maintained independently

05Security considerations

  • HTTPS access through ALB and ACM
  • SSL connection to Amazon RDS PostgreSQL
  • Database credentials stored in Kubernetes Secrets
  • CIDR-restricted EKS API access
  • Separate IAM roles for the EKS control plane and worker nodes

06Evidence

The project includes evidence from the deployed environment and CI workflow:

  • ALB, ACM certificate, and HTTPS configuration
  • Saleor dashboard, API, and GraphiQL access
  • RDS SSL configuration
  • Prometheus monitoring and Grafana dashboards
  • Alertmanager configuration and alerting
  • Successful GitHub Actions runs validating the Helm chart
Saleor dashboard served over HTTPS.
Saleor API reachable on its own hostname.
GraphiQL served by the API.
Grafana: CPU and memory by namespace.
Alertmanager routing alerts to an email receiver.
Alert email delivered by Alertmanager.
Helm validation runs on GitHub Actions.

07Scope and next steps

The AWS deployment uses Kubernetes manifests and Amazon RDS PostgreSQL. The separate Helm chart includes an in-cluster PostgreSQL configuration and is validated through GitHub Actions.

The current CI workflow validates the Helm chart; it does not automatically deploy the application to AWS.

Potential improvements

  • Manage RDS and ACM resources through Terraform
  • Add an automated deployment stage after CI validation
  • Move worker nodes into private subnets

Related projects

02Delivery & security

Secure CI/CD Pipeline for Tabulae

GitHub Actions runs backend tests, frontend checks, Docker builds, secret and dependency scanning, and publishes images to Amazon ECR using OIDC.

  • GitHub Actions
  • Docker
  • Pytest
  • PostgreSQL
Read the case study
03Observability

AWS Observability Platform for Tabulae

Prometheus, Grafana, Loki and Alloy, with Blackbox Exporter health probes and an alert rule that fires when the application endpoint goes down.

  • Prometheus
  • Grafana
  • Loki
  • Grafana Alloy
Read the case study
04Infrastructure automation

Infrastructure Automation with Terraform, Ansible and Jenkins

Terraform with S3 remote state, a Jenkins pipeline with a manual approval gate, and Systems Manager commands that start and verify Nginx on EC2.

  • Terraform
  • Jenkins
  • Ansible
  • AWS EC2
Read the case study