Blueprints

Blueprints are declarative YAML files that define complete lab environments. They specify infrastructure components, participant configuration, and lifecycle settings.

Why Blueprints?

Traditional ApproachTeabar Blueprints
Manual setup scriptsDeclarative YAML
Hours of preparationMinutes to deploy
Inconsistent environmentsReproducible every time
Hard to shareVersion control friendly
Complex cleanupAutomatic TTL

Blueprint Structure

Every blueprint has three main sections:

apiVersion: teabar.dev/v1
kind: Blueprint
metadata:
  name: my-environment
  description: What this environment provides

spec:
  # 1. Environment settings (TTL, provider, region)
  # 2. Components (GitLab, Kubernetes, databases, etc.)
  # 3. Participants (count, isolation, resources)

Quick Example

Here’s a minimal blueprint for a Kubernetes training environment:

apiVersion: teabar.dev/v1
kind: Blueprint
metadata:
  name: k8s-basics
  description: Basic Kubernetes cluster for training

spec:
  ttl: 4h
  provider: hetzner

  components:
    - name: cluster
      type: kubernetes
      version: '1.28'
      nodes:
        control: 1
        worker: 2

  participants:
    count: 10
    isolation: namespace

Deploy it with:

teactl env create -f blueprint.yaml --name my-training

Learn More

Resource Types

Blueprints can provision various infrastructure resources:

Community Blueprints

Browse and use community-contributed blueprints:

# List available community blueprints
teactl blueprint list --community

# Use a community blueprint directly
teactl env create --blueprint community/gitlab-cicd --name my-env

Popular community blueprints:

  • gitlab-cicd - GitLab with runners and CI/CD pipelines
  • kubernetes-workshop - Multi-node K8s with monitoring
  • argocd-gitops - ArgoCD with example applications
  • full-devops - Complete DevOps stack (GitLab + K8s + ArgoCD)
ende