Skip to main content
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.
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.
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.
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

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.
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.
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.