[LFX Mentorship 2026 - Project Idea] Docker Desktop Extension

[mathieu-benoit]

Potential idea for an LFX project, to refine.

It would be great to have a Docker extension in Docker Desktop for Score:

• Docs: https://docs.docker.com/extensions/
• Easy to implement: https://docs.docker.com/extensions/extensions-sdk/build/frontend-extension-tutorial/
• Marketplace for inspiration: https://hub.docker.com/search?q=&type=extension
• Example with Microcks: https://github.com/microcks/microcks-docker-desktop-extension

We need to refine what could be the UI and the features, roughtly at this stage:

• Opening a folder where .score-compose and .score-k8s and score.yaml files are?
• Supporting both score-compose and score-k8s? score-helm too?
• Showing Score file?
• Showing info in state files?
• Showing provisioners score-* provisioners list?
• Showing resources score-* resources list?
• Showing running containers and hyperlink to the "Containers" tab of Docker Desktop?
• ...

Anything top mind that we could have here? Feel free to help refining this idea.

[ShantKhatri]

Hi @mathieu-benoit, I have done some research, interacted with environment and have few additions:

score-compose only for v1 Hard agree. Each implementation has its own state quirks and a premature abstraction over all three usually fits none of them well.

Monaco + score-v1b1.json The schema is already published in the spec repo, wiring it into Monaco's setDiagnosticsOptions is almost a one-liner. One open question: does saving auto-trigger generate, or is that manual? I'd go manual with an unsaved-changes indicator to avoid surprise regenerations.

Provisioners + Resources linkage The state file already has enough to link resource uid -> provisioner -> outputs. One joined panel beats two separate list views, and it's the natural place to surface outputs with secret masking.

Run panel This is what makes it a workflow tool vs a status pane. ddClient.extension.host.cli.exec() supports streaming stdout so it's not much work. Worth noting: up/down would talk to docker compose directly since score's job ends at generate.

Bundled binary Same call as Microcks. Assuming PATH means it only works for people who already have Score, which kills the discoverability angle. A versioned download in the Dockerfile build step keeps it manageable without vendoring.

My MVP cut: Monaco editor + run panel + resource outputs panel + bundled binary. Graph view and intent-vs-reality diff are high value but can follow once the core loop works. Happy to help scope if useful.

[Siddhartha-singh01]

Hi @mathieu-benoit ,

I have been following this project and this particular issue for the last couple of weeks now. Went through the Docker Extensions SDK documentation, studied the Microcks extension as a reference, explored how score-compose manages state and provisioners internally, and kept jotting down notes along the way. After sitting with the idea for a while and thinking through the different angles, here is where I have landed.

On scoping to score-compose only for v1

This makes the most sense to me. Each Score implementation carries its own state management semantics, provisioner loading behaviour, and output format. Trying to build a unified abstraction across score-compose, score-k8s, and score-helm in the first iteration would spread the effort thin without delivering a focused experience. Since the user is already inside Docker Desktop and working in a container-first local development workflow, score-compose is the natural and most coherent starting point. Support for other implementations can follow once the core experience is stable.

Monaco Editor with schema validation

The score-v1b1.json schema is already published in the spec repository. Integrating it into Monaco through the monaco-yaml language service would give us autocomplete and real-time validation with very little wiring. One design question that I kept going back and forth on is whether saving the file should auto-trigger generate or remain a manual action. After thinking about it more carefully, I believe a manual trigger with a visual dirty-state indicator is the better path. Auto-generating on every save risks unexpected container restarts during active editing, which creates more friction than it removes. Keeping the user explicitly in control of when generation happens feels like the right default.

Provisioners and resources as a unified panel

The .score-compose/state.yaml file already captures the full dependency graph from resource UID to provisioner to outputs. We can surface this by calling score-compose resources list and score-compose resources get-outputs through the Extensions SDK host CLI execution API and rendering it as a single joined table. Secret masking on outputs with a reveal toggle is important here since provisioner outputs frequently contain generated credentials. I kept debating whether to split this into two separate panels but concluded that one combined view is significantly more useful. The relationship between a resource and its provisioner is the information the developer actually needs, and separating them would break that context.

Run panel

This is the piece that turns the extension from a passive viewer into a genuine workflow tool. The panel should cover the full inner loop: init, generate, up, and down. The Extensions SDK supports streaming stdout through ddClient.extension.host.cli.exec with the stream option, which means we can provide real-time terminal output during generation and container startup. After running up, showing container status with navigation links to Docker Desktop's Containers tab would close the feedback loop cleanly and keep the developer inside a single interface.

Bundled binary

Assuming score-compose is already available on the user's PATH limits discoverability for anyone encountering Score for the first time through this extension. A versioned download during the Dockerfile build step, with platform-specific binaries declared in metadata.json under host.binaries for darwin, linux, and windows, keeps the distribution self-contained. This follows the same pattern Microcks uses and avoids the need for vendoring.

How I would phase this

After going through everything, here is the phasing that makes the most sense to me.

Phase 1 as the core MVP would include the Monaco editor with score-v1b1.json schema validation, a run panel supporting init, generate, up, and down with streaming output, a resource outputs panel with secret masking, and a bundled score-compose binary for all platforms.

Phase 2 for polish would add container status with navigation links to the Docker Desktop Containers tab, a provisioner list showing installed provisioners and their supported resource types, and inline error diagnostics from generate failures surfaced directly in the editor.

Phase 3 as a longer-term roadmap could cover dependency graph visualization showing the resource to provisioner to container relationship as a directed graph, an intent versus reality diff comparing what score.yaml declares against what is actually running, and multi-workload support for projects with multiple score files.

A couple of smaller things I noted down along the way that could add value: shipping a small set of example score.yaml templates as quick-start options to help with onboarding, and a startup version check comparing the bundled binary against the latest GitHub release to keep users current.

Would be glad to help refine the scope further or contribute to any of these areas.