Features

Sailwright's features share one goal: make machine setup something you run, not something you remember. Each section below names the exact commands involved — if you'd rather start from a problem than a feature, see Use Cases, or find your role on Who It's For.

Working with virtual machines normally means a different tool on every operating system — Tart here, Hyper-V there, QEMU somewhere else. Sailwright hides that behind one command vocabulary, whatever the backend underneath: build creates or refreshes the reusable VM image, create stands up the managed target, start/stop control its power state, provision runs the Ansible setup workflow against it, and destroy removes it again.

Use the list subcommand on any of these (sailwright build list, sailwright provision list, and so on) to see exactly what your current host supports, and --help on any command for its full flag set.

sailwright provision local applies your team's setup playbook to the machine you're sitting at instead of a managed VM — with --check for a dry run that shows what would change before anything does. It picks the right default inventory for your host OS automatically, and lets you override the playbook or inventory path directly on the command line.

On Windows, the wrapper takes extra care: it creates a temporary administrator account and a loopback-only WinRM listener (or a temporary SSH key when using --proto ssh), runs the playbook, then restores the previous state afterwards. Because these are real host changes, it asks for confirmation by default — pass --yes to skip the prompt once you trust the flow.

For security-conscious teams and Windows fleet admins, that detail is the point: no standing remote-management access is left behind.

A small YAML config (ansible-role-sources.yml) lets you build the Ansible role search path and default playbook from multiple sources: local directories you're actively developing, and Git repositories cloned and kept up to date automatically. Sources are layered in order, so private overrides can sit in front of the bundled public roles without forking anything.

Point a source stack at a specific playbook to make it the default entrypoint for sailwright provision local and VM provisioning, or keep the bundled example roles and playbooks as a fallback while you build out your own. This is how consultancies and multi-team organizations keep private customizations in front of a shared public base — versioned and reviewable, without forking.

Build a VM image once and share it through infrastructure you already run: finished build artifacts can be pushed to, and pulled from, any OCI (Docker-style) registry with sailwright push and sailwright pull, using the same target vocabulary as the VM workflow and a Docker-like image reference. Credentials come from your existing docker login session by default, with flags available for registry-specific username/password, access tokens, or custom CA certificates.

Pushed artifacts are ordinary OCI artifacts, so they're inspectable with standard tools like ORAS. Sailwright's own CI publishes completed Ubuntu build artifacts to GitHub Container Registry on every push to main.

Build state, deployment state, caches, and standalone runtime assets live outside the repository in an OS-appropriate app-data directory, while user-editable configuration lives in a separate, OS-appropriate config directory — both overridable with environment variables when the defaults don't fit your setup.

Running the standalone sailwright binary outside a Git checkout works the same way: on first run it extracts its bundled scripts, playbooks, and other runtime assets into the managed app-data directory and keeps that tree in sync on later runs.

See These Features Applied

Curious how these pieces fit together in practice? Browse Use Cases for real workflows, find your role on Who It's For, or dive into the documentation. Ready to try it? Releases are on GitHub — or get in touch with questions.