Files
ComfyUI_frontend/apps/website
nav-tej 7b1cc3498d feat(website): add /enterprise-msa page for the Enterprise Customer Agreement (#13483)
*PR Created by the Glary-Bot Agent*

---

Publishes the Comfy Enterprise Customer Agreement (MSA) as a browsable
web page at [`/enterprise-msa`](https://comfy.org/enterprise-msa) so
prospects can review the template before signing an Order Form.
Requested in the `#website-and-docs` thread to make it easier for
companies to view ahead of time and easier to share.

Uses the same `LegalContentSection` template that already serves
[`/affiliates/terms`](https://comfy.org/affiliates/terms), so the visual
language matches the existing legal pages and layout choices (sticky
TOC, active-section tracking, mobile collapsible TOC) are picked up for
free.

## Changes

- **New page** `apps/website/src/pages/enterprise-msa.astro` — mirrors
the `/affiliates/terms` pattern, English-only, with a preamble paragraph
identifying the parties above the TOC.
- **`enterprise-msa` i18n block** in `translations.ts` — drives 12
numbered sections (Definitions → Miscellaneous) plus `Exhibit A. Order
Form`, verbatim from the executed template dated May 22, 2026.
- **Route + locale invariance** — `enterpriseMsa: '/enterprise-msa'`
added to `baseRoutes` and to `LOCALE_INVARIANT_ROUTE_KEYS`, so localized
variants are not served without a legal review of the translation.
Consistent with the existing `termsOfService` / `affiliateTerms`
convention documented in `config/routes.ts`.
- **Footer discovery** — `Enterprise MSA` link added to the `Company`
column of `SiteFooter.vue`, between `Terms of Service` and `Privacy
Policy`. This makes the MSA reachable from the `/cloud/enterprise` page
(and site-wide) with no changes to the enterprise page itself.
- **Test coverage** — new `enterpriseMsaSections.test.ts` guards section
IDs, numeric title pattern, page-chrome keys, and the locale-invariant
route so a future refactor of `LOCALE_INVARIANT_ROUTE_KEYS` cannot
silently start serving an unreviewed translation.

## Verification

- `pnpm test:unit` — 162/162 pass (17 files, 7 new tests)
- `pnpm typecheck` — 0 errors, 0 warnings on changed files (pre-existing
hints untouched)
- `pnpm build` — 498 pages built, `/enterprise-msa/index.html` (80 KB)
contains all 12 sections + Exhibit A
- `oxlint` + `oxfmt` clean on all changed files
- Manual QA via `pnpm preview` at 1440×900 desktop and 390×844 mobile
(responsive layout inherits from `LegalContentSection`, verified
visually) — desktop screenshots attached

## Notes for review

- The MSA copy is a verbatim reproduction of the executed `.docx`
template shared in Slack. If Legal wants edits, they can happen inline
in the `enterprise-msa.*` i18n block — no template restructuring needed.
- The effective date is hard-coded to `May 22, 2026` (matches the
template file name `GP 5.22.26`); update `enterprise-msa.effective-date`
when Legal ships a new template.
- The page intentionally does NOT set `noindex` — the MSA is a
customer-facing document that should be discoverable via search,
matching the user's stated goal of "easier for companies to view ahead
of time."

cc @michael-poganski — requested by James in the Slack thread for
approval to ship.

## Screenshots

![Enterprise MSA page hero at 1440x900: heading, effective date, parties
paragraph](https://pub-1fd11710d4c8405b948c9edc4287a3f2.r2.dev/sessions/2ee32139e0f46eeeb710c64932b4a359aaac84c62427b8bf4e4b6b599ee421bf/pr-images/1783448568340-98d4a75f-f626-438c-a8a0-1650a6baec7e.png)

![Enterprise MSA sticky TOC with Definitions section active, showing
bolded defined
terms](https://pub-1fd11710d4c8405b948c9edc4287a3f2.r2.dev/sessions/2ee32139e0f46eeeb710c64932b4a359aaac84c62427b8bf4e4b6b599ee421bf/pr-images/1783448568702-5c5d44b7-a39d-4958-a34d-fc2201cea7cb.png)

![Site footer showing the new Enterprise MSA link between Terms of
Service and Privacy
Policy](https://pub-1fd11710d4c8405b948c9edc4287a3f2.r2.dev/sessions/2ee32139e0f46eeeb710c64932b4a359aaac84c62427b8bf4e4b6b599ee421bf/pr-images/1783448569039-2a862202-85cc-4181-8af0-dc835d36d384.png)

![/cloud/enterprise page footer confirming the Enterprise MSA link is
visible from the enterprise
page](https://pub-1fd11710d4c8405b948c9edc4287a3f2.r2.dev/sessions/2ee32139e0f46eeeb710c64932b4a359aaac84c62427b8bf4e4b6b599ee421bf/pr-images/1783448569349-4386d7da-d7f4-4306-911d-723476db2ef2.png)

---------

Co-authored-by: Glary-Bot <glary-bot@users.noreply.github.com>
Co-authored-by: Michael B <michael@imick.io>
2026-07-08 17:40:59 +00:00
..
2026-06-09 20:14:03 +00:00

@comfyorg/website

Marketing/brand website built with Astro + Vue.

Ashby careers integration

/careers and /zh-CN/careers are rendered from Ashby's public job board API at build time. Data flow:

  1. src/pages/careers.astro awaits fetchRolesForBuild() during the Astro build.
  2. src/utils/ashby.ts calls GET https://api.ashbyhq.com/posting-api/job-board/{board}?includeCompensation=false, validates the envelope and each posting with Zod (src/utils/ashby.schema.ts), and maps to the domain type in src/data/roles.ts.
  3. On any failure (network, HTTP 4xx/5xx, envelope schema drift), the fetcher falls back to the committed JSON snapshot at src/data/ashby-roles.snapshot.json.
  4. src/utils/ashby.ci.ts emits GitHub Actions annotations and a $GITHUB_STEP_SUMMARY block so stale fetches are visible on green builds.

Required environment variables

Both are build-time only. Never prefix with PUBLIC_ (Astro would inline that into the client bundle).

Name Purpose Default (when unset)
WEBSITE_ASHBY_API_KEY Ashby API key (Basic auth) Build uses the committed snapshot
WEBSITE_ASHBY_JOB_BOARD_NAME Ashby public job board slug Build uses the committed snapshot

CI wiring (manual step — required)

This repo's .github/workflows/*.yaml changes cannot be pushed by a GitHub App. A maintainer must apply the following edits once:

.github/workflows/ci-website-build.yaml — pass the env into the build step and run the unit tests before it:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Setup frontend
        uses: ./.github/actions/setup-frontend

      - name: Run website unit tests
        run: pnpm --filter @comfyorg/website test:unit

      - name: Build website
        env:
          WEBSITE_ASHBY_API_KEY: ${{ secrets.WEBSITE_ASHBY_API_KEY }}
          WEBSITE_ASHBY_JOB_BOARD_NAME: ${{ vars.WEBSITE_ASHBY_JOB_BOARD_NAME || 'comfy-org' }}
        run: pnpm --filter @comfyorg/website build

      - name: Verify API key is not leaked into build output
        env:
          WEBSITE_ASHBY_API_KEY: ${{ secrets.WEBSITE_ASHBY_API_KEY }}
        run: |
          set +x
          if [ -z "${WEBSITE_ASHBY_API_KEY:-}" ]; then
            echo "Secret not available in this run; skipping leak check."
            exit 0
          fi
          # grep -rlF prints only file paths (never match content).
          MATCHES=$(grep -rlF --exclude-dir=node_modules --null \
            -e "$WEBSITE_ASHBY_API_KEY" apps/website/dist/ 2>/dev/null \
            | tr '\0' '\n' || true)
          if [ -n "$MATCHES" ]; then
            echo "::error title=Ashby API key leaked into build output::$MATCHES"
            exit 1
          fi

.github/workflows/ci-vercel-website-preview.yaml — add the two env vars to the top-level env: block so vercel build (both deploy-preview and deploy-production jobs) sees them:

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_WEBSITE_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_WEBSITE_PROJECT_ID }}
  VERCEL_TOKEN: ${{ secrets.VERCEL_WEBSITE_TOKEN }}
  VERCEL_SCOPE: comfyui
  WEBSITE_ASHBY_API_KEY: ${{ secrets.WEBSITE_ASHBY_API_KEY }}
  WEBSITE_ASHBY_JOB_BOARD_NAME: ${{ vars.WEBSITE_ASHBY_JOB_BOARD_NAME || 'comfy-org' }}

The secret must also be added to the Vercel project environment (vercel env add WEBSITE_ASHBY_API_KEY … or via the Vercel UI) so that vercel build in the preview job has access to it.

Fork PRs do not exercise this path: ci-vercel-website-preview.yaml receives an empty VERCEL_TOKEN for forks and fails at vercel pull before the build runs. Fork-safe PR interactions (the preview-URL comment) are handled by pr-vercel-website-preview.yaml.

Refreshing the snapshot

When a maintainer wants to update the committed snapshot (e.g. after onboarding/offboarding roles):

WEBSITE_ASHBY_API_KEY=WEBSITE_ASHBY_JOB_BOARD_NAME=comfy-org \
  pnpm --filter @comfyorg/website ashby:refresh-snapshot
git commit apps/website/src/data/ashby-roles.snapshot.json

The script exits non-zero on any non-fresh outcome so stale/empty snapshots can't be accidentally committed.

Cloud nodes integration

/cloud/supported-nodes (and /zh-CN/) lists custom-node packs preinstalled on Comfy Cloud, joined with public metadata from the ComfyUI Custom Node Registry (api.comfy.org). See src/pages/cloud/supported-nodes/AGENTS.md for the build pipeline, source-file map, and key invariants.

Build-time env var: WEBSITE_CLOUD_API_KEY (Cloud /api/object_info auth; the build falls back to the committed snapshot when unset). Must also be set in the Vercel project environment.

Production strictness

src/utils/cloudNodes.build.ts throws when fetchCloudNodesForBuild() returns { status: 'stale' } and process.env.VERCEL_ENV === 'production'. This prevents the production deploy from silently shipping an out-of-date snapshot when the Cloud API is unreachable or WEBSITE_CLOUD_API_KEY is missing. Preview and local builds continue to use the committed snapshot with a warning annotation.

Required GitHub Actions / Vercel secrets

Name Where Purpose
WEBSITE_CLOUD_API_KEY GitHub Actions repo secret + Vercel project env Auth for Cloud /api/object_info. Required for fresh production data.

The Release: Website workflow uses the GitHub Actions secret to regenerate apps/website/src/data/cloud-nodes.snapshot.json via .github/actions/cloud-nodes-pull/action.yaml. The Vercel environment value is read at build time by vercel build in ci-vercel-website-preview.yaml; the deploy-production job hard-fails before vercel build --prod if the secret is missing.

Refreshing the snapshot

To update the committed snapshot manually (e.g. after onboarding new packs to Comfy Cloud):

WEBSITE_CLOUD_API_KEY=\
  pnpm --filter @comfyorg/website cloud-nodes:refresh-snapshot
git commit apps/website/src/data/cloud-nodes.snapshot.json

The script exits non-zero on any non-fresh outcome so stale/empty snapshots can't be accidentally committed. Otherwise the Release: Website GitHub Actions workflow runs the same step on every manual dispatch and opens a PR with the refreshed snapshot.

HubSpot contact form

The contact page uses HubSpot's hosted form embed for the interest form:

<script
  src="https://js-na2.hsforms.net/forms/embed/developer/244637579.js"
  defer
></script>
<div
  class="hs-form-html"
  data-region="na2"
  data-form-id="94e05eab-1373-47f7-ab5e-d84f9e6aa262"
  data-portal-id="244637579"
></div>

The localized /zh-CN/contact page uses the same portal and script with form ID 6885750c-02ef-4aa2-ba0d-213be9cccf93.

This keeps submission handling, validation, anti-spam updates, and field configuration in HubSpot. The local implementation in src/components/contact/HubspotFormEmbed.vue only loads the hosted script and renders the documented embed container.

Scripts

  • pnpm dev — Astro dev server
  • pnpm build — production build to dist/
  • pnpm typecheckastro check
  • pnpm test:unit — Vitest unit tests
  • pnpm test:e2e — Playwright E2E tests (requires pnpm build first)
  • pnpm ashby:refresh-snapshot — refresh the committed careers snapshot
  • pnpm cloud-nodes:refresh-snapshot — refresh the committed cloud nodes snapshot