Repository navigation
Distribution: Docker MCP Catalog + Docker Hub — resolve the two blockers #822
Description
Backlog item. gflow-cli is not in Docker's MCP Registry and publishes no image to Docker Hub.
Both are wanted; neither is blocked on effort alone. Recording the actual blockers so whoever
picks this up does not rediscover them.
Context lives in docs/CONTAINER.md and docs/MARKETPLACES.md.
Where we are
A container image already exists and passes Glama's automated checks — build
01a0a3c1-c0a3-7462-bb4b-350a715ca63b, success in 31.2s, answering initialize and tools/list
with 15 tools, no browser and no credentials. Its build spec is tracked as
glama.json and guarded by tests/test_glama_build_spec.py.
That image is a health-check artefact, not a product. It starts the MCP server and enumerates
tools. It cannot generate anything.
Blocker 1 — Docker requires shareable test credentials
Docker's CONTRIBUTING.md
requires every submission to share working test credentials so their team can verify the server.
gflow authenticates against a personal Google account with Flow access, and generation bills
that account's Veo credits. Handing that over is not on.
Possible resolutions, in order of preference:
- A dedicated Google account with Flow access, used only for review, holding minimal credits.
Unknown whether Flow access can be provisioned on demand for a fresh account — that is the
thing to check first. - Ask Docker whether a server that needs the user's own account can be listed with a documented
"bring your own credentials" note instead. Worth one question before building anything.
Blocker 2 — the container cannot do the job (the real one)
Docker Desktop's MCP Toolkit runs catalog servers in containers and expects them to work.
gflow drives Flow through a real, headed Chrome session signed in to the user's Google account
(see docs/ARCHITECTURE.md). Google's auth and reCAPTCHA stack rejects
browsers advertising automation and most headless approaches.
So a catalog listing today would ship something that passes every check Docker can run and fails
the first thing a user asks of it. A green badge on a broken install is worse than no listing.
Making it real needs all of: Chromium in the image, a logged-in Chrome profile mounted in, a
display server for the headed session, and Google's anti-automation accepting a container-run
browser. The first three are work. The fourth is not ours to decide.
This is therefore downstream of the pure-HTTP transport tracked in docs/ARCHITECTURE.md
§ "What's blocked". If that ever lands, revisit this immediately — it is the unlock, and this
issue should be re-read the day it does.
Docker Hub is a separate, smaller question
Publishing an image to Docker Hub does not require Docker's catalog review, so blocker 1 does not
apply. Blocker 2 still does: whatever we push can introspect but not generate. If we publish, the
image description has to say that in its first line, or we are shipping a misleading artefact.
The maintainer has a Docker Hub account under the public ffroliva@gmail.com identity, so the
account side is not a blocker.
Definition of done
- Confirm whether a fresh Google account can get Flow access (settles blocker 1's best path)
- Ask Docker about a bring-your-own-credentials listing
- Decide Docker Hub: publish an explicitly-labelled introspection-only image, or hold
- If the HTTP transport lands, re-evaluate the whole issue
- Update
docs/CONTAINER.mdanddocs/MARKETPLACES.mdwith whatever is decided
Activity
ffroliva commentedon Sep 15, 2026
Correction: blocker 2 as written is not supported by evidence
I filed this issue asserting that "the container cannot generate". That claim came from
architecture, not from a run — and the run now contradicts the strong form of it.
What was actually measured today (Docker 28.3.0, image built with Chromium + Xvfb, $0, no
generation attempted):
gflow --versioninside the containergflow, version 0.75.0— runsversion 149.0.7827.55navigator.webdriverin a raw Playwright launchTrueTwo of my earlier statements were wrong for the same reason, and it is the reason
skills/spike/SKILL.mdexists:statement about that image, presented as a fact about containers generally.
navigator.webdriver = Truereading is about my probe, not about gflow. gflow'sown launch path already neutralises it —
--disable-blink-features=AutomationControlled(client.py:518) andObject.defineProperty(navigator,'webdriver',{get:()=>undefined})(client.py:759).My probe used neither.
Also worth recording: two failures during this spike were my harness, not the system —
xvfbinstalled withoutxauth, and a probe that bypassed the entrypoint so headed Chrome ranwith no
DISPLAYat all. Neither is evidence about anything.Revised state
Plumbing works. A container is a viable host for gflow. What remains genuinely unmeasured:
channel="chrome"(real Chrome, not bundled Chromium) can be installed and resolvedin the image.
browser_manager.pyresolves that channel to a single Linux path, and gflowrequires a real-Chrome profile for generation — so this is the next thing to test.
display attached; the compose file drafted for this has a
loginservice using the host Xsocket for exactly that.
the login arm is not run, this stays UNMEASURED rather than assumed.
cookie decryption — a portability limit, not anti-automation. Untested.
Blocker 1 (Docker requires shareable test credentials) is unaffected and remains the harder
one for the Docker MCP Catalog specifically.
The design under test is a
docker-compose.ymlwith a namedgflow-authvolume holding theChrome profile and
GFLOW_CLI_HOME, so the container stays disposable and the identity does not.That is a standard pattern for browser-automation containers, not a hack — my earlier framing of
it as one was also wrong.
docs(container): measure whether a container can host gflow, and corr…