Motivation
Consumers that use Playwright currently need to select a prebuilt Playwright image or manually coordinate several coupled inputs:
- the Python or Node Playwright package;
- the browser revision compatible with that package;
- native libraries required by the selected browser and base distribution;
- the installed browser location and runtime environment; and
- repeatable acquisition, caching, and offline materialization.
OmegaFlow exposed this gap while integrating its protected controlled-session controller. Its current draft uses mcr.microsoft.com/playwright/python:v1.61.0-noble, but that replaces the user-selected controller base merely to obtain a compatible browser runtime.
Reploy already carries related conformance machinery: .github/workflows/integration.yml downloads checksum-pinned Playwright fixtures, and the OmegaFlow controlled-session conformance profile uses a pinned browser controller base. This proves the need but is not yet a reusable blueprint capability.
Goal
Allow a Reploy application to request a reproducible Playwright runtime while retaining an ordinary compatible base image. Reploy should own the acquisition and materialization mechanics; the application should continue to own browser automation and its Playwright version constraint.
Candidate shapes
Evaluate the smallest public contract that satisfies the goal:
- Reusable package collection/profile: compose the Playwright binding, compatible browser payload, native packages, and runtime wiring from provider-owned package declarations.
- Dedicated
tool:playwright capability: add a Playwright-aware tool/provider that derives or validates the browser revision, resolves its closed artifacts, requests native dependencies, and exports the executable/runtime coordinates.
Prefer existing provider primitives if they can preserve the invariants below without application-specific scripts or a hidden image substitution. Use a dedicated capability if compatibility resolution and browser artifact ownership cannot be modeled safely as an ordinary package collection.
Required behavior
- Preserve the blueprint-selected base image rather than replacing it with a Playwright image.
- Support an explicitly selected browser, initially Chromium.
- Bind the browser revision to a compatible pinned Playwright binding version.
- Resolve and retain browser downloads as verified, cacheable provider artifacts.
- Materialize the final runtime without public network access.
- Install the required native libraries through the supported OS provider for accepted base families.
- Expose stable browser/runtime coordinates needed by the Playwright binding.
- Run the application as its configured non-root runtime identity.
- Fail early with actionable diagnostics for unsupported bindings, browser revisions, bases, platforms, or architectures.
- Include all provider inputs in build identity and cache invalidation.
An initial Linux amd64 implementation is sufficient if unsupported targets fail explicitly. Linux arm64 support can be added when the upstream browser/binding combination is available and proven.
Non-goals
- Browser actions, recording semantics, screenshots, or media compilation.
- OmegaFlow-specific controlled-session behavior.
- Arbitrary blueprint build hooks.
- Implicitly selecting or changing an application base image.
- Treating FFmpeg as part of Playwright unless a broader browser-media capability is deliberately designed.
Acceptance evidence
- A blueprint using a normal supported Python or Node base requests Playwright plus Chromium without selecting a Playwright image.
- Reploy resolves, builds, and then reuses the exact browser/runtime closure.
- The built environment launches Chromium through Playwright and produces a deterministic smoke artifact with runtime public networking denied.
- Repeated builds demonstrate cache reuse; incompatible versions and unsupported bases fail before deployment.
- Provider, blueprint, CLI/help, and Linux Docker integration tests cover the chosen public contract.
Motivation
Consumers that use Playwright currently need to select a prebuilt Playwright image or manually coordinate several coupled inputs:
OmegaFlow exposed this gap while integrating its protected controlled-session controller. Its current draft uses
mcr.microsoft.com/playwright/python:v1.61.0-noble, but that replaces the user-selected controller base merely to obtain a compatible browser runtime.Reploy already carries related conformance machinery:
.github/workflows/integration.ymldownloads checksum-pinned Playwright fixtures, and the OmegaFlow controlled-session conformance profile uses a pinned browser controller base. This proves the need but is not yet a reusable blueprint capability.Goal
Allow a Reploy application to request a reproducible Playwright runtime while retaining an ordinary compatible base image. Reploy should own the acquisition and materialization mechanics; the application should continue to own browser automation and its Playwright version constraint.
Candidate shapes
Evaluate the smallest public contract that satisfies the goal:
tool:playwrightcapability: add a Playwright-aware tool/provider that derives or validates the browser revision, resolves its closed artifacts, requests native dependencies, and exports the executable/runtime coordinates.Prefer existing provider primitives if they can preserve the invariants below without application-specific scripts or a hidden image substitution. Use a dedicated capability if compatibility resolution and browser artifact ownership cannot be modeled safely as an ordinary package collection.
Required behavior
An initial Linux
amd64implementation is sufficient if unsupported targets fail explicitly. Linuxarm64support can be added when the upstream browser/binding combination is available and proven.Non-goals
Acceptance evidence