# Runtime behavior **Workshop**’s system components work together to transform a workshop definition into a running container, following a set of dynamic processes and workflows that drive workshop operations. #### NOTE For a general description of these components, see [System components](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-system-components). ## Workshop launch process The workshop launch process coordinates the [workshopd daemon](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-daemon), [LXD backend](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-lxd-backend), [state management](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-state-database), [interface policy](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-interface-system), and [ZFS storage](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-zfs-storage) subsystems, all detailed in the previous section. The launch sequence begins with workshop YAML validation and normalization. The LXD container is then created from a base image. The [system SDK](https://ubuntu.com/workshop/docs//explanation/sdks/concepts.md#exp-system-sdk) is installed first to provide the core integration layer with host system resources. Regular SDKs are installed sequentially. SDK-specific [setup hooks](https://ubuntu.com/workshop/docs//explanation/sdks/concepts.md#exp-sdk-hooks) are executed during this phase. Workshop creates a lightweight ZFS clone after each SDK installation to enable efficient updates and rollbacks. Interface validation performs compatibility checking and policy enforcement. Connection establishment handles device attachment and resource binding. The container is then started and health checks are performed to complete the launch. - Launch operations create new workshops from scratch by creating new LXD containers and projects as needed, downloading and caching base images as required, installing all SDKs with complete hook execution, and establishing all interface connections. - Refresh operations update existing workshops by preserving LXD container identity and networking, restoring to base snapshot before applying changes, skipping unchanged SDKs using snapshot comparison, running save-state and restore-state hooks for SDK data persistence, and updating only modified interface connections. Workshop status transitions follow a predictable lifecycle: - *Off* → *Pending*: Workshop creation is initiated by user request - *Pending* → *Waiting*: Launch encounters errors requiring manual intervention - *Pending* → *Stopped*: Launch succeeds but the container remains stopped - *Stopped* → *Ready*: Container starts successfully and becomes available for use These changes are tracked in the state management system and can be monitored through the API. #### NOTE For a complete reference guide on status transitions, see [Workshop status diagrams](https://ubuntu.com/workshop/docs//reference/workshop-status.md#ref-workshop-status). ## Container layout Container runtime setup builds on the [LXD backend](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-lxd-backend) foundation with runtime-specific configuration applied during workshop launch. Key directories inside the container include: - The root file system as a ZFS dataset. - The `/project/` mount to provide transparent access to project files on the host. - The `/var/lib/workshop/` directory where workshop state volume and SDK volumes are mounted. The [interface system](https://ubuntu.com/workshop/docs//explanation/architecture/components.md#exp-arch-interface-system) provisions different resources within containers: - Mount interfaces appear as regular directories. - Proxy devices handle port forwarding and services such as the SSH agent. - GPU, audio, and camera devices are passed through to the workshop with proper permissions and access controls. ## Diagrams Workshop launch flow: