Blueprint Resources
Resources are the infrastructure building blocks you provision in a blueprint. Teabar supports a wide variety of resource types, from Kubernetes clusters and VMs to Helm releases and DNS entries.
Resource Types
Kubernetes Clusters
Virtual Machines
Helm Releases
Kubernetes Manifests
DNS Entries
Secrets
Resources Section Overview
All resources are defined under spec.resources in your blueprint:
apiVersion: teabar.dev/v1
kind: Blueprint
metadata:
name: my-environment
spec:
resources:
# Kubernetes clusters
clusters:
- name: main
provider: hetzner
type: talos
# ...
# Virtual machines
vms:
- name: dev-server
provider: hetzner
# ...
# Helm releases
helm:
- name: gitlab
cluster: main
chart: gitlab/gitlab
# ...
# Kubernetes manifests
manifests:
- name: config
cluster: main
template: |
# YAML manifest here
# DNS entries
dns:
- name: app
type: A
# ...
# Secrets
secrets:
- name: api-key
type: generated
# ... Resource Dependencies
Resources can reference each other using template expressions:
spec:
resources:
clusters:
- name: main
provider: hetzner
type: talos
nodes:
workers: 3
helm:
- name: ingress
cluster: main # Reference cluster by name
chart: ingress-nginx/ingress-nginx
dns:
- name: app
type: A
# Reference the cluster's ingress IP
target: "{{ .Resources.clusters.main.ingress_ip }}" Teabar automatically resolves dependencies and provisions resources in the correct order.
Common Patterns
Per-Participant Resources
Use the count field with the participant index to create resources for each participant:
spec:
variables:
- name: participant_count
type: integer
default: 10
resources:
vms:
- name: "workstation-{{ .Index }}"
count: "{{ .Variables.participant_count }}"
provider: hetzner
type: cx21
image: ubuntu-22.04 This creates workstation-0, workstation-1, …, workstation-9 VMs.
Conditional Resources
Enable or disable resources based on variables:
spec:
variables:
- name: enable_monitoring
type: boolean
default: false
resources:
helm:
- name: prometheus
cluster: main
chart: prometheus-community/kube-prometheus-stack
enabled: "{{ .Variables.enable_monitoring }}" Shared vs. Isolated Resources
Some resources are shared across participants, while others are created per-participant:
spec:
resources:
# Shared: One GitLab instance for all participants
helm:
- name: gitlab
cluster: main
namespace: gitlab
chart: gitlab/gitlab
# Isolated: One namespace per participant
manifests:
- name: participant-ns
cluster: main
count: "{{ .Variables.participant_count }}"
template: |
apiVersion: v1
kind: Namespace
metadata:
name: participant-{{ .Index }} Resource Lifecycle
Resources follow the environment lifecycle:
- Creation - Resources are provisioned when the environment starts
- Updates - Some resources can be updated in-place; others require recreation
- Checkpoints - Resource state can be captured for quick restoration
- Destruction - Resources are cleaned up when the environment is destroyed or expires
Tip
Provider Support
Different resource types support different providers:
| Resource Type | Hetzner | AWS | Azure |
|---|---|---|---|
| Clusters | Talos, K3s | EKS, Kubeadm | AKS, Kubeadm |
| VMs | Cloud VMs | EC2 | Azure VMs |
| DNS | Hetzner DNS | Route 53 | Azure DNS |
| Secrets | Generated, Vault | Generated, Secrets Manager, Vault | Generated, Key Vault, Vault |