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]