← Volver al listado de tecnologías ← Índice de Goose

14. Deployment y best practices

Por: Artiko
goosedeploymenttanzuloggingbest-practices

14. Deployment y best practices

Cierre del tutorial. Acá juntamos todo: cómo desplegar Goose para un equipo o empresa, qué variables de entorno operativas conocer, cómo loguear y monitorear, y las prácticas que separan un setup que funciona de uno que escala.

Custom distributions (revisitado)

En el capítulo 9 introdujimos las custom distributions. Acá las usamos en serio.

Caso típico

Tu empresa quiere distribuir Goose a 200 developers con:

# distribution.yaml
name: empresa-goose
version: 2.5.0
base: goose-1.x.y

provider:
  default: acp
  locked: true
  acp:
    endpoint: https://agents.empresa.com/v1
    auth:
      type: bearer
      token_source: env:ACP_TOKEN

extensions:
  preinstalled:
    - empresa-postgres-mcp
    - empresa-jira-mcp
    - github
  allowlist_only: true

persistent_instructions: ./persistent-empresa.md

config_locked:
  - provider
  - acp.endpoint
  - extensions.allowlist

distribution:
  channel: stable
  update_url: https://goose-internal.empresa.com/releases

Build:

goose distribution build distribution.yaml
# Output: empresa-goose-2.5.0-{macos,linux,windows}.{dmg,deb,rpm,exe}

Distribución vía MDM, intranet o repo de paquetes interno. Los developers reciben Goose pre-configurado, sin necesidad de tocar nada.

VMware Tanzu Platform

Para deployments empresariales sobre Tanzu (VMware), Goose tiene una integración específica:

# tanzu-app.yaml
apiVersion: kontent.tanzu.vmware.com/v1alpha1
kind: Application
metadata:
  name: goose-internal
spec:
  source:
    image: registry.empresa.com/goose:2.5.0
  config:
    provider: acp
    acp_endpoint: https://agents.tanzu.empresa.com
  scaling:
    min: 2
    max: 10
  observability:
    logs: enabled
    metrics: enabled

Lo que hace:

Es el patrón si tu organización ya operates Tanzu y querés un Goose como servicio interno en lugar de instalación per-developer.

Environment variables completas

Tabla operativa de las variables que vas a tocar en CI/scripts/deployments:

Provider y modelo

VariableEjemploUso
GOOSE_PROVIDERclaude-codeOverride provider
GOOSE_MODELclaude-sonnet-4-5Override modelo
OPENAI_API_KEYsk-...Provider openai
OPENROUTER_API_KEYsk-or-...Vía openai con base_url
ANTHROPIC_API_KEYsk-ant-...Si requirido por provider
GOOGLE_API_KEYAIza...Gemini
ACP_TOKENbearer tokenACP auth

Comportamiento

VariableEjemploUso
GOOSE_LOG_LEVELdebugVerbosidad: trace, debug, info, warn, error
GOOSE_DISABLE_TELEMETRY1Apagar usage data
GOOSE_NO_AUTO_APPROVE1Forzar prompts aunque pase —auto-approve
GOOSE_NO_INTERACTIVE1No preguntar, fallar si falta info
GOOSE_SESSION_DIR~/.goose-sessionsDirectorio alternativo de sessions
GOOSE_CONFIG/path/to/config.yamlConfig alternativo
GOOSE_TIMEOUT300Timeout default en segundos

Paths

VariableDefault
GOOSE_HOME~/.config/goose (Linux) / ~/Library/Application Support/goose (macOS)
GOOSE_CACHE_DIR~/.cache/goose
GOOSE_DATA_DIR~/.local/share/goose

Network y proxy

VariableUso
HTTPS_PROXYProxy HTTPS
HTTP_PROXYProxy HTTP
NO_PROXYHosts a saltearse del proxy
GOOSE_USER_AGENTCustom user agent (auditoría)

CI-friendly

export GOOSE_LOG_LEVEL=info
export GOOSE_NO_INTERACTIVE=1
export GOOSE_TIMEOUT=600
export GOOSE_DISABLE_TELEMETRY=1
goose run pipeline-recipe.yaml --param ...

