Use case · Temporal
Temporal workflows with an explicit management boundary
Sysaro inventories Temporal, probes readiness and builds a typed PostgreSQL deployment profile without rewriting arbitrary existing installations.
Verified against public version: 0.20.02026-09-15Factual boundary · roadmap is not presented as shipped
Temporal currently has inventory, lifecycle/readiness and a typed PostgreSQL deployment preview. Destructive apply is intentionally reserved for a canonical Sysaro-managed OCI deployment so existing systemd/container setups are not guessed or overwritten.
Workflow stack dependencies
1
PostgreSQL 18
persistence + visibility databases
2
Temporal Server
frontend readiness on managed local target
3
Observability
OTel/Prometheus/Grafana/Loki/Tempo as independent managed services
4
OCI boundary
future canonical deployment with owned volumes/secrets
What is safe today
| Area | Current boundary |
|---|---|
| Inventory | Version/backend/target visibility |
| Readiness | Fixed local TCP probe; no client-controlled network target |
| Configuration | Typed PostgreSQL deployment profile preview |
| Lifecycle | Backend-aware start/stop/restart for allowlisted systemd/OCI targets |
Why apply is constrained
Temporal is deployed in several materially different ways. Sysaro does not assume an existing temporal.service uses a specific environment/config contract.
Full apply becomes transactional only where Sysaro owns the image, volumes, secret wiring and rollback path.