feat: hatchet ui command

[mnafees]

Description

Add new hatchet ui subcommand to serve a full Hatchet frontend for self-hosted deployments with no frontend.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

Changes have been:

• Tested (unit, integration, or manually with steps specified)
• Linted and formatted
• Documented (where applicable)

---

🤖 AI Disclosure

• I acknowledge that an LLM was used in the creation of this Pull Request, in accordance with Hatchet's AI_POLICY.md.

• Details: [e.g. generating tests, writing docs]

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hatchet-docs	Ready	Preview, Comment	Jul 10, 2026 12:01pm

[Copilot]

Pull request overview

Adds a new hatchet ui CLI subcommand that serves an embedded Hatchet dashboard bundle locally and reverse-proxies API traffic to a selected Hatchet deployment/profile, targeting self-hosted/API-only installs that don’t ship a frontend.

Changes:

• Introduces hatchet ui command implementation (embedded SPA serving + /api reverse proxy + browser auto-open).
• Adds a build hook/script to compile the frontend and embed the output into the CLI binary for releases (plus Taskfile helpers).
• Documents the new CLI command in the docs navigation and reference pages.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
Taskfile.yaml	Adds tasks to build/embed the dashboard bundle into the CLI binary.
hack/build/embed-ui.sh	Builds the frontend app and copies dist/ into the CLI’s embedded assets directory.
frontend/docs/pages/reference/cli/ui.mdx	Adds reference documentation for hatchet ui.
frontend/docs/pages/reference/cli/index.mdx	Mentions hatchet ui in the CLI feature list.
frontend/docs/pages/reference/cli/_meta.js	Adds the new “Serving the Dashboard UI” page to the CLI docs nav.
cmd/hatchet-cli/cli/ui.go	Implements the hatchet ui command, local server, SPA handler, and reverse proxy.
cmd/hatchet-cli/cli/internal/ui/ui.go	Adds go:embed-backed accessors to bundled UI assets + Bundled() check.
cmd/hatchet-cli/cli/internal/ui/assets/.gitkeep	Placeholder to keep the embedded assets directory in a clean checkout.
cmd/hatchet-cli/cli/internal/ui/.gitignore	Ignores built UI assets while preserving .gitkeep.
cmd/hatchet-cli/.goreleaser.yml	Runs the embed hook before building CLI artifacts.
.github/workflows/cli-release.yaml	Installs Node + pnpm so the UI embed hook can run during CLI releases.

[github-actions]

⚠️ Optional test failure: The load-deadlock job failed on this PR (optimistic-scheduling=true). This check is non-mandatory and does not block merging, but may be worth investigating. View logs

[github-actions]

⚠️ Optional test failure: The load-deadlock job failed on this PR (optimistic-scheduling=false). This check is non-mandatory and does not block merging, but may be worth investigating. View logs

[github-actions]

⚠️ Optional test failure: The load-deadlock job failed on this PR (optimistic-scheduling=true). This check is non-mandatory and does not block merging, but may be worth investigating. View logs

[github-actions]

⚠️ Optional test failure: The load-deadlock job failed on this PR (optimistic-scheduling=true). This check is non-mandatory and does not block merging, but may be worth investigating. View logs

[abelanger5]

How does the UI "know" which tenant / tenant memberships to render? It seems like this would only work in no-auth mode, otherwise I can't see how this would work without modifying frontend code.

[abelanger5]

I worry about this, users running hatchet ui will be opening a port with full access to their target tenant. There are lots of network misconfigurations where this would be particularly bad, for example Docker Desktop for a while had an issue where ports would be discoverable if you were bound to a network. Same with VPNs like Tailscale, lots of (mis)configurations would allow for remote access to this port.

I wonder if we should require some form of auth to the /api/ proxy which we control from the CLI process. Again, this would require some frontend changes to pass some kind of token through (perhaps can hook into the exchange token mechanism).