Test script: Deploy your app to your own domain

• Job slug: deploy-to-own-domain
• Version / status: v1 · frozen 2026-10-16 00:47 ET, before the first run. Checker: checks/run-checks-deploy.mjs at bwt-auth-starter commit f2b4b4f (branch deploy-base).
• Run order for v1: Vercel and Cloudflare Pages now. Netlify waits for written permission (no sign-up). Render is a later fallback.
• Rubric version: v1 (rubric)
• Author / date: Lando (CEO), 2026-10-16
• Conflict to disclose: BuildWithThis itself is hosted on Vercel (Hobby). The page must say so.

1. The job

You have a working app in a GitHub repo, a frontend plus a small Node API, like most AI-built apps once they leave the builder. You want it live on your own domain with HTTPS, without becoming a DNS expert. You’re done when https://<sub>.buildwiththis.xyz serves the app and its API with a valid certificate.

2. Candidates

Picked because they’re what vibe coders actually use. Bolt.new deploys to Netlify. v0 and Lovable’s export docs point to Vercel. Cloudflare is the common “free and fast” choice.

Scroll sideways for more columns →

3. Fixed inputs

• App: private repo pathakarchit/bwt-auth-starter, tag deploy-v1 (commit 9dc00d2, which is starter-v1 plus 8 lines):

  • The footer shows the build-time env VITE_APP_LABEL.
  • GET /api/health returns { ok, label: APP_LABEL, canarySet }.
  • APP_CANARY is a server-only value that must never reach the browser.

  No auth, so this tests deploying, not login. Notes are stored in a JSON file; on serverless hosts that may be read-only or temporary. Persistence is not scored here (that’s job #4).

• Env values (identical for every tool):

  • VITE_APP_LABEL=j03-<tool>
  • APP_LABEL=j03-<tool>-runtime
  • APP_CANARY=bwt-canary-<random 16 hex, per run, kept in .env.test>

• Domain: buildwiththis.xyz. DNS is at Spaceship, which only the user can log in to (passkey). Apex currently has A 76.76.21.21 (Vercel); no CAA records. Test hostnames:

  • Vercel: j03-vercel.buildwiththis.xyz
  • Cloudflare: j03-cf.buildwiththis.xyz
  • Netlify: j03-netlify.buildwiththis.xyz (Render fallback: j03-render.buildwiththis.xyz)

• Project names (checked free on 2026-10-16): Cloudflare bwt-j03 (→ bwt-j03.pages.dev), Netlify bwt-j03 (→ bwt-j03.netlify.app). Vercel: bwt-j03.

• Checker: checks/run-checks-deploy.mjs (added before the first run), using Node fetch, tls.connect for the certificate, and DNS over HTTPS (dns.google) for record visibility. No browser is needed except one screenshot of the page per tool.

4. Fixed task (the “prompt”)

The operator (agent) follows only the vendor’s official docs and logs each docs page used.

Deploy the app at tag deploy-v1 so that:
1. https://<host>.buildwiththis.xyz serves the frontend with a valid HTTPS certificate,
   and plain http:// redirects to https://.
2. The Node API runs on the same host: GET /api/health and GET /api/notes return 200 JSON.
3. VITE_APP_LABEL is applied at build time (visible in the footer) and APP_LABEL / APP_CANARY
   at runtime (health shows the label and canarySet=true). APP_CANARY must not appear in any
   file the browser downloads.
4. Pushing a new commit to the deploy branch redeploys automatically, or with one documented command.
5. You can roll back to the previous deployment.
Use the vendor's recommended way to deploy a Vite + Express app. If the API needs code changes
for this host, make the smallest change the docs show.

5. Run design (keeps user steps to one DNS batch)

Phase 0, setup (agent, before the user’s DNS step; time logged but not scored as “time to live”):

1. Create each project and deploy it to the vendor’s own URL (*.vercel.app, *.pages.dev, *.netlify.app).
2. Attach the custom hostname in each vendor’s dashboard, API or CLI first. Cloudflare’s docs warn that a CNAME without this step gives a 522 error, and attaching first also avoids dangling records.
3. Copy the exact DNS values each vendor asks for. Vercel gives a project-specific CNAME target, so it’s only known after this step. Record any extra TXT verification records requested.
4. Send the user one batch of records (section 5a).

Phase 1, user step (one time): the user adds the batch at Spaceship and replies “done” with the time. That is the only planned user step for all three tools. A second batch, if any vendor needs one, counts as a manual intervention for that vendor.

Phase 2, timed checks (agent): for each host, poll public DNS every 30 s until the record is visible, then measure time from DNS visible to valid HTTPS (T_dns→https). Then run all checks in section 7.

5a. The DNS batch (template; exact values are filled in after phase 0)

Scroll sideways for more columns →

TTL: Spaceship default. Don’t change the apex record or the MX records.

6. Follow-up rules and interventions

• Time cap: 90 active agent minutes per tool, not counting waiting on the user’s DNS step. DNS→HTTPS wait cap: 60 minutes after the record is visible.
• Allowed: vendor docs, CLI and API references, error messages.
• Not allowed: third-party tutorials, copying another tool’s branch.
• Manual interventions (C2):
  • Any action only the user can do, other than the one planned DNS batch: OAuth/GitHub-app installs, extra DNS records, dashboard-only clicks the agent can’t make, support tickets.
  • Any workaround not in the docs.
  • Sign-up for a missing account is setup, logged but not scored. It must use tools@ or [email protected].
• Deploy method: Git-connected deploys from a branch <tool> cut from deploy-v1, which is what readers do. If the vendor’s GitHub app isn’t installed, installing it is a user step and is logged. A CLI direct upload is allowed as a fallback and logged.

7. Pass/fail checks

Scroll sideways for more columns →

Metrics logged (not pass/fail):

• Phase-0 agent time to the vendor URL.
• DNS records requested (count and types) and user steps.
• T_dns→https.
• Lines changed (git diff --shortstat deploy-v1 -- . ':!package-lock.json') and vendor-specific files added.
• Docs pages used.
• Plan and cost.

8. Quality checklist (C5): docs and developer experience

Scroll sideways for more columns →

9. Security checklist (C7)

Scroll sideways for more columns →

10. Weights and tie-breaker

• Weights: default (C1 35 · C2 15 · C3 10 · C4 10 · C5 10 · C6 10 · C7 10).
• C1: core checks D1–D5 decide G1; C1 uses D1–D7.
• C2 anchors: user steps beyond the planned DNS batch plus docs-unanswered problems. 5 = 0–1 · 4 = 2–3 · 3 = 4–5 · 2 = 6–8 · 1 = more.
• C3 anchors: agent active time to all core checks passing (T = 90 min): 5 = ≤22 · 4 = ≤45 · 3 = ≤67 · 2 = ≤90 · 1 = cap hit. T_dns→https is reported separately.
• C4: 5 = free plan allows this use, with quota to spare · 4 = free, but the plan’s terms limit it (e.g. non-commercial only) · 2 = needs a paid plan.
• C6 (lock-in): 5 = no vendor-specific code (config file only), custom domain on free · 3 = API had to be rewritten for this host’s runtime · 1 = can’t leave without a rewrite.
• Tie-breaker: C2 (fewest user steps), then C3.

11. Cleanup

• Keep the projects and DNS records until the verdict is published plus 30 days.
• Then delete the projects first, then the CNAMEs, so no records are left dangling.
• Rotate APP_CANARY per run. It’s not a real secret.

Notes at freeze

1. Netlify permission: ask Netlify for written permission to benchmark and publish, from [email protected]. CEO decision 2026-10-16: Netlify waits for that permission and is not part of the first runs; Render is a later fallback.
2. Cloudflare product choice (v1 decision: Pages): Cloudflare now steers new projects to Workers. Workers custom domains and routes need the zone on Cloudflare, which we’re not doing until the planned DNS move. Follow the docs: if the recommended path needs nameservers on Cloudflare, log it as a finding and use Pages (CNAME to *.pages.dev, per Pages custom domains).
3. Vercel Hobby commercial-use limit: the run uses the existing Hobby team. The page must tell readers that a commercial app needs a paid plan, and we should decide whether buildwiththis.com itself needs to move off Hobby.