Workspaces model per-user development sandboxes on a shared host. They compose ordinary HostKit resources with naming, paths, network policy, previews, and an optional workspace agent.
use HostKit.DSL, providers: [HostKit.Providers.Caddy]
project :dev_host do
roots data: "/srv/workspaces", state: "/var/lib/workspaces", config: "/etc/workspaces"
prefixes user: "ws-", unit: "ws-"
tenant :alice, quota: [memory: "4G"] do
agent port: 4173
end
workspace :blog, owner: :alice do
service :preview do
directory root_path(:data), mode: :private_dir
daemon unit_name() do
service_user service_user()
working_directory root_path(:data)
exec_start ["/usr/bin/env", "mix", "phx.server"]
sandbox :vibe_dev
listen :http, port: 4000, on: :loopback
end
preview :http, port: 4000, domain: "alice-blog.dev.example.com"
inside do
monitor :mix, task: "test", every: "5m"
monitor :git, clean: true
end
end
end
endUseful pieces:
tenantdeclares an owner and can install a workspace agent.workspacescopes paths, identity names, and unit names for sandboxed work.agent/workspace_agentdeclare the agent service boundary.previewexpands to listener/provider metadata for preview routes.insideandinside_monitordescribe checks intended to run inside the sandbox.- Ordinary HostKit DSL still works inside a workspace:
directory,daemon,sandbox,listen,monitor, and provider resources.
Workspaces are intentionally inspectable. They are not a separate runtime system hidden behind opaque state; they compile to HostKit services/resources plus metadata.