Reusable Kubernetes Infrastructure Template
This repository provides production-ready, template-based Kubernetes infrastructure that can be easily customized and deployed to any cluster using modern best practices.
- Fork-Based Workflow - Clients fork this template and add their configuration
- 100% Parameterized - No hardcoded client-specific values in base template
- Multi-Domain Gateway - Support for both platform subdomains (
*.example.com) and client-owned custom domains (app.client.com) - Security by Default - NetworkPolicies, Pod Security Standards, encryption
- Compliance Ready - Built-in security controls and compliance features
- Modern Stack - Gateway API, ArgoCD GitOps, External Secrets, Velero backups
- Scalable - Designed for <500 users, <1TB data per client (scales further if needed)
This repository contains complete infrastructure for deploying applications on Kubernetes.
monobase-infra/
βββ terraform/ # β OPTIONAL: OpenTofu/Terraform modules
β βββ modules/ # - Reusable infrastructure modules
β β βββ aws-eks/ # - AWS EKS, Azure AKS, GCP GKE
β β βββ azure-aks/ # - K3s on-premises, k3d local
β β βββ gcp-gke/ # Only needed if provisioning clusters
β β βββ on-prem-k3s/ # Can skip if cluster already exists
β β βββ local-k3d/
β βββ examples/ # Example cluster configurations
β βββ aws-eks/ # AWS EKS example
β βββ azure-aks/ # Azure AKS example
β βββ do-doks/ # DigitalOcean DOKS example
β βββ k3d/ # Local k3d example
βββ values/ # β CONFIGURATION: All deployment values
β βββ cluster/ # β YOUR CLUSTER: Terraform config (gitignored)
β βββ infrastructure/ # Infrastructure component values
β βββ deployments/ # Application deployment values
βββ charts/ # β CORE: Helm charts for applications
β βββ api/
β βββ api-worker/
β βββ account/
βββ infrastructure/ # β CORE: K8s infrastructure components
β βββ envoy-gateway/
β βββ argocd/
β βββ ...
βββ argocd/ # β CORE: GitOps configuration
βββ scripts/ # β CORE: Automation scripts
βββ docs/ # β CORE: Documentation
- Cluster Provisioning (Optional): OpenTofu modules for AWS/Azure/GCP/on-prem/local
- Application Deployments: Monobase API, API Worker, Monobase Account Helm charts
- Storage Infrastructure: Cloud-native CSI drivers (EBS, Azure Disk, GCP PD)
- Networking & Routing: Envoy Gateway with Gateway API
- Security Layer: NetworkPolicies, Pod Security Standards, RBAC, encryption
- Backup & Disaster Recovery: Velero 3-tier backups
- Monitoring Stack: Prometheus + Grafana (optional)
- GitOps: ArgoCD with App-of-Apps pattern
- Secrets Management: External Secrets Operator + Cloud KMS
- Configuration Profiles: Pre-configured small/medium/large deployments
Required:
- β Existing Kubernetes cluster (EKS, AKS, GKE, or self-hosted)
- β kubectl configured and authenticated
- β Helm 3.x installed
- β Cluster meets minimum requirements
Minimum Cluster Specs:
- 3 worker nodes
- 4 CPU cores per node (12 total)
- 16GB RAM per node (48GB total)
- 100GB storage per node
This repository includes OpenTofu/Terraform modules for provisioning Kubernetes clusters. Use the unified provision.sh script for all cluster types:
Supported Platforms:
- AWS EKS -
./scripts/provision.sh --cluster acme-eks - Azure AKS -
./scripts/provision.sh --cluster acme-aks - GCP GKE -
./scripts/provision.sh --cluster acme-gke - DigitalOcean DOKS -
./scripts/provision.sh --cluster acme-doks - On-Premises K3s -
./scripts/provision.sh --cluster acme-k3s - Local k3d (Development) -
./scripts/provision.sh --cluster k3d-local
Workflow:
# 1. Provision cluster
./scripts/provision.sh --cluster k3d-local
# 2. Bootstrap GitOps auto-discovery
./scripts/bootstrap.shSee docs/reference/TERRAFORM-MODULES.md for module documentation and docs/getting-started/CLUSTER-PROVISIONING.md for detailed provisioning workflows.
This template works with ANY Kubernetes cluster regardless of how it was provisioned.
True GitOps: Empty cluster β Git-driven auto-deployment
- Existing Kubernetes cluster (EKS, AKS, GKE, K3s, or any distribution)
kubectlconfigured and authenticatedhelm3.x installed
# 1. Fork and clone
git clone https://github.com/monobaselabs/monobase-infra.git
cd monobase-infra
# 2. Bootstrap GitOps auto-discovery (ONE-TIME)
./scripts/bootstrap.shThat's it for setup! The bootstrap script:
- β Installs ArgoCD (if not present)
- β Deploys ApplicationSet for auto-discovery
- β ArgoCD now watches values/deployments/ directory
- β Outputs ArgoCD UI access info
# 3. Create client configuration from example
cp values/deployments/acme-production.yaml values/deployments/acme-prod.yaml
# 4. Edit configuration
vim values/deployments/acme-prod.yaml
# Required changes:
# - global.domain: acme.com
# - global.namespace: acme-prod
# - api.image.tag: "5.215.2" (pin version, not "latest")
# - account.image.tag: "1.0.0" (pin version, not "latest")
# 5. Commit and push to deploy
git add values/deployments/acme-prod.yaml
git commit -m "feat: add acme-prod deployment"
git pushβ ArgoCD auto-detects and deploys! No manual commands needed.
The bootstrap script outputs ArgoCD UI access information. Use the admin credentials provided to log in and monitor your deployments through the ArgoCD web interface.
# Just edit, commit, and push - ArgoCD syncs automatically
vim values/deployments/acme-prod.yaml
git commit -am "Update acme-prod: increase replicas"
git push
# β ArgoCD auto-syncs only acme-prodIf you need to create a Kubernetes cluster first:
# 1. Fork and clone (same as above)
git clone https://github.com/monobaselabs/monobase-infra.git
cd monobase-infra
# 2. Provision cluster using unified script
./scripts/provision.sh --cluster k3d-local
# For other platforms:
# ./scripts/provision.sh --cluster myclient-eks
# ./scripts/provision.sh --cluster myclient-aks
# ./scripts/provision.sh --cluster myclient-doks
# 3. Script will:
# - Initialize Terraform
# - Create cluster infrastructure
# - Extract and save kubeconfig to ~/.kube/{cluster-name}
# - Test cluster connectivity
# 4. Bootstrap GitOps auto-discovery (ONE-TIME)
./scripts/bootstrap.sh
# 5. Create client configuration
cp values/deployments/acme-production.yaml values/deployments/acme-prod.yaml
# 6. Edit configuration
vim values/deployments/acme-prod.yaml
# Required changes:
# - global.domain: acme.com
# - global.namespace: acme-prod
# - global.storage.provider: cloud-default (EKS/AKS/GKE) or local-path (dev)
# - api.image.tag: "5.215.2" (pin version, not "latest")
# - account.image.tag: "1.0.0" (pin version, not "latest")
# 7. Commit and push to deploy
git add values/deployments/acme-prod.yaml
git commit -m "feat: add acme-prod deployment"
git push
# β ArgoCD auto-detects and deploys!All configuration is consolidated in the values/ directory:
Reference Examples:
values/deployments/acme-production.yaml- Complete production configuration (HA, backups, security)values/deployments/acme-staging.yaml- Complete staging configuration (single replicas, Mailpit enabled)
Your Client Config:
- Copy the appropriate example:
cp values/deployments/acme-production.yaml values/deployments/yourclient-{env}.yaml - Edit the new file to change required values (domain, namespace, image tags)
- Customize as needed (resources, replicas, optional components)
Example:
# Create production deployment
cp values/deployments/acme-production.yaml values/deployments/acme-prod.yaml
vim values/deployments/acme-prod.yaml
# Change: domain, namespace, image tags, backup bucket
# Create staging deployment
cp values/deployments/acme-staging.yaml values/deployments/acme-staging.yaml
vim values/deployments/acme-staging.yaml
# Change: domain, namespace
git add values/deployments/acme-*
git commit -m "feat: add acme deployments"
git pushArgoCD automatically discovers any YAML files in values/deployments/ and deploys them.
| Component | Technology | Purpose |
|---|---|---|
| Gateway | Envoy Gateway | Shared Gateway API routing, zero-downtime updates |
| API Backend | Monobase API | Core API service |
| Frontend | Monobase Account | React/Vite frontend application |
| Database | PostgreSQL 16.x | Primary datastore with replication |
| Storage | Cloud-native storage | Persistent storage for databases |
| GitOps | ArgoCD | Declarative deployments with web UI |
| Secrets | External Secrets Operator | Cloud KMS sync (AWS/Azure/GCP) |
The infrastructure automatically selects the appropriate storage provider based on global.storage.provider:
| Provider | Use When | StorageClass |
|---|---|---|
ebs-csi |
AWS EKS | gp3 |
azure-disk |
Azure AKS | managed-premium |
gcp-pd |
GCP GKE | pd-ssd |
local-path |
k3d/k3s dev | local-path |
cloud-default |
Any cloud | (cluster default) |
Recommendation:
- Cloud deployments (EKS/AKS/GKE/DOKS): Use native CSI drivers or
cloud-default - Development: Use
local-pathfor simplicity
| Component | Enable When | Purpose |
|---|---|---|
| API Worker | Offline/mobile sync needed | Real-time data synchronization |
| Valkey | Search features needed | Full-text search engine |
| MinIO | Self-hosted S3 needed | Object storage (files, images) |
| Monitoring | Production visibility needed | Prometheus + Grafana metrics |
| Velero | Backup/DR required | Kubernetes-native backups |
| Mailpit | Dev/staging only | Email testing (SMTP capture) |
Internet β Envoy Gateway (shared, HA) β HTTPRoutes (per client/env) β Applications
β
PostgreSQL + Cloud Storage
MinIO (optional)
Valkey (optional)
Key Design Decisions:
- Shared Gateway - One Gateway in
gateway-system, HTTPRoutes per client (zero-downtime) - Multi-Domain Support - Platform subdomains (
*.example.com) + client custom domains (app.client.com) - Centralized Certificates - All TLS certificates in
gateway-systemnamespace (security best practice) - Namespace Isolation - Each client/environment gets separate namespace (
{client}-{env}) - No Overengineering - No service mesh, no self-hosted Vault (use cloud KMS)
- Security First - NetworkPolicies, PSS, encryption, compliance features built-in
monobase-infra/ # Base template repository
βββ charts/ # Custom Helm charts
β βββ api/ # Monobase API application chart
β βββ account/ # Monobase Account frontend chart
β
βββ infrastructure/ # Infrastructure manifests & configs
β βββ envoy-gateway/ # Gateway API
β βββ argocd/ # GitOps
β βββ external-secrets-operator/ # Secrets management
β βββ cert-manager/ # TLS certificates
β βββ velero/ # Backup solution
β βββ security/ # NetworkPolicies, PSS, encryption
β βββ monitoring/ # Optional Prometheus + Grafana
β
βββ argocd/ # ArgoCD application definitions
β βββ bootstrap/ # App-of-Apps root
β βββ infrastructure/ # Infrastructure apps
β βββ applications/ # Application apps
β
βββ docs/ # Documentation
βββ scripts/ # Automation scripts
See docs/INDEX.md for complete documentation index.
π Getting Started:
- Client Onboarding - Fork, configure, deploy
- Deployment Guide - Step-by-step deployment
- Example Deployments - Production and staging reference examples
ποΈ Architecture:
- System Architecture - Design decisions, components
- GitOps with ArgoCD - App-of-Apps pattern
- Gateway API - Envoy Gateway, HTTPRoutes
- Multi-Domain Gateway - Client custom domains, certificate management
- Storage - Cloud CSI drivers
βοΈ Operations:
- Certificate Management - TLS certificates, client domains
- Backup & DR - 3-tier backup, disaster recovery
- Scaling Guide - HPA, storage expansion
- Troubleshooting - Common issues
π Security:
- Security Hardening - Best practices
- Compliance - HIPAA, SOC2, GDPR
π Reference:
- Values Reference - All configuration parameters
- Optimization Summary - Simplification history
Clients can pull template updates from the base repository:
# In your forked repo (one-time setup)
git remote add upstream https://github.com/monobaselabs/monobase-infra.git
# Pull latest template updates
git fetch upstream
git merge upstream/main
# Resolve any conflicts (usually keep your values/deployments/, accept upstream changes)
git push origin main- NetworkPolicies - Default-deny, allow-specific traffic patterns
- Pod Security Standards - Restricted security profile enforced
- Encryption at Rest - PostgreSQL encryption, cloud storage encryption
- Encryption in Transit - TLS everywhere via cert-manager
- RBAC - Least-privilege service accounts
- Secrets Management - Never commit secrets, use External Secrets + KMS
- Compliance - See compliance documentation in docs/
- 3 nodes Γ 4 CPU Γ 16GB RAM
- ~7 CPU, ~23Gi memory
- ~100Gi storage (PostgreSQL)
- 3-5 nodes Γ 8 CPU Γ 32GB RAM
- ~22 CPU, ~53Gi memory
- ~1.15TB storage (PostgreSQL + MinIO)
Improvements to the base template are welcome! If you implement a useful feature or fix:
- Make changes in your fork
- Test thoroughly
- Submit a pull request to the base template repository
- Your contribution helps all clients!
- Issues: GitHub Issues
- Documentation: docs/
[Add your license here]