Blueprints

Um blueprint é uma receita declarativa em YAML para instalar e operar um serviço via SSH. Blueprints sustentam a camada de serviços: uma station registra services a partir de blueprints e os executa nas suas VMs.

Onde os blueprints ficam

Cada blueprint é uma pasta dentro de blueprints/, com um blueprint.yaml como entrypoint:

blueprints/
└── docker/
    ├── blueprint.yaml        # obrigatório
    └── scripts/              # sidecars shell opcionais
        └── install.sh

O catálogo é descoberto automaticamente — basta colocar a pasta e ela aparece ao registrar um service. Sem código, sem registro manual.

Duas formas

• Standalone — declara seus próprios roles[], cada um rodando nas suas VMs (ex.: docker, k3s).
• Hosted — declara host: { blueprint, role } e roda sobre outro service (ex.: argocd sobre k3s.server).

Exemplo

Um blueprint standalone mínimo:

name: docker
description: Container runtime (Docker CE)
version: 1.0.0
compatibility:
  os: [ubuntu-22-04, ubuntu-24-04, debian-12, debian-13]

roles:
  - name: main
    install:
      - name: install
        description: Install Docker CE
        script: scripts/install.sh
        verify:
          run: command -v docker >/dev/null 2>&1
    uninstall:
      - name: remove
        description: Remove Docker CE
        run: sudo apt-get remove -y docker-ce

Os steps rodam via SSH; cada verify os mantém idempotentes. Steps podem publish valores (secrets ou facts) para roles seguintes ou services hosted, e um bloco uninstall desfaz o serviço na ordem inversa. O templating resolve ${inputs.X}, ${secrets.X}, valores de peers e arquivos embutidos (${file:...}) por host em tempo de execução.

Como criar

A referência completa da DSL — todos os campos, todo o templating e verify / publish / rollback / uninstall — é mantida no repositório: docs/blueprint-dsl.md.

O repositório também traz uma skill de agente blueprint-dsl (.agents/skills/blueprint-dsl/), para que um assistente de IA crie blueprints com domínio completo da DSL.