Logging system

Niveles

GOOSE_LOG_LEVEL=debug goose session
LevelQué loggea
traceCada packet de IPC, embeddings, etc. (mucho ruido)
debugTool calls, decisions, retries
infoDefault. Sesiones, config changes, errors
warnSolo problemas potenciales
errorSolo errores

Destinos

# config.yaml
logging:
  level: info
  destinations:
    - type: console
    - type: file
      path: ~/.local/share/goose/logs/goose.jsonl
      rotation:
        max_size: 100MB
        max_files: 5
    - type: syslog
      address: udp://logs.empresa.com:514
      facility: local6

Los logs en archivo son JSONL: una línea de JSON por entrada, fácil de grepear y feedear a un pipeline:

# Errores recientes
tail -f ~/.local/share/goose/logs/goose.jsonl | jq 'select(.level=="error")'

# Tool calls de la sesión actual
jq 'select(.event=="tool_call")' goose.jsonl

Métricas y usage data

Goose puede exponer métricas Prometheus en endpoints internos:

metrics:
  enabled: true
  bind: 127.0.0.1:9091
curl http://localhost:9091/metrics | grep goose
# goose_tokens_input_total{model="claude-sonnet-4-5"} 1.4e+06
# goose_tokens_output_total{model="claude-sonnet-4-5"} 2.1e+05
# goose_tool_calls_total{tool="read_file"} 4231
# goose_session_duration_seconds_sum 12483.4
# goose_errors_total{kind="rate_limit"} 12

Conectalo a tu Prometheus y armás dashboards de Grafana con cost/usage por developer/proyecto.

Telemetry opcional al proyecto

Por default, Goose envía datos anónimos al proyecto upstream (estadísticas de uso, no contenido de prompts). Apagás con:

export GOOSE_DISABLE_TELEMETRY=1

O a nivel config:

telemetry:
  enabled: false

En enterprise probablemente quieras deshabilitarlo.

Terminal integration

Shell helper

Goose ofrece un alias inteligente que toma context de tu shell:

# Una sola línea
goose ask "¿qué pasó con el último commit?"

# Goose ve tu PWD, git status, comandos recientes y responde

Cargás esto en tu .zshrc:

eval "$(goose shell-init zsh)"

Ahora goose ask (sin sesión) interpreta tu working directory y los últimos comandos del history para responder con contexto.

Para Ghostty / iTerm / Wezterm

Algunos terminals tienen plugins que integran Goose más profundo:

Verificá si tu terminal tiene plugin oficial.

Best practices acumuladas (recap)

1. Provider y modelo

2. Sesiones y context

3. Recipes y subagents

4. Seguridad

5. Cultura del equipo

Anti-patterns finales

”Te delego todo”

Goose hace cosas, no decide qué cosas hacer. Si entregás “decidí qué hacer” estás abandonando el rol crítico del developer: scope, prioridades y trade-offs. Esos siguen siendo humanos.

”El agente sabe el codebase”

No, el agente lee lo que vos le pones en context. Investigá tu repo y dirigí al agente; el resultado depende de qué le mostraste.

”Auto-approve total”

Inevitablemente algún día va a hacer algo que no querías. La pequeña fricción de aprobar manualmente es un seguro barato.

”Si no funciona, cambio modelo”

A veces sí, a veces no. Lo más común es que tu prompt o tu context engineering sean el problema. Un mejor modelo no compensa instrucciones malas.

Cierre del tutorial

Empezaste sin saber qué era Goose. Ahora podés:

Goose es una de las herramientas más completas para uso serio de agentes hoy. La diferencia entre un equipo que lo usa bien y uno que lo usa mal no es la herramienta: es la disciplina de iterar el harness, mantener recipes y respetar permisos.

Como pasó con git, con Docker, con Kubernetes: la herramienta es el medio; el oficio del equipo es el fin. Goose te da el medio. Lo que hagas con eso sigue siendo decisión vuestra.

Recursos para seguir

← Volver al listado de tecnologías ← Índice de Goose