A Project is the top-level organizational unit in ZEDEDA Cloud. Every asset you create — edge nodes, app instances, network instances, volumes, images, datastores, and policies — belongs to exactly one project. Projects define access control scope, policy inheritance, and the boundary for zero-touch deployments. When an edge node checks in, it receives configuration based on its assigned project.

Each project belongs to a single enterprise. An enterprise starts with one default empty project, and you can create as many additional projects as your segmentation requires.

The project's status rolls up from the status of its attached policies. If any policy is broken or incomplete, the project goes Inactive.

Policies are the key mechanism by which a project controls what happens on every edge node assigned to it. When a node joins a project, all active policies in that project are automatically applied to that node. When a node is removed from a project, policies delivered by that project are revoked.

Enforces remote attestation on every edge node in the project. When enabled:

• EVE-OS generates a PCR quote using the TPM at each attestation cycle
• The quote is sent to ZEDEDA Cloud, which compares PCR values against the registered baseline template for that node model
• If the values match, the controller releases the key to unseal the node's encrypted disk
• If the values do not match, the node is quarantined: apps are not started and config is withheld until the attestation issue is resolved

This uses measured boot (not secure boot). Measured boot records component state into TPM PCR registers for remote verification. It does not block unsigned code from running, but it does make tampering detectable.

To enable: check Enforce Edge Node Attestation in the project's Policies tab.

Automatically deploys one or more network instances to every edge node in the project. This eliminates the need to manually create the same network instance on every node.

Use cases:

• Ensure all nodes in a factory project have the same local switch network wired up before any apps land
• Pre-provision a management VLAN network instance on every node at onboarding time

How it works: select one or more pre-defined network instances from the dropdown. When a new node is added to the project, EVE-OS receives the network instance config and creates the instance automatically.

Automatically deploys a specified app instance to every edge node in the project. When a new node is added, the app is deployed without any manual step.

Key behaviors:

• The app is created as an app instance on every existing node in the project immediately
• Any new node added to the project receives the app at its first heartbeat
• If a node is moved to a different project, the app instance deployed by this policy is deleted from that node

Use cases:

• Ensure every node in a project runs a monitoring agent, VPN client, or security scanner
• Auto-deploy a standard telemetry container to all nodes in a region project

Controls remote access via the EdgeView feature. EdgeView lets operators open a terminal session to an edge node that is behind a firewall, without requiring a VPN.

Policy settings:

How it works:

• The policy is delivered to the node as part of the project config at next heartbeat
• To start a session, an operator requests a JWT token via ZEDEDA Cloud (time-limited, project-scoped)
• EVE-OS validates the JWT and opens an encrypted tunnel back to the ZEDEDA relay
• The operator connects using the EdgeView client container on their laptop

Note: The EdgeView policy must be enabled at the project level before any EdgeView session can be started on nodes in that project.

A device-level policy delivered to all nodes in the project. Controls node-level behaviors including:

• Flow logs: enable/disable collection of application network flow records (source/destination IP, port, ACL rule matched, packet/byte counters) for network instances in the project
• Metric collection intervals: how frequently EVE-OS samples CPU, memory, disk, and network metrics
• Debug settings: verbose logging levels, coredump enablement

Flow logs are disabled by default. Enable at the project level when you need network traffic visibility for compliance, debugging, or traffic analysis.

Available in Deployment type projects only. Automatically provisions a volume instance on every edge node in the project. Used to pre-stage persistent storage before apps land.

Defined as part of a project deployment (see Zero-Touch Deployments below).

ZTD is exclusive to Deployment type projects. It automates policy assignment and app instance deployment using a tag-matching system.

1. You define a deployment inside the project: a named, versioned bundle of policies and app configs
2. Each deployment has one or more deployment tags (key:value pairs)
3. Each edge node in the project also has tags
4. ZEDEDA Cloud continuously matches node tags to deployment tags; matching nodes receive that deployment's config and apps automatically
5. Changing a node's tags (or a deployment's tags) re-evaluates the match and applies or removes configs accordingly

