How to share content between SDKs

Two SDKs in the same workshop can share a directory through the mount interface, without routing the content through the host. Three pieces make up the flow: the providing SDK declares a mount slot, the consuming SDK declares a mount plug, and the workshop definition pairs the two with an explicit connections: entry.

Where the SDKs already declare the slot and the plug, only the pairing is left to graft on from the workshop definition, and How to add mounts to a workshop covers that with the shipped uv and jupyter pair. Building the slot and the plug into SDKs you author is the subject here. The examples use two synthesized SDKs: cachekit, which publishes a directory, and builder-sdk, which reads it.

Prerequisites

Before starting, ensure you have these requirements satisfied:

  • A working SDKcraft installation.

  • An sdkcraft.yaml you can edit for each side of the pair. If you don’t have one yet, Craft SDKs with SDKcraft walks through scaffolding an SDK with sdkcraft init.

  • A workshop you can launch and refresh on a host with Workshop installed.

Declare the mount slot

The providing SDK exposes a directory with a mount slot. cachekit publishes the directory it fills so that other SDKs can read it:

sdkcraft.yaml
# ...

slots:
  shared:
    interface: mount
    workshop-source: /home/workshop/cachekit-share

workshop-source is the only attribute a mount slot accepts, and How to declare plugs and slots covers its form. In particular, a slot cannot mark itself read-only: read-only is a plug attribute, so each consumer decides for itself whether it mounts the shared directory read-only.

The slot publishes the directory but never creates it. Make sure the SDK does, in a setup-base or setup-project hook, or through the parts that build it.

Declare the mount plug

The consuming SDK declares a mount plug naming the path where the shared directory appears. builder-sdk reads what cachekit publishes through a plug of its own:

sdkcraft.yaml
# ...

plugs:
  cache:
    interface: mount
    workshop-target: /home/workshop/builder-sdk-cache

Neither declaration names the other SDK, and the plug and the slot don’t have to share a name: builder-sdk calls its plug cache while cachekit calls its slot shared. Nothing pairs them until the workshop definition does.

Connect the SDKs

Listing both SDKs in a workshop is not enough to pair them. Left to the SDKs’ own rules, a mount plug auto-connects only to the slot the system SDK provides, so builder-sdk:cache connects to system:mount and receives a directory that Workshop allocates on the host, while cachekit:shared stays listed but unconsumed.

To pair them, name the plug and the slot in a top-level connections: entry:

workshop.yaml
name: dev
base: ubuntu@24.04
sdks:
  - name: cachekit
  - name: builder-sdk
connections:
  - plug: builder-sdk:cache
    slot: cachekit:shared

Both sides use the <SDK-NAME>:<NAME> form. While the pair is still unpublished, list the SDKs under sdks: with the try- or project- prefix that matches how you’re testing them. The prefix belongs in sdks: only: connections: always names the bare SDK, and a prefixed name there fails the launch as a reserved name.

Apply the change with workshop launch, or workshop refresh for a workshop that is already running:

$ workshop refresh

Note

A plug named in connections: is claimed by that entry. It no longer falls back to system:mount, so the host directory it used to receive is no longer mounted. Removing the entry and refreshing again returns the plug to that default.

Verify the connection

Confirm the pairing with workshop connections:

$ workshop connections dev

  INTERFACE  PLUG                   SLOT                 NOTES
  mount      dev/builder-sdk:cache  dev/cachekit:shared  -
  mount      dev/builder-sdk:state  dev/system:mount     -

On the first row, the SLOT column names dev/cachekit:shared rather than dev/system:mount, which confirms that builder-sdk reads from cachekit instead of from a host directory.

The second row shows the default the connections: entry overrides. builder-sdk:state is not named in the workshop definition, so it auto-connects to system:mount and receives a host directory. A dash in the PLUG column marks a slot that nothing consumes, which is what dev/cachekit:shared would show if the connections: entry were missing.

See also

Explanation:

How-to guides:

Reference:

Tutorial: