Dependencies

Everything a task requires from your environment is declared in a single list, with a type:

dependencies:
  source: "."                              # directory
  gcpCredential: ./keys/service-account.json     # file
  gitToken: ${env.OREN_GIT_TOKEN}          # sensitive value
  docker: true                             # access granted

The key is defined by the contract — you do not choose the name, only how to satisfy it. Each type determines how the value reaches the worker.

Form	You provide	The worker receives
directory	a host path	a mounted directory
file	a host path	a mounted file, mode 0400
string	a value or ${env.OREN_VAR}	an environment variable

Only the OREN_ prefix is visible

${env.X} sees only variables prefixed with OREN_. An ${env.GIT_TOKEN} does not resolve even if the variable exists in the environment — and the refusal is explicit since 0.5.2; before that the expression became text and the literal flowed on as if it were the value.

The prefix exists so a pipeline does not reach the whole environment of whoever runs it by accident.

| socket | true | a mounted socket |

Privilege

Each type carries a level, and that is what makes implementations comparable:

Type	Privilege
git-repository, directory	low
secret/git-token, secret/registry-credentials	medium
secret/gcp-service-account, secret/coolify-token	high
engine/docker	critical — socket access is equivalent to root on the host

Two tokens, two levels: a secret/git-token can be issued for one repository, so it is medium; a secret/coolify-token is scoped to a whole team and cannot be narrowed to the one application a step deploys, so it is high. The level describes what the credential can do, not what you intend to use it for.

A directory with mutable: true goes up one level: writing to your working directory costs more than reading it.

It is also created if it does not exist. A mutable directory is where the worker writes, and requiring it to already be there would break every first run in a clean copy — the .oren/artefatos of a CI that has just cloned does not exist, and git does not version empty directories.

A read directory that does not exist is the opposite: it is a wrong path, and Oren refuses, naming the step and the dependency. Creating it would silently mount an empty directory, and the step would fail later, far from the cause.

Credentials without registering anything

You do not need to store secrets anywhere new. If your organisation already uses Vault or Secret Manager, fetching the secret is just one more task:

- id: creds
  task: acme/fetch-vault-secrets@^1.0.0
  implementation: acme/fetch-vault-secrets-sh
  inputs:
    paths: [secret/data/gcp/prod]
  dependencies:
    vaultToken: ${env.OREN_VAULT_TOKEN}

- id: push
  task: techlite/push-docker-image@^1.0.0
  implementation: techlite/push-docker-image-skopeo
  dependencies:
    registryCredential: ${outputs['creds'].gcpServiceAccount}

Values marked as secret never appear in logs, never reach the lockfile and never touch the disk — the CLI materialises the content straight into the container.

The mark is contagious: an ordinary field that interpolates a secret value starts being treated as secret.