Local DevOps Workbench
Evidence-based discovery → standard config you own.
Quick start · Features · Supported workflows · Documentation · CI · Contribute
LDW discovers your repository from evidence and records the setup you approve. Run it with
ldw up, the managed path, or export a Tiltfile or mise tasks that you own and can run without
LDW. Coordinate native processes, Docker Compose, DDEV, and Kubernetes; add isolated VMs,
observability, backups, and SSH deployment when you need them.
Keep your existing tools. LDW works with your package scripts, Makefile, Compose files, and DDEV configuration, adding a consistent lifecycle around them.
Public preview: Install from source. APIs may change before
v1.0.0.
The everyday workflow
cd /path/to/your/project
ldw init . # Discover and review
ldw plan # Preview the run
ldw up # Start the accepted mode
# In another terminal:
ldw status # Health and endpoints
ldw logs api # Logs for your api resource
ldw down # Stop and preserve data
Review once, run consistently. Every ldw up uses the accepted manifest and lock;
it never rescans the repository or calls AI.
Or export and leave
ldw export tiltfile # A standalone Tiltfile for `tilt up`
ldw export mise # mise tasks for `mise run dev`
ldw export tiltfile --check # Fail CI when the export is stale or edited
Exported files come from the same accepted manifest and list what they cannot do without LDW. See Export and eject and Compared with other tools.
What you can do
| Capability | What it gives you |
|---|---|
| Discover an existing stack | Find package scripts, workspaces, Compose, DDEV, Helm, ports, and required environment variable names, with evidence for each proposed resource. |
| Use one daily workflow | Plan, start, inspect, log, test, and stop linked projects through the same CLI. Select another declared mode when you need it. |
| Run several projects | Check fixed-port conflicts and acquire project locks before startup, with ownership tracking and bounded rollback. |
| Keep integrations current | Review changes, detect drift, apply plans atomically, and repair, upgrade, or remove files with proven ownership. |
| Export standard config | Generate a Tiltfile or mise tasks from the accepted manifest, check them in CI, or eject them to the team. |
| Share a portable setup | Commit the manifest and lock for your team, or integrate locally without changing the repository. |
| Ask for optional AI analysis | Let Codex or Claude Code propose a setup for ambiguous repositories through a consent-based, restricted analysis workflow. |
Supported workflows
| Your project uses | LDW coordinates |
|---|---|
| Native tools | Existing package scripts, Make targets, and local application processes. |
| Docker Compose | Project-owned services, dependencies, logs, and container-retaining shutdown. |
| DDEV | The existing DDEV project and its service lifecycle. |
| Native + containers | Accepted infrastructure startup, provider health checks, then native applications. |
| Kubernetes / kind | Declared Helm charts, local images, namespaces, and resources in Workbench-owned kind contexts. |
| OrbStack VMs | Explicit machine creation, provisioning, deployment, health checks, and rollback on macOS. |
Select another declared mode with ldw up my-project:kubernetes.
Kubernetes setup and
VM operations are explicit; ldw up never creates a VM.
Quick start
1. Install LDW
Requirements: macOS or Linux, Git, uv, and your project's native tools. Python 3.12–3.14 is supported; the commands below install 3.12. Container workflows need Docker Desktop, Docker Engine, or a supported compatible Docker context.
git clone https://github.com/openplanr/ldw.git
cd ldw
uv python install 3.12
uv tool install --force --python 3.12 .
uv tool update-shell
export PATH="$HOME/.local/bin:$PATH"
ldw bootstrap --apply
ldw doctor
bootstrap --apply installs Workbench tooling; doctor checks prerequisites.
This install includes every first-party plugin: VMs, SSH deployment, failure labs,
observability, and coding-agent analysis. Install ./packages/ldw-core instead for the core
alone.
For a fresh Mac, follow the complete installation guide.
Optional: OrbStack VMs and Ansible-based labs
Local VMs require OrbStack on macOS. From the LDW checkout, install the extra dependencies:
uv tool install --force --python 3.12 '.[ansible]'
Then follow the VM guide.
2. Connect your project
cd /path/to/your/project
ldw init .
Review the detected resources, commands, ports, and managed files. Accepting saves the setup,
links the project, and validates it. Discovery uses no AI by default.
Use ldw init . --local-only to keep the integration entirely on your machine.
Try the Compose tutorial for a runnable frontend, API, PostgreSQL, and Redis example.
3. Start developing
ldw plan
ldw up
If Docker is stopped, use ldw runtime start or ldw up --start-runtime.
Add --wait to require resource readiness, or --no-ui for CLI-only startup.
With Tilt available, ldw up provides an attached resource UI.
Press Ctrl-C in the attached session or run ldw down to stop it. Normal shutdown preserves data
and retains Compose containers. Full lifecycle behavior.
Automating onboarding or choosing a project identity?
ldw init . --json returns a plan without applying it. Noninteractive plain ldw init leaves
the plan unapplied, prints the next command, and exits nonzero. Unresolved plans cannot be applied.
Use --project-id my-project for a stable identity; DDEV uses the accepted DDEV name.
See the integration reference for resolve/apply commands.
Go beyond startup
| When you need to… | Use |
|---|---|
| See metrics, logs, and traces | Local observability with Grafana, Prometheus, Loki, Tempo, and OpenTelemetry. |
| Protect and restore project data | Checksummed backups and guarded resets, with a mandatory snapshot before reset. |
| Rehearse a release in isolation | OrbStack VMs with verified artifacts, local tunnels, and health-gated releases. |
| Deploy to an existing server | SSH deployment to one Ubuntu LTS host, with pinned identity and health-gated rollback. Server provisioning, DNS, TLS, and public ingress stay external. |
| Practice recovering from failure | Bounded failure labs that verify a healthy baseline, inject a fault, and report recovery. |
| Prepare for offline work | Verified cache warming for supported tools, images, charts, and dependencies. |
| Add custom integrations | Declarative packs and trusted Python extensions for organization-specific behavior. |
How LDW keeps the setup predictable
- Discover repository facts and evidence.
- Review and save the manifest and lock atomically.
- Run the accepted setup with locks and port checks.
- Reconcile repository changes before updating the integration.
In team mode, commit these files:
.devops-workbench/
├── project.toml # Accepted resources, modes, and commands
└── workbench.lock # Integration ownership and hashes
Ignore machine overrides in .devops-workbench/project.local.toml. Operational state stays in
local user directories. Secrets stay in project-owned environment files or an external store;
manifests declare variable names only.
Use ldw integration diff and ldw review to review changes, then ldw resolve 1 and ldw apply.
ldw review shows what LDW will write; ldw plan shows how ldw up will start. LDW refuses to overwrite
drifted managed content and removes only artifacts it can prove it owns.
Follow the reconciliation guide to apply changes.
Optional AI, bounded authority
Request analysis during initialization with --agent codex, --agent claude, or --agent auto.
After per-project consent, eligible analyzers receive a restricted mirror of eligible tracked
files. Credentials, environment files, Git data, and ignored or untracked files are excluded.
Proposals must pass schema and evidence validation; agents have no direct infrastructure authority.
Codex requires a passing native sandbox self-test; Claude Code uses restricted file tools.
Unsupported environments fail closed. --agent none keeps onboarding deterministic.
ldw context --json supplies redacted, read-only operational facts for coding tools.
See the threat model.
Find your next step
| I want to… | Start here |
|---|---|
| Install on a fresh machine | New-Mac guide |
| Try a working example | Compose tutorial |
| Onboard my own repository | Add a project |
| Export a Tiltfile or mise tasks | Export and eject |
| Run several projects together | Multi-project guide |
| Look up a command or config field | CLI reference · Manifest reference |
| Understand the design | Architecture · Environment boundaries · Compared with other tools |
| Diagnose a problem | Troubleshooting · Support |
Browse the full documentation for all guides and references.
Contributing
LDW is licensed under Apache 2.0. Bug reports, documentation improvements, integration packs, and code contributions are welcome. Start with CONTRIBUTING.md and the Code of Conduct, or use GitHub Discussions for setup and design questions.
Report vulnerabilities through the security policy, and keep secrets and private project data out of public issues.
Metadata
Release files for local-devops-workbench 0.2.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| local_devops_workbench-0.2.1.tar.gz | 991.2 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| local_devops_workbench-0.2.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.0 MB
Release files / local_devops_workbench-0.2.1.tar.gz
| Download URL | local_devops_workbench-0.2.1.tar.gz |
|---|---|
| Size | 991.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
44d92b83d88100df550627ee629b6bfff479d68749f0acd82eae5fd944f0e1b3
|
|
BLAKE2b-256 checksum How to use checksums |
091fbee7c076b3320ae701296fa2168ce88101fcf0ff2f7f3b61d185972c66d0
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.
Transparency logRelease files / local_devops_workbench-0.2.1-py3-none-any.whl
| Download URL | local_devops_workbench-0.2.1-py3-none-any.whl |
|---|---|
| Size | 11.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
ee482dbd467f9b9b8145560cb0230c947bce3fa68eeb32893f4e93fc2df60086
|
|
BLAKE2b-256 checksum How to use checksums |
1f817ac8a9a16e1f19625601f965f430bf31a5738a3f9f52270ae05d05660e49
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.
Transparency logSecurity for local-devops-workbench 0.2.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for local_devops_workbench-0.2.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.