How to declare plugs and slots

Create SDKs← Build an SDK|Configure a mount →

This guide shows how to declare plugs and slots in an SDK definition, so that an SDK can consume capabilities from other SDKs or expose its own to them. The examples cover the mount and tunnel interfaces; plugs and slots for the other supported interfaces follow the same shape.

Prerequisites

Before starting, ensure you have these requirements satisfied:

  • SDKcraft installed.

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

The declarations below go under top-level plugs: and slots: keys in sdkcraft.yaml.

Declare a mount plug

A mount plug consumes a directory that becomes available at a path inside the workshop. The required attribute is workshop-target, which must be an absolute path and may use $SDK to refer to the SDK installation directory:

sdkcraft.yaml
# ...

plugs:
  cache:
    interface: mount
    workshop-target: /home/workshop/.cache/cachekit

When a workshop installs the SDK, Workshop auto-connects this plug to system:mount, the slot the system SDK provides, and the plug receives a directory allocated on the host. Pairing it with another SDK’s slot instead requires an explicit connections: entry in the workshop definition; How to share content between SDKs covers that flow end to end. The mode, uid, gid, and read-only attributes are optional.

Declare a mount slot

A mount slot exposes a directory the SDK provides so that other SDKs can plug into it. The required attribute is workshop-source, which must be an absolute path inside the workshop and may use $SDK:

sdkcraft.yaml
# ...

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

This is for cross-SDK sharing within the workshop. A mount slot on a regular SDK is not wired on its own: until a workshop definition names it in a connections: entry, it stays declared and unconsumed. How to share content between SDKs covers that flow end to end.

Exposing a directory from the host is the responsibility of the system SDK; a regular SDK cannot declare a host-rooted mount slot.

Declare a tunnel slot

A tunnel slot exposes a network endpoint inside the workshop:

sdkcraft.yaml
# ...

slots:
  api:
    interface: tunnel
    endpoint: 127.0.0.1:8080

A tunnel slot is auto-connected only when the host side declares a tunnel plug that matches the slot by name or through a connections: entry in the workshop definition, and only when that plug’s endpoint is a loopback address or a Unix domain socket. Other pairings have to be connected manually with workshop connect. The endpoint syntax accepts shorthand forms, including bare port numbers and unix socket paths. See Tunnel interface for the full grammar.

See also

Explanation:

How-to guides:

Reference:

Tutorial: