Rabbit is a GitOps automation platform by UDX. Infrastructure is declared as YAML files in an application repository, and a GitHub Marketplace action turns pull requests into Terraform plans and merges into applied infrastructure across AWS, GCP, and Kubernetes.

How does Rabbit deploy infrastructure?

A single GitHub Actions step discovers YAML configs in the repository, merges them per environment, authenticates with short-lived cloud identity, and runs Terraform per service in dependency order. Pull requests get a plan comment; pushes apply; deleted branches destroy their ephemeral environments; a nightly plan detects drift.

What infrastructure can Rabbit manage?

A catalog of more than two dozen modules covering AWS (CloudFront, WAF, Route53, ACM), GCP (GKE, Cloud SQL, Secret Manager, networking, monitoring), and Kubernetes workloads (deployments, services, HPA, PDB, gateway routes, namespaces), plus monitoring integrations.

Is Rabbit safe to point at production?

Production is guarded by design: manual production applies are blocked, production destroy is blocked outright, pull requests can only plan, and a nightly drift check reports out-of-band changes. Production changes flow only through reviewed merges.

UDX Worker is the open container runtime contract Rabbit workloads run on: base, Node.js, and PHP images with declarative supervised services, runtime secret resolution from cloud providers, and redacted release evidence for CI. The guide lives at udx.dev/worker.

Rabbit: GitHub to Kubernetes GitOps Automation

Q: When do I not need Rabbit?

If you run one application on a platform you like and have no compliance requirements, a PaaS is the right amount of infrastructure. Rabbit earns its keep when environments multiply, when auditors ask who changed what and when, or when infrastructure has outgrown the person who clicked it together.

About
Cloud Automation
DevOps Manual
Strategy
Resources
Our Projects
Contact

Infrastructure That Lives in Your Repository

Every team eventually discovers that the cloud console was a trap. Someone clicked something two years ago, nobody remembers why, and now staging works for reasons no one can explain. Rabbit ends that. Everything your application needs - the CDN in front of it, the firewall rules, the DNS and certificates, the Kubernetes workloads, the secrets wiring - is YAML in the application's own repository, reviewed like code and applied by machinery: one step in a GitHub Actions workflow, published on the GitHub Marketplace.

      .github/workflows/infra-build.yamlthe entire integration
    

on:
  pull_request: { branches: ["production", "staging"] }
  push: { branches: ["production", "staging"] }

jobs:
  deploy:
    steps:
      - uses: actions/checkout@v4
      - uses: udx/github-rabbit-action@v1

      .rabbit/production/30-app.yamla workload, declared
    

services:
  - module: k8s-namespace
    id: my-app
  - module: k8s-deployment
    id: my-app
    image: my-org/my-app:latest
    replicas: 2
  - module: k8s-http-gateway-route
    id: my-app
    hostname: my-app.example.com

Software logistics is the discipline of moving software from where it is made to where it runs - staged, tracked, and delivered intact. Rabbit is that discipline built as machinery. Worker puts a software factory in your pocket: one container contract that configures, supervises, and ships your processes identically everywhere. Rabbit hands you the palette: a catalog of infrastructure modules you compose into whole environments with a few lines of YAML.

Declare the environment you want. The cloud converges to match.

Compose Environments from a Catalog

Behind the single workflow step sits a catalog of more than two dozen infrastructure modules: CloudFront and WAF at the edge, Route53 and ACM for names and certificates, GKE, Cloud SQL, and Secret Manager on Google Cloud, and the full family of Kubernetes workload resources. You compose them like a palette - a CDN here, a firewall there, a deployment behind it - and Terraform applies them in dependency order. The same composition, replayed per lifecycle, is how a branch becomes staging and a merge becomes production: every stage gets its own branch, its own domain, and its own complete stack.

Rehearse Every Change Before It Is Real

Open a pull request and Rabbit posts the plan as a comment: every resource that will be created, changed, or destroyed, reviewed next to the code that caused it. Merge, and it applies. Delete a branch, and its ephemeral environment is cleaned up behind you. A nightly plan catches drift, so the console click somebody made on Friday shows up in a report instead of an outage. Production is guarded by design: manual applies are blocked, destroy is blocked outright, and pull requests can only ever plan. The safe path and the lazy path are the same path.

A Software Factory in Your Pocket

The containers Rabbit deploys run on UDX Worker, our open runtime contract: base, Node.js, and PHP images published on Docker Hub. A services.yaml declares the supervised processes a container runs. A worker.yaml carries configuration and references to provider secrets that are resolved at runtime, never baked into an image. CI captures redacted release evidence of exactly what shipped. One contract for every workload, identical from a laptop to production.

Read the Worker Guide

It Runs the Page You Are Reading

Rabbit has been in production since January 2023, and udx.io is one of its tenants: the CloudFront distribution serving this page, the WAF in front of it, and the Kubernetes workloads rendering it are all YAML in this site's repository. When we talk about WordPress at scale, this is the delivery system underneath.

It is also the machinery in our recent field stories. When a live music venue needed a complete second home for its Next.js site - Kubernetes, secrets, live data, and a per-tenant firewall, stood up beside the incumbent host with production untouched - the entire environment was eight YAML files and two workflows. And the static-site preview system that gives every branch a live URL is the same idea at its lightest weight.

Questions Engineers Actually Ask

What happens on a pull request, a merge, a deleted branch?

Trigger	What Rabbit does
Open a pull request	Plan only: the full diff of your infrastructure, posted as a PR comment
Merge or push	Apply: the environment converges to what the YAML declares
Delete a branch	Destroy: the ephemeral environment is removed behind you
Nightly schedule	Plan only: drift detection, so console clicks get caught and reported
Manual dispatch	Your choice of plan, apply, or destroy - with production guarded

How does Rabbit know which environment a branch is?

The environment is not a setting; it is the branch. A push to production resolves to the production lifecycle, staging to staging, and everything else to development - where per-developer folders give each engineer a personal environment built from the same modules as production. Pull requests resolve against their target branch, which is why a PR into production shows you the production plan.

How does it authenticate to my clouds?

With short-lived identity: GCP Workload Identity Federation and AWS OIDC roles. No long-lived cloud keys sitting in repository secrets.

Is it safe to point at production?

Production is guarded by design. Manual production applies are blocked - changes arrive only through the merge pipeline where they were planned and reviewed. Production destroy is blocked outright. Pull requests can never apply. A nightly plan reports drift before it becomes a mystery.

When do I not need Rabbit?

If you run one application on a platform you like, deploy from its dashboard, and have no compliance questions to answer, stay there - a PaaS is the right amount of infrastructure for that job. Rabbit earns its keep when environments multiply, when auditors ask who changed what and when, or when the infrastructure has outgrown the person who originally clicked it together.