Hello World: Your First Workflow

Template source: cre-templates/starter-templates/hello-confidential-workflows (available in TypeScript and Go; the two implementations are behaviorally equivalent)

This is the smallest possible Confidential Workflow end to end, to be focused in the deploy part. It takes only 4 steps:

1. clone the repo
2. configure the environment variables
3. simulate
4. deploy

What This Workflow Does

This template is the minimal end-to-end shape of a Confidential Workflow, in four steps:

Concretely, on every CRON tick the workflow:

1. Hands the triggered request to an enclave (AWS Nitro, us-west-2) instead of executing the callback on Workflow DON nodes
2. Fetches the API_TOKEN secret — released by the Vault DON directly into the attested enclave
3. Calls the configured URL from inside the enclave with the secret in the Authorization header
4. Scores the confidential response against scoreThreshold → verdict APPROVE / REJECT
5. Crosses back to the DON with usingTheDons() and generates a signed report containing only the verdict and score — never the secret or the raw response body

The default endpoint is https://postman-echo.com/headers, which echoes request headers back — no signup or real API key needed. The workflow uses it to confirm the secret really was injected inside the enclave, reported as the boolean secret reached API: true rather than by ever logging the token.

Prepare the Workflow

Step 1: Clone the Templates Repo

We will use the TypeScript version.

git clone https://github.com/smartcontractkit/cre-templates.git
cd cre-templates/starter-templates/hello-confidential-workflows/hello-confidential-workflows-ts

Step 2: Install Dependencies

bun install --cwd ./my-workflow

Step 3: Set Up Environment Variables

Copy the example environment variables file to a new file named .env.

cp .env.example .env

In this basic example, using the default echo endpoint, the SECRET_API_TOKEN in .env can be any non-empty value, it doesn’t have to be a real API token.

The secrets.yaml at the project root maps the workflow-facing secret ID to that environment variable:

secretsNames:
    API_TOKEN:
        - SECRET_API_TOKEN

Note: In local simulation the CRE CLI injects secret values from .env according to this mapping. In a real deployment, the same secret ID (API_TOKEN) is resolved from the Vault DON instead — your workflow code doesn’t change. Deployment requires an extra step, which will also be covered later.

Simulate the Workflow

From the project root, start the simulation with the CRE CLI:

cre workflow simulate my-workflow --target staging-settings --non-interactive --trigger-index 0

You’ll see output similar to:

[SIMULATION] Running trigger trigger=cron-trigger@1.0.0
╭────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Trigger requested TEE Execution your trigger will run in one of the following Tees:                │
│     - AWS Nitro in us-west-2                                                                       │
│ The simulator is not a real TEE, and is meant to debug.                                            │
│ Do not use it for sensitive information.                                                           │
│ During real execution, user logs for this trigger will not be visible, and will not leave the TEE. │
│ They are presented in the simulator for debugging only.                                            │
╰────────────────────────────────────────────────────────────────────────────────────────────────────╯

[USER LOG] Enclave computation complete. verdict=REJECT

✓ Workflow Simulation Result:
"REJECT (score: 371, secret reached API: true)"

Reading the Output

• The simulator confirms the TEE constraint it resolved (AWS Nitro in us-west-2) and warns that it is not a real enclave — logs are shown for debugging only; in real execution they never leave the TEE.
• secret reached API: true means the Vault DON secret was fetched inside the enclave and arrived in the outbound request’s Authorization header.
• The verdict can flip between APPROVE and REJECT from run to run — the score derives from the live response body, and the echo endpoint includes a per-request trace ID.
• Lower scoreThreshold in my-workflow/config.staging.json to see APPROVE consistently.

Deploy the Workflow

Deployment takes 3 steps:

1. add the secret to the Vault DON
2. deploy
3. verify.

Private Registry

We’ll use the private registry (authorized by your CRE login session — no wallet, no gas).

The private registry is a Chainlink-hosted, offchain workflow registry.

All lifecycle operations (deploy, activate, pause, delete, update) are authorized by your CRE login session. You do not need to settup a wallet and there are no Ethereum Mainnet transactions and no gas fees for registry management.

Step 1: Add the Secret to the Vault DON (Before Deploying!)

A deployed workflow cannot read your local .env file — it fetches secrets from the Vault DON at runtime.

Before deploying, you must store API_TOKEN in the Vault DON. Execute the secret creation:

cre secrets create secrets.yaml --target staging-settings --secrets-auth=browser

Alert Make sure SECRET_API_TOKEN is set in your .env before executing the command above!

The CLI reads secrets.yaml, picks up the value from SECRET_API_TOKEN in .env, opens a browser window to authorize against the Vault DON with your CRE login session, and stores the secret. When it’s over, you’ll see:

Secret created: secret_id=API_TOKEN, owner=<your-organization-owner>, namespace=main

Verify it landed (only the ID is shown, never the value):

cre secrets list --target staging-settings --secrets-auth=browser

Note: In a Confidential Workflow, the Vault DON releases this secret only into an attested enclave at the moment getSecret() runs — it is never exposed in plaintext to Workflow DON nodes.

Step 2: Deploy

Verify if the configuration file workflow.yaml is already prepared for deployment.

Go to staging-settings, user-workflow.

Add or update deployment-registry: "private":

staging-settings:
  user-workflow:
    workflow-name: "hello-confidential-staging"
    deployment-registry: "private"

Then deploy from the project root:

cre workflow deploy my-workflow --target staging-settings

The CLI compiles the workflow to WASM, uploads the artifacts, and registers the workflow — active immediately:

Deploying Workflow: hello-confidential-staging
Compiling workflow...
✓ Workflow compiled successfully
Uploading files...
✓ Workflow registered in private registry

Details:
   Registry:         private
   Workflow Name:    hello-confidential-staging
   Workflow ID:      <workflow-id>
   Status:           Active
   Owner:            <your-organization-owner>

Step 3: Verify and Manage

Confirm it’s registered and active:

cre workflow list --registry private

You can also check it out on CRE workflows

Manage your workflow:

cre workflow pause my-workflow --target staging-settings     # pause
cre workflow activate my-workflow --target staging-settings  # resume
cre workflow delete my-workflow --target staging-settings    # permanently remove

The workflow now runs on its CRON schedule: every execution happens inside a real enclave, fetches API_TOKEN from the Vault DON, and produces a DON-signed report.

⚠️ Production reminder: the template logs Enclave computation complete. verdict=... inside the enclave for debugging. Remove every runtime.log() inside the TEE handler before any real deployment — anything logged from within a Confidential Workflow could leak the data the enclave is meant to protect.

Clean up

This workflow is intended solely to cover the deployment process, so it is best practice to remove it after learning the process:

cre workflow delete my-workflow --target staging-settings

Key Takeaways

What’s Next

You’ve just learned how to deploy a Confidential Workflow — now let´s go to the second use case: Automated Liquidation Protection.