This means you can:

• Maintain canary vs. production deployments: nodes tagged env:canary get one app version, nodes tagged env:production get another
• Roll back by reactivating a previous deployment version (ZEDEDA retains up to 100 deployment versions per project)
• Migrate node groups between deployments simply by changing node tags

Each deployment version can include:

zcli project create MY_PROJECT \
  --description="Workshop project" \
  --project-type=deployment \
  --deployment-name=MY_DEPLOYMENT-v1 \
  --deployment-tag=env:production \
  --app-inst-config=./app_config.json \
  --net-inst-config=./net_config.json \
  --vol-inst-config=./vol_config.json \
  --dev-policy-config=./dev_policy.json \
  --edgeview-config=./edgeview_policy.json

zcli project update-deployment MY_PROJECT \
  --deployment-id=<deployment-id> \
  --app-inst-config=./updated_app_config.json \
  --deployment-tag=env:production

zcli project update MY_PROJECT --config=flowlogs:true

Flow log records include: source and destination IP, source and destination port, ACL rule applied, and packet and byte counters per flow.

1. Navigate to Administration > Projects
2. Click the + icon
3. Details: enter Name, Title, Description; select Type (Deployment or Legacy) and Profile (Regular or Azure)
4. Deployments (Deployment type only): define deployment name and tags
5. Policies: configure Attestation, Network Instance Policy, Edge App Policy, EdgeView Policy, and Device Policy
6. Review and click Add

The Name field is permanent and unique within the enterprise. The Title can be changed later. The Type and Profile cannot be changed after creation.

resource "zedcloud_project" "workshop" {
  name        = "workshop-project"
  title       = "EVE-KVM Workshop Project"
  description = "Workshop project for EVE-OS and EVE-KVM workflows"
  type        = "DEPLOYMENT"

  # Attestation policy
  attestation_policy {
    enforce = true
  }

  # Edge App policy: auto-deploy a monitoring agent to all nodes
  app_policy {
    app_id = zedcloud_application.monitoring_agent.id
  }

  # EdgeView policy: allow dev and app access, 8-hour sessions
  edge_view_policy {
    edgeview_allow      = true
    max_expire_sec      = 28800
    max_instances       = 3
    dev                 = true
    app                 = true
    ext                 = false
  }

  tag {
    key   = "env"
    value = "workshop"
  }
}

POST /v1/projects
{
  "name": "workshop-project",
  "title": "EVE-KVM Workshop Project",
  "type": "PROJECT_TYPE_DEPLOYMENT",
  "attestationPolicy": {
    "enforceAttestation": true
  },
  "appPolicy": {
    "apps": [{ "id": "<app_bundle_id>" }]
  },
  "edgeviewPolicy": {
    "edgeviewAllow": true,
    "maxExpireSec": 28800,
    "maxInstances": 3,
    "dev": true,
    "app": true
  },
  "tags": { "env": "workshop" }
}

1. At the next heartbeat, EVE-OS receives the full project config bundle from the controller
2. Attestation policy: EVE-OS begins the TPM-based PCR quote cycle; attestation results are reported back before apps are started
3. Network Instance policy: EVE-OS creates the specified network instance(s) on the node (e.g., sets up a local switch bridge, wires it to the specified uplink port)
4. Edge App policy: EVE-OS receives the app bundle reference and starts the download and deployment pipeline (INIT > DOWNLOAD > INSTALL > RUNNING)
5. EdgeView policy: EVE-OS starts the EdgeView server-side container with the policy parameters; the node is now reachable via EdgeView sessions authenticated by JWT
6. Device policy / flow logs: EVE-OS configures its network monitoring subsystem; flow records begin accumulating and are reported to the controller on schedule

• Datastores
• EVE-OS Images
• Edge Apps
• Deploying from Marketplace