This wiki covers the core ZEDEDA Cloud objects and workflows used to deploy and manage edge workloads. Each section explains what the object is, how to create it via ZEDUI, Terraform, and the API, and what happens on the edge node when the object is applied.

When setting up a project from scratch, create objects in this order to avoid missing-dependency errors:

1. Project (required first; everything else belongs to it)
2. Datastores (required before Images and Content Trees)
3. Images (required before App Bundles)
4. EVE-OS Images (assign to edge nodes before or after project creation)
5. Network Instances (required before App Instances; see network documentation)
6. Persistent Volumes / Content Trees (can be created in parallel with images)
7. Patch Envelopes (optional; add to App Bundle definition)
8. App Bundle (references images, volumes, networks, patch envelopes)
9. App Instance (deploys the bundle to a specific edge node)

  ZEDUI / Terraform / API
          |
          v
  ZEDEDA Cloud Controller
  (stores config, manages state,
   distributes to devices)
          |
          | HTTPS / mTLS
          | (device heartbeat every 60s by default)
          v
  EVE-OS on Edge Node
  (pulls config, downloads images
   from datastores, starts workloads
   via KVM or containerd)
          |
          v
  Running Workload
  (VM via KVM, or OCI container
   via containerd)

• Heartbeat: EVE-OS checks in with the controller on a regular interval (default 60s). Config changes are delivered on the next heartbeat, not pushed in real time.
• Measured Boot: EVE-OS uses TPM-based measured boot to record component state for remote attestation. This is not the same as secure boot (which blocks unsigned code).
• A/B Partitions: EVE-OS updates use a dual-partition scheme. Updates are written to the inactive partition and activated on reboot. The previous partition is retained as a fallback.
• Project Scoping: All ZEDEDA Cloud objects belong to a project. API tokens and user accounts are permissioned at the project level.