One YAML File.
Full Stack.
Production Ready.

Deploy your entire GCP + AWS + Kubernetes infrastructure from a single YAML config. No Terraform expertise. No HCL. Push to GitHub and everything deploys in the right order.

Get Started See the YAML
RABBIT infra.yaml
services:
- module: gcp-networking
- module: gcp-gke-cluster
- module: gcp-sql-instance
- module: k8s-deployment
- module: aws-cloudfront
Your YAML defines the infrastructure — Rabbit makes it real
ACTION rabbit-auto
Resolve dependency order
OIDC → Workload Identity
Isolated state per module
Plan on PR, apply on merge
GitHub Action parses YAML — resolves order — zero credentials needed
LIVE production
VPC + Subnets
GKE Cluster
Cloud SQL HA
K8s Workloads
CloudFront CDN
WAF (6 rulesets)
New Relic Synthetics
25
Modules
1
Config
0
Credentials
4.5yr
Battle Tested
Every resource live — stateful, observable, zero credentials in pipeline
The Problem
Infrastructure Shouldn't Require
a Platform Team
Most teams spend weeks stitching together Terraform modules, debugging dependency ordering, and managing state files. Rabbit eliminates all of it.
Module Sprawl
Every team writes the same GKE cluster, VPC, and Cloud SQL modules from scratch. Copy-paste across repos, drift over time, nobody owns the shared code.
2-4 weeks to build from scratch
Dependency Hell
Networking must deploy before GKE. GKE before node pools. Node pools before K8s resources. Get the order wrong and the whole stack fails.
#1 cause of deployment failures
Credential Sprawl
Service account keys in GitHub Secrets. API tokens in environment variables. Nobody knows which credentials are active or when they expire.
Top audit finding every year
HCL Learning Curve
Terraform's HCL syntax requires specialized knowledge. Your app developers can read YAML instinctively—HCL requires training.
40+ hours to become productive
Plan/Apply Gap
Running Terraform locally gives different results than CI/CD. Different credentials, different state, different surprises in production.
"Works on my machine" for infra
Multi-Client Chaos
Agencies managing multiple client projects duplicate entire Terraform repos per client. Updates mean touching every repo manually.
N repos × N modules = chaos
How It Works
Three Steps. Zero Terraform Expertise.
1
Write One YAML
List the infrastructure services you need. Each entry maps to a battle-tested Terraform module with production-grade defaults.
services: - module: gcp-networking id: prod-network - module: gcp-gke-cluster id: prod-gke - module: k8s-deployment id: web-app
2
Push to GitHub
On a PR, Rabbit runs terraform plan and posts the diff. Merge to a protected branch and it auto-applies. Same workflow your team already uses for code review.
# .github/workflows/infra.yml - uses: udx/rabbit-automation-action@v1 with: config_path: .rabbit/prod/infra.yaml plan_only: ${{ github.event_name == 'pull_request' }}
3
Everything Deploys in Order
Rabbit auto-resolves dependency ordering: networking → GKE → node pools → K8s resources → CDN → WAF → monitoring. No manual orchestration.
✔ gcp-networking (order: 10) ✔ gcp-gke-cluster (order: 20) ✔ gcp-gke-nodepool (order: 30) ✔ k8s-deployment (order: 80) ✔ aws-cloudfront (order: 130) ✔ gcp-monitoring (order: 140)
Live Example
This YAML Deploys a Production Stack
The left panel shows what you write. The right panel shows what Rabbit deploys. Module defaults handle 90% of the configuration—you only specify what's unique to your project.
.rabbit/production/infra.yaml
1# Your entire infrastructure in one file
2services:
3
4 - module: gcp-networking
5 id: prod-network
6 configurations:
7 network_name: prod-vpc
8 region: us-east1
9
10 - module: gcp-gke-cluster
11 id: prod-gke
12 configurations:
13 cluster_name: prod-cluster
14 region: us-east1
15
16 - module: gcp-sql-instance
17 id: prod-db
18 configurations:
19 database_version: MYSQL_8_0
20 availability_type: REGIONAL
21
22 - module: k8s-deployment
23 id: web-#{Environment}
24
25 - module: aws-cloudfront-distribution
26 id: cdn-#{Environment}
27
28 - module: gcp-monitoring
29 id: prod-alerts
Deployment Output
gcp-networking
prod-network · VPC + subnet + secondary ranges
+3 applied
gcp-gke-cluster
prod-gke · Regional cluster + master auth
+5 applied
gcp-gke-nodepool
prod-nodes · e2-standard-4, 1-5 autoscale
+2 applied
gcp-sql-instance
prod-db · HA MySQL 8.0, SSL, query insights
+4 applied
k8s-deployment
web-production · Workload Identity bound
+3 applied
aws-cloudfront-distribution
cdn-production · WP-optimized caching
+8 applied
gcp-monitoring
prod-alerts · DB + CPU + Slack notifications
+6 applied
Defaults do the heavy lifting. Each module ships with a default.yml containing production-grade configuration. Your YAML only overrides what's specific to your project. The CloudFront module alone includes WordPress-optimized cache behaviors, origin failover, Lambda@Edge routing, and WAF integration—all from one service entry.
Module Library
25 Production-Grade Modules
Every module ships with opinionated defaults built from 4.5 years of production use. Override only what's unique to your project.
gcp-networking
VPC, subnets, secondary ranges for pods/services
order: 10
gcp-iam
Service accounts, roles, Workload Identity
order: 15
gcp-gke-cluster
Regional GKE cluster with VPC-native networking
order: 20
gcp-gke-nodepool
Auto-scaling node pools with repair/upgrade
order: 30
gcp-sql-instance
HA MySQL/Postgres with SSL, backups, insights
order: 40
gcp-postgresql-instance
Dedicated PostgreSQL with Flex Server support
order: 40
gcp-secret-manager
Secret creation with labels and access controls
order: 50
gcp-storage
Buckets with lifecycle rules and versioning
order: 50
gcp-static-ip
Reserved external IP addresses
order: 15
gcp-monitoring
Alert policies, notification channels, Slack
order: 140
aws-cloudfront-distribution
CDN with WP-optimized caching, origin failover, Lambda@Edge
order: 130
aws-waf
Managed rulesets: SQLi, XSS, brute-force, rate limiting
order: 125
k8s-deployment
Deployments with Workload Identity binding
order: 80
k8s-hpa
Horizontal Pod Autoscaler
order: 90
k8s-pdb
Pod Disruption Budgets for availability
order: 90
k8s-service
ClusterIP/LoadBalancer service definitions
order: 85
k8s-configmap
ConfigMaps with secret injection
order: 75
k8s-namespace
Namespace creation and resource quotas
order: 70
k8s-secret
Kubernetes Secrets from GCP Secret Manager
order: 75
k8s-access
RBAC roles and service account bindings
order: 72
k8s-http-gateway-route
Gateway API HTTPRoute resources
order: 100
k8s-http-health-check-policy
Health check policies for Gateway API
order: 100
k8s-memcached
Memcached via Helm with registry auth
order: 85
k8s-shared-http-gateway
Shared Gateway API Gateway resource
order: 95
newrelic-synthetic-monitors
Uptime checks from multiple regions, Slack alerts
order: 150
Security
Zero Credentials. Everywhere.
No API keys in environment variables. No service account JSON files. No static credentials anywhere in your pipeline. Workload Identity handles authentication end-to-end.
Workload Identity Federation
GitHub Actions authenticates directly with GCP using OIDC tokens. No service account keys stored in GitHub Secrets. The identity is the workload itself.
GCP Secret Manager Injection
Reference secrets in your YAML using GCP Secret Manager paths. Rabbit resolves them at deployment time and injects values into Terraform configs automatically.
Service Account Impersonation
Local development uses the same Workload Identity model. Run worker run on your laptop with service account impersonation—no key files, identical to CI/CD.
PR-Gated Deployments
Pull requests trigger plan-only mode. Destructive changes exceeding your threshold automatically fail the PR. Protected branches enforce approval before any apply.
Enterprise WAF Out of the Box
The AWS WAF module ships with 6 managed rulesets enabled by default: WordPress, SQL injection, XSS, PHP, Linux, and Account Takeover Prevention with brute-force login protection.
State Isolation
Each service gets its own Terraform state file in GCS, prefixed by environment, module, and service ID. No shared state locks. No cross-module state corruption.
Comparison
How Rabbit Stacks Up
Rabbit occupies a unique position: simpler than Terragrunt, more opinionated than Atmos, and free. Here's how it compares to the alternatives.
Feature Rabbit Terragrunt Atmos Spacelift Manual TF
Config Language YAML only HCL YAML HCL + UI HCL
Terraform Knowledge Required None Moderate Minimal Moderate Expert
Auto Dependency Ordering ✔ Built-in ✔ dependency{} ✔ ✔ ✘
Pre-Built GCP Modules 25 modules BYO AWS-focused BYO BYO
Opinionated Defaults ✔ default.yml ✘ ✔ ✘ ✘
Workload Identity ✔ Built-in Manual Manual ✔ Manual
PR Plan / Merge Apply ✔ Via Atlantis ✔ ✔ ✘
Local Dev Parity ✔ worker run ✔ ✔ Cloud only Different creds
Cost Included Free / OSS Free / OSS From $499/mo Free
Setup Time Minutes Hours Hours-Days Hours Weeks
vs Terragrunt
YAML Instead of HCL
Terragrunt requires writing HCL wrappers around modules with find_in_parent_folders(), dependency blocks, and input maps. Rabbit uses YAML that any developer can read and edit without Terraform training.
vs Atmos (Cloud Posse)
GCP-Native, Not AWS-Centric
Atmos is built around the AWS SweetOps ecosystem with 800+ AWS components. Rabbit is built for GCP-first teams with AWS CDN/WAF integration. Simpler stack, less learning curve, more opinionated.
vs Spacelift / env0
Runs in Your GitHub. You Own It.
Spacelift starts at $499/mo and requires sending your Terraform state to a third party. Rabbit runs as a GitHub Action in your own infrastructure. No vendor lock-in, no SaaS dependency.
Under the Hood
Production Patterns. Battle-Tested.
Details from 4.5 years of running multi-tenant infrastructure across GCP and AWS for agencies, startups, and enterprise clients.
Isolated GCP Projects
Each client gets their own GCP project, artifact registry, and Kubernetes namespace. Billing, IAM, and secrets are completely separated. No cross-tenant data leakage.
Per-Client GitHub Orgs
Repositories fork into client GitHub organizations with automated sync. Build artifacts deploy to client-owned registries. Disaster recovery plan included—clients can operate independently.
Shared WAF, Per-Client Rules
One UDX shared WAF serves all tenants to reduce costs ($5–10/ACL + $1/rule). Clients with custom requirements like large POST payloads get dedicated WAF configurations.
60–80% WAF cost reduction
Real migration, not a demo. In March 2026, we completed a full V3 → V5 cluster migration across all tenants. Below is the actual sequence we followed. The same process applies when onboarding new clients or migrating from manual Terraform.
Migration Sequence
1
Deploy new cluster + SFTP
Provision GKE cluster with Rabbit infra configs. Deploy SFTP access first so developers aren't blocked during tenant migration.
Day 1–2
2
Migrate networking + WAF
Recreate CloudFront distributions, link to shared UDX WAF. Delete deprecated firewall rules and unused IP ranges.
Day 3–5
3
Move tenant workloads
Deploy each tenant namespace with Workload Identity. Configure Firebase real-time database for CloudFront distribution IDs and container state.
Day 5–9
4
Validate + decommission old cluster
Remove Rabbit Cron, Rabbit Updater, and legacy services. Verify all tenants operational. Delete old cluster.
Day 9–12
Disaster Recovery
Client-Owned Recovery
Repositories auto-sync to client's GitHub organization. Build artifacts publish to their Google Cloud project. If the relationship ends, the client has everything needed to operate independently.
State + Config Portability
Terraform state files in client-owned GCS buckets. Infra YAML configs in client-owned repos. Workload Identity bound to their GCP project. No vendor lock-in on any layer.
12
Days to Migrate
0
Downtime
100%
Client Owned
Full Pipeline in Your Repository
# .github/workflows/rabbit-infra.yml name: Infrastructure on: pull_request: paths: ['.rabbit/**'] push: branches: [main] jobs: deploy: runs-on: ubuntu-latest permissions: id-token: write # OIDC for Workload Identity contents: read pull-requests: write # Post plan as PR comment steps: - uses: udx/rabbit-automation-action@v1 with: config_path: .rabbit/prod/infra.yaml plan_only: ${{ github.event_name == 'pull_request' }} post_plan_comment: true # Auto-update Firebase with deploy state - uses: udx/rabbit-firebase-sync@v1 if: github.ref == 'refs/heads/main' # Invalidate CloudFront cache post-deploy - uses: udx/rabbit-cache-invalidate@v1 if: github.ref == 'refs/heads/main'
What Happens on Each Event
Pull Request Opened
Rabbit runs terraform plan and posts the diff as a PR comment. Destructive changes exceeding your threshold auto-fail the check. Reviewers see exactly what will change before approving.
Merge to Protected Branch
Rabbit auto-applies the plan. Dependency ordering ensures networking deploys before GKE, GKE before workloads. Firebase real-time database updates immediately so containers pick up new state (CloudFront IDs, config changes).
Post-Deploy Automation
CloudFront cache invalidation fires automatically. New Relic synthetic monitors verify endpoints. Container SHA updates propagate via Firebase—no webhook pings, no manual triggers.
New Relic APM
Full application performance monitoring for every tenant. Track MySQL query times, response latency, and throughput. Real-time alerts when response time exceeds thresholds.
Query analysis down to individual SQL statements
Synthetic Monitoring
New Relic synthetic monitors ping every endpoint from multiple regions. Login flows, API health, and critical page loads verified every minute. Slack alerts on failure.
Multi-region pings every 60 seconds
Container Health
PHP worker max children, keep-alive timeouts, CGI read timeouts, and horizontal pod autoscaling monitored continuously. Crash loops detected and reported via GCP alerting.
Crash container detection + auto-restart
MySQL Insights
Cloud SQL Query Insights enabled by default. Identify slow queries, CPU spikes, and connection pool exhaustion. Memcached hit rates tracked to catch cache misses before they impact users.
From 7s to sub-1s query times on one client
Terraform Plan Drift
Nightly plan runs compare declared state vs cloud state. Diffs posted to Slack when infrastructure has drifted. Manual console changes caught before they cause production issues.
Nightly drift detection
Cron → GitHub Actions
Scheduled tasks migrated from RabbitKron to GitHub Actions for full observability. Run history, logs, and failure alerts visible in GitHub UI instead of buried in container logs.
Full audit trail for every scheduled job
How We Work Together
Managed Infrastructure Service
Rabbit ships as a GitHub Action inside your repository—you own the code. UDX provides the modules, the defaults, and the initial setup. We configure Workload Identity, provision your GCP resources, and deploy your first stack. Ongoing support is included.
Included With UDX Engagement
Rabbit is not a separate SaaS product. It's included as part of your UDX infrastructure engagement. No per-seat pricing, no per-deploy charges, no module marketplace. Your team gets full access to all 25 modules and future releases.
Embedded Engineers
UDX engineers join your Slack, attend standups, and work inside your repositories. Infrastructure changes go through the same PR workflow as your application code. Your team learns the patterns by working alongside ours.
What You Get
25 production-grade Terraform modules with opinionated defaults
Workload Identity Federation configured for your GCP + GitHub
PR-gated deployment pipeline running in your GitHub Actions
CloudFront + WAF with WordPress-optimized caching out of the box
New Relic synthetic monitors for uptime across regions
Firebase real-time state propagation to running containers
Nightly Terraform drift detection with Slack alerts
Disaster recovery documentation and client-owned state files
No vendor lock-in. Every YAML config, Terraform state file, and container image lives in your infrastructure. If you stop working with UDX, you keep everything. The modules are standard Terraform—any engineer can maintain them.
Stop Writing Terraform.
Start Shipping Infrastructure.
Rabbit runs as a GitHub Action inside your own repository. We set it up for you. Deploy your first stack in days, not months.
Get Started Talk to Us
For Agencies
Manage All Client Sites from One Config Pattern
Each client gets their own YAML, GCP project, and isolated state. Same modules, same defaults, same deployment workflow. Onboard a new client project in minutes.
For Startups
Production GCP Stack Without a Platform Team
VPC, GKE, Cloud SQL, CDN, WAF, monitoring—all from one YAML file. Your engineers focus on product, not infrastructure. Scale from 1 to 50 services without rewiring.
For Platform Teams
Golden Path for Your Engineering Org
Ship opinionated infrastructure templates your teams actually use. YAML is readable by everyone. Module defaults encode your org's best practices. PRs catch mistakes before they reach production.
Built with