> ## Documentation Index
> Fetch the complete documentation index at: https://docs.doppels.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Share Doppels Capability Run Results with Your Team

> Use Doppels Share to expose a Capability result to collaborators — only declared outputs are shared, never your credentials or local scripts.

Share lets you expose the result of a Capability run to collaborators without sending them your code, your credentials, or your environment. You run the Capability on your machine — with your own auth, your own VPN, your own `aws-cli` context — and Share publishes only the declared `returns` outputs for others to access. Your Recipe stays on your machine. The cloud never touches your steps.

## How sharing works

When you share a run, Doppels cloud acts as a coordination layer. It receives the declared outputs you authorize, issues a short-lived URL, and makes the result available to whoever you give the link to. Execution stays entirely on the host machine that ran the Capability. The cloud does not receive your Recipe YAML, your environment variables, your shell scripts, or any step output that isn't explicitly listed in `returns`.

This matters in practice: you can share the result of a production query, a generated report, or a freshly built artifact with a teammate, and they get exactly the data you declared — nothing more.

## Security model

Doppels is designed so that the boundaries around your credentials are structural, not policy-based.

<Note>
  **Your secrets never leave your machine.** Doppels inherits host authentication — `aws-cli`, `gcloud`, SSH keys, VPN connections, environment variables — exactly as they exist on your machine. None of that context is transmitted to the cloud, to collaborators, or anywhere else.
</Note>

The key guarantees:

* **Only declared `returns` are shared.** A Capability's `outputs` block defines exactly what a run can expose. `stdout`, `stderr`, intermediate files, and any step output not listed in `returns` are logs, not results — they stay local by default.
* **The Recipe is never exposed.** The YAML that defines your steps, shell scripts, and command invocations is not part of a Share. Collaborators see the result, not the implementation.
* **The cloud coordinates, not executes.** Every step runs on the host that invoked `doppels run`. The cloud receives only what you push to it after the run completes.

## The Share YAML model

A Share is a snapshot of a Capability contract and run results. It references the Capability by `capabilityRevision`, which pins the name, version, and SHA-256 digests of both the manifest and the transitive schema bundle. This means a Share is cryptographically tied to the exact Capability definition that produced it — you can't quietly change the contract and re-publish under the same revision.

```yaml theme={null}
capabilityRevision:
  name: hn-top-stories
  version: 1.0.0
  digest: sha256:<manifest-hash>
  schemaDigest: sha256:<schema-bundle-hash>
```

The `capabilityRevision` digest is computed by the CLI at run time. If you change the Capability YAML and try to share under the same version, it's an error — increment `metadata.version` to publish a new revision.

## Share a run

<Note>
  Share CLI commands are being finalized in an upcoming release. Check `doppels --help` for the most up-to-date subcommands once you have the CLI installed.
</Note>

When Share is available, the workflow will look something like this: you run your Capability locally (`doppels run capability/<name>`), then use a share command to publish the declared `returns` outputs to a short-lived URL. A teammate accesses that URL and sees exactly the data you declared — nothing more.

Until then, use the Git-native approach below for all team collaboration.

## Share YAML files directly

Because Capabilities and Recipes are plain YAML committed to Git, the simplest way to share a Capability with a teammate is to share the repository or the files themselves. They can clone or copy the YAML, run `doppels validate`, and execute the Capability on their own machine with their own credentials — no Share URL needed.

<Tip>
  For most team workflows, committing the YAML to a shared Git repository is the fastest path to reuse. A teammate clones your repo and runs `doppels run capability/<name>` locally. Share URLs are better suited for sharing specific run outputs — a generated CSV, a build artifact, a status snapshot — rather than the Capability itself.
</Tip>