Repository navigation
mcpx docs: a custom subdomain for the site (DNS, CNAME, HTTPS) #1943
Description
Relocated from dezren39/darwin-nix#119 on 2026-10-28 (placement audit): mcpx's single source lives in developing-today/code (pkgs/mcpx); re-home tracked at #309. Original body below; issue references inside it are historical (dezren39/nix numbering).
Parent: #90
Summary
Give the docs site its own hostname, e.g. mcpx.drewrypope.com: create the DNS record, set the custom domain on the repository's Pages, confirm the domain is verified against takeover, then enforce HTTPS. This is mostly clicks and one DNS record. The only real choice is subdomain vs. a path under www.drewrypope.com vs. a new domain.
Original notes
- documentation
- make a book using whatever is the most common and simple modern choice
- github static setup. separately, assign a subdomain
("github static setup" is #118.)
Current state (checked 2026-09-30 with dig, curl and gh api)
| Name | Resolves to | Serves |
|---|---|---|
drewrypope.com (apex) |
Porkbun forwarding IPs 207.207.210.x |
a 307 redirect to http://www.drewrypope.com/, done by Porkbun rather than GitHub |
www.drewrypope.com |
CNAME dezren39.github.io |
the user site dezren39/dezren39.github.io (branch-published, HTTPS enforced) |
mcpx.drewrypope.com, docs.drewrypope.com, any random name |
CNAME uixie.porkbun.com |
Porkbun parking. This looks like a wildcard *.drewrypope.com record |
_github-pages-challenge-dezren39.drewrypope.com |
TXT present | the GitHub Pages domain-verification record for the dezren39 account |
- DNS is hosted at Porkbun (NS
*.ns.porkbun.com). This answers the question of who hosts the DNS. - A domain verified for the account covers its immediate subdomains (GitHub docs). If
drewrypope.comshows as verified under Settings > Pages, thenmcpx.drewrypope.comis already protected from takeover. Confirm in the UI, because the TXT record is only evidence of verification. - The wildcard. GitHub warns against wildcard DNS records because of takeover risk. That warning is about wildcards pointed at GitHub Pages; this one points at Porkbun parking. An explicit
mcpxCNAME takes precedence over the wildcard for that name, so the wildcard does not block this issue. Whether to keep it is a separate call (security deferred). dezren39/nixhas no Pages site yet (fix(deps): update github.com/charmbracelet/ssh digest to ebfa259 - autoclosed #118). Until it has a custom domain, a project site from it would be served athttps://www.drewrypope.com/nix/, because it inherits the user site's domain.
Steps (assuming Approach C and the Actions deploy from #118)
- Add the custom domain on the repository first: Settings > Pages > Custom domain, or
gh api repos/dezren39/nix/pages -X PUT -f cname=mcpx.drewrypope.com. GitHub asks for the domain to be added on GitHub before creating the DNS record, so that nobody else can claim it in between (GitHub docs). - At Porkbun, create
CNAME mcpx -> dezren39.github.io.. It must be the user domain: notdezren39.github.io/nix, and not the*.pages.github.ioname shown in repository settings. - Verify the record with
dig mcpx.drewrypope.com +nostats +nocomments +nocmd, which should show the CNAME chain ending at GitHub Pages. Propagation can take up to 24 hours. - Wait for the certificate, then tick Enforce HTTPS. The option can take up to 24 hours to appear.
- No
CNAMEfile. With a custom GitHub Actions workflow, "noCNAMEfile is created, and any existingCNAMEfile is ignored and is not required" (same GitHub page, step 4). Do not add one. It would do nothing, and it would mislead the next reader. It only matters if fix(deps): update github.com/charmbracelet/ssh digest to ebfa259 - autoclosed #118 chooses Approach A (branch deploy). - Base URL. Build the site for
https://mcpx.drewrypope.com/with root/, not/nix/: fix(deps): update github.com/charmbracelet/ssh digest to ebfa259 - autoclosed #118'sbaseUrlargument, or mdBook'ssite-url. - Check the old path. GitHub normally redirects
www.drewrypope.com/nix/to the new domain once one is set. Verify this after the switch; do not rely on it.
Approaches: which hostname
Approach A (least recommended): no custom domain, serve at www.drewrypope.com/nix/
- It costs nothing: no DNS change at all.
- But the URL names the config monorepo, not the product, and it breaks the day the docs move (a separate repository, a rename).
- The
/nix/base path gets baked into every link and asset, and printed install one-liners (curl <url> | sh, amd host fails at evaluation: no outputHashes for p2panda-core-0.7.1 #158) would carry it forever.
Approach B (middle): a new dedicated domain, e.g. mcpx.dev or getmcpx.com
- It gives the best name for a product and the best short URL for
curl -fsSL <domain>/install.sh | sh. It also survives any change of owner or repository. - Costs: a registration fee every year, a second DNS zone, a separate domain verification, and the domain has to be renewed forever or it becomes a takeover target.
- It is worth it only if mcpx becomes a public product with users outside this machine. It can be added later: the domain setting on the repository is one field, and the old subdomain can redirect.
Approach C (recommended): mcpx.drewrypope.com
- One CNAME in a zone that is already managed.
- The domain appears already verified for the account, so no new takeover surface.
- HTTPS comes free from GitHub Pages.
- It is independent of the repository name, so the docs can later move to another repository by moving one repository setting.
- It is exactly what the notes ask for ("assign a subdomain").
Open questions
- The name:
mcpx.drewrypope.comordocs.mcpx..., or something else? - Does the short install URL for
curl <short> | shlive on this host (e.g.https://mcpx.drewrypope.com/install.sh, served by Pages as a static file), or somewhere shorter? It is tied to the release channels in amd host fails at evaluation: no outputHashes for p2panda-core-0.7.1 #158. - Keep or remove the Porkbun wildcard
*.drewrypope.comrecord? - Should the apex keep forwarding to
wwwvia Porkbun, or move to GitHub's own apex-to-www redirect (A/AAAA records on the apex)? This is unrelated to mcpx and can be left alone.
Ease · Impact · Related
Ease S (one DNS record, one repository setting, a wait for the certificate) · Impact med (stable public URL; every printed link and the install one-liner depend on it) · Depends on / related: #118 (the site must exist first), #158 (short install URL), #155
Security/auth deferred; see tracker.
Activity
developing-today commentedon Oct 28, 2026
CODE-868
dezren39 commentedon Oct 28, 2026
History carried over from dezren39/darwin-nix#119 (verbatim, oldest first):
@dezren39 · 2026-09-30T07:20:17Z
Integration pass. Placed in the DAG rooted at #181.
d956689to222dd7f#90 (site platform)dezren39 commentedon Oct 29, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 29, 2026
🤖 Agent note · done (triage) — one decision is Drew's, surfaced below in full
Triage verdict
Dedupe. Not a duplicate. #1943 is the domain slice of tracker #1890; its siblings are #1939 (choose the site generator) and #1941 (build the site in CI and deploy to GitHub Pages). No other issue covers DNS/custom-domain work.
The premise moved with the relocation. The steps in this issue target a Pages site on
dezren39/nix(its #118). The docs now live here, indeveloping-today/codeunderpkgs/mcpx— and this repo has no Pages site yet (verified 2026-10-29:gh api repos/developing-today/code/pagesreturns 404). So there is currently nothing for a custom domain to attach to: #1941 must land first (with #1939's generator choice feeding it). The good news from the relocation: the rest of the issue's analysis carries over unchanged — same GitHub account (dezren39), same Porkbun zone, same verified-apex reasoning — only the repository in step 1 changes fromdezren39/nixtodeveloping-today/code.Sequencing (no implementation packet enqueued — it would only block):
gh apiondeveloping-today/code, verify the CNAME chain, enforce HTTPS once the certificate issues, build with root base URL/, and check the old path redirects. Acceptance criteria from this issue carry over as written, with the repo name swapped.The decision for Drew (in plain words)
What this is: the mcpx documentation site (once #1941 builds it) needs a public web address. This is choosing that address and creating one DNS record for it.
The options:
www.drewrypope.com/nix/; here it would be under the user site's domain with a project path). Costs nothing and needs no DNS change — but the URL names Drew's personal site, not the product, every link and asset bakes in the path prefix, and printed install one-liners would carry it permanently. Moving docs later breaks every link.mcpx.dev). The best product name and the best short URL for a futurecurl <domain>/install.sh. Costs a yearly registration fee forever, a second DNS zone to manage, a separate domain verification — and if the registration ever lapses, the name becomes a takeover target.mcpx.drewrypope.com(the issue's recommendation, and mine). One CNAME record (mcpx→dezren39.github.io) in the Porkbun zone Drew already manages; the apex domain already carries the GitHub Pages verification TXT record (per this issue's 2026-09-30 check), so no new takeover surface; HTTPS is free from GitHub Pages; and because the hostname is independent of the repository, the docs can move repos later by changing one setting.Recommendation: C. It is exactly what the original note asked for ("assign a subdomain"), it costs nothing recurring, and B remains available later — the repository domain setting is one field, and the subdomain can redirect to a future dedicated domain.
What I need from Drew, when #1941 is close:
One evidence caveat: I could not re-verify the issue's 2026-09-30 DNS findings from this sandbox — its DNS answers come through an intercepting proxy (synthetic 198.18.x range), so the wildcard/parking/TXT state is carried from the issue, not re-checked. Real verification (
digfrom a normal network) is step 3 of the implementation sequence above, before anything depends on it.Labels: set to
user/review— this is Drew's call above; the queue task is complete and nothing is enqueued behind it.29 remaining items
dezren39 commentedon Nov 5, 2026
🤖 Agent note · unblock pass 2026-11-05 — ready packet; Drew's remainder shrunk to two one-line acts
gh api repos/developing-today/code/pages→cname: null,https_enforced: true, site healthy at developing-today.github.io/code/. Laptop-sidedig mcpx.developing-today.com→uixie.porkbun.com(parking wildcard — no explicit record yet);zettel.developing-today.comprecedent intact. Nothing has moved since the 2026-11-03 triage.mcpxCNAME ininfra/dns/dns_config/default.nix(zettel pattern). It is inert — a declaration only.mcpx.developing-today.com,mcpx.developing.todayas a Porkbun URL-forward redirect (Pages supports exactly one custom domain — this is the only shape).user/escalatedby design — but it is now a decision + a word, not a project.dezren39 commentedon Nov 5, 2026
#1943 prep advanced (2026-11-05): terraform plan run against PR #6119's declaration — still NOT applied (gate #1860 stands).
dns/mcpx-cname-1943, the one-linemcpxCNAME declaration ininfra/dns/dns_config/default.nix) and the owner's owninfra/dns/plan.shwas run end-to-end (nix config generation → sops state load → tofu init → plan). True plan: 1 to add, 0 to change, 1 to destroy.mcpxCNAME ondeveloping-today.com→developing-today.github.io, TTL 600 — exactly the dns: declare mcpx CNAME — prep for #1943 (NOT applied) #6119 declaration, nothing more.01b.usentry of typeLINSTOR-CONTROLLER, namelinstor, id"0"— not a real DNS record type and absent from the declared config ("key not in for_each map"). An apply would ask the provider to delete it; it should betofu state rm'd or otherwise dealt with under the same go-ahead so it can't complicate the cutover apply.tofu initin a fresh checkout moved the decrypted state aside (terraform.tfstate.backup, 78,165 B) and planned against an empty state. That artifact was discarded; the figures above come from a directtofu plan -refresh=falsewith the state restored from that backup. (In Drew's already-initialized working clone the init step is a no-op and this doesn't arise.)mcpx.developing-today.com,mcpx.developing.todayas a Porkbun URL-forward redirect — and says "apply it" (the Validate the legacy DNS Terraform project (Porkbun bulk changes) — read-only #1860 go-ahead); (2) GitHub Pages claim formcpx.developing-today.comissues the domain-verification token; (3) the_github-pages-challenge-developing-today.mcpxTXT record is declared indns_config/default.nixwith that token and the whole change is applied viatofu apply; (4) dig + HTTPS verification, docssiteUrlflip; (5) Porkbun console forward formcpx.developing.today.dezren3i, its password checks out, and the only remaining step there is an emailed 2FA code (details on impl(dns-registry): recurring DNS backup job, renewal/cost tracking, dashboard view of the domain register #902). It does not gate this issue; both zones for mcpx docs: a custom subdomain for the site (DNS, CNAME, HTTPS) #1943 sit in the main account.dezren39 commentedon Nov 5, 2026
Drew clarification (2026-11-05 02:08 CST): mcpx.developing-today.com's zone is in the MAIN Porkbun account (
developingtoday) — the mcpx CNAME needs only the API key we already have (BWSporkbun.api-key/porkbun.secret-key, verified against that account). The second account (dezren3i) is NOT on the mcpx path; its login is proceeding separately for audit + API access to its own domain group (drewrypope.com). The plan stands as computed (1 add = the mcpx CNAME; 1 destroy = the state-only01b.usLINSTOR remnant, state-rm recommended under the same go-ahead). Apply still waits for Drew's explicit go-ahead per the #1860 rule.dezren39 commentedon Nov 5, 2026
Note from the 2026-11-05 Porkbun pass (details on #902): mcpx.developing-today.com stays in the main account (
developingtoday) per Drew's clarification — developing-today.com is confirmed among that account's 39 domains and its per-domain API opt-in is already on. The second account is audit/API-key work for its own domain group only and is not on the mcpx path.One caveat for the apply: the BWS main pair (
porkbun.api-key) is domain-restricted — API reads succeed only forsecurity.cab; developing-today.com itself is denied by key scope ("This API key is restricted to specific domains"). Before the apply, confirm which credentials infra/dns actually uses; if it is this pair, the key's allowed-domains have to be widened in the web session first. Still no apply.developing-today commentedon Nov 5, 2026
Credential question CLOSED — Drew's ruling (main chat, 2026-11-05): "terraform uses the dev today cred for dev today domain I already answered that."
So terraform (infra/dns) uses the main Porkbun account credential (the BWS pair
porkbun.api-key/porkbun.secret-key) for developing-today.com — consistent with Drew's 2026-11-05 02:08 ruling that the mcpx zone lives in the main account. No credential swap is needed or planned.Why that pair currently can't read developing-today.com — root cause PROVEN today (API's own error, reads only):
domain/listAllwith the main pair: 200, all 39 domains returned, every domainapiAccess: 1— per-domain API opt-in is ON account-wide, including developing-today.com. The domain-side toggles are not the problem.dns/retrieve/developing-today.com: 403 — "This API key is restricted to specific domains anddeveloping-today.comis not in the allowed list." Identical 403 for developing.today and rom.how.dns/retrieve/security.cab: 200 SUCCESS, 10 records.The main account's API key itself carries a domain allowlist containing only security.cab. That is the whole blocker.
Exact fix (documented, NOT applied — editing the main account's key settings is outside this lane's authorization, and no main-account session was live): in the main Porkbun account → Account → API → gear/settings on the existing key → add
developing-today.comto the key's allowed domains (or clear the domain restriction). One-minute UI edit; no DNS change, no key rotation — the pair terraform already uses stays the same, and it will then read developing-today.com's records.Apply status unchanged: this issue's apply (mcpx CNAME → developing-today.github.io + the
01b.usstate-only cleanup) still waits for Drew's explicit go-ahead, per the standing "wait to apply".Same-session completion (second account, for the record): the dezren3i Porkbun account audit + API setup is done — full-access API pair created and vaulted in Bitwarden as
porkbun.dezren3i-api-key/porkbun.dezren3i-secret-key(fingerprints verified on read-back), API access enabled for all 8 domains in that account (apiAccess: 1on each), and DNS reads proven for all 8, including drewrypope.com (12 records).developing-today commentedon Nov 5, 2026
Correction to the comment above (my earlier figures came from a corrupted tool delivery; the values below are from two independent synchronous API re-reads, 2026-11-05):
For the dezren3i account: the per-domain
apiAccessflag reads 0 for all 8 domains inlistAll— API access works because the account-level "Opt In All Domains" setting is ON, which grants the unrestricted key access account-wide regardless of the per-domain flags. DNS reads are proven for all 8 domains; correct record counts: drewrypope.com 17, dezren39.dev 12, the other six 11 each. The main-account findings in the comment above (39 domains, the 403 allowlist error, the exact fix) are unaffected — those were verified in two synchronous runs.dezren39 commentedon Nov 5, 2026
Porkbun main-account follow-ups BLOCKED on session (2026-11-05 ~10:52 CST): Drew's two directives — (1) create a NEW unrestricted main-account API pair (replacing the edit-in-place allowlist plan; vault as
porkbun.devtoday-full-api-key/porkbun.devtoday-full-secret-keyper Drew's naming ruling) and (2) add popesdrew@gmail.com as the main account's backup email — both require a livedevelopingtodayweb session, and none exists on the laptop. The only Porkbun session (Helium, CDP 19222 — the only browser debug endpoint up) is dezren3i, proven two ways: the API page's key fingerprint isd9971fc716e9(the dezren3i pair created today), not52c1d1026fb7(the vaulted main pair); and the account settings page shows username dezren3i. Drew's login today covered dezren3i + Meta only. No fresh login was attempted. Next step is Drew's: log into the main Porkbun account on the laptop (same as he did dezren3i), and both items execute immediately. #1943's apply still separately awaits his go-ahead; terraform still consumes the restricted BWS pair — no rewiring done.dezren39 commentedon Nov 5, 2026
BWS Porkbun secret rename — done (Drew directive, main chat 2026-11-05 10:47 CST: "rename so it's clear it's devtoday and limited or full access").
This account's pair (values unchanged — new-named secrets created with identical values, sha256-verified before the old names were deleted):
porkbun.api-key→porkbun.devtoday-limited-api-key(sha256 52c1d1026fb7…, len 68)porkbun.secret-key→porkbun.devtoday-limited-secret-key(sha256 4f5c0e526b52…, len 68)Old names deleted from BWS afterward; get-by-old-id now errors.
Consumers inventoried first: nothing reads these BWS names programmatically. The one live reference was the sops mirror
secrets/sops/common/bws.yaml, whose keys are the BWS names — updated in PR #6317 (merged, merge commit 8d82b73): decrypted key-diff is exactly these two renames, every other value identical, round-trip verified; the primary checkout's mirror now carries the new names. infra/dns is NOT a BWS-name consumer:main.tfreads keysporkbun_api_key/porkbun_secret_keyfrom the sops filesecrets/sops/common/porkbun.yaml— untouched by this rename.Post-rename smoke (creds fetched via the new names):
domain/listAll200, 39 domains;dns/retrieve/security.cab200, 10 records — the pair remains allowlist-limited exactly as before; only the names changed.One operational note: the fleet secrets broker still serves the deleted names from its in-memory cache until its next periodic refresh (≤15 min TTL; the manual refresh endpoint needs an admin token). BWS itself — the source of truth — no longer has them, and no consumer reads the old names.
The new full-access main pair (parallel lane) is being vaulted directly as
porkbun.devtoday-full-api-key/porkbun.devtoday-full-secret-key, completing the naming scheme: devtoday-limited / devtoday-full / dezren-full.dezren39 commentedon Nov 5, 2026
Correction to my rename-completion comment above (comment 6664072693): the claim "nothing reads the BWS names programmatically" was incomplete. A delayed full-tree grep finished afterward and surfaced one real consumer of the old main-account names: the weekly DNS backup script
dns-backup.py(goal crondns-backup-weekly, Sundays 09:12, code#902 slice 1).It has been migrated to
porkbun.devtoday-limited-api-key/porkbun.devtoday-limited-secret-keyand verified through its own code path (secret fingerprints match the renamed secrets; self-test passes; read-onlylistAllreturns SUCCESS, 39 domains). Detail recorded on #902. All other old-name mentions in the tree are historical records (dated snapshots, memory logs, baselines), left as-is. The old names stay deleted.dezren39 commentedon Nov 6, 2026
Porkbun unblock attempt — 2026-11-06 (fleet-side solve pass)
Tried to clear the account blockage end-to-end fleet-side. Status per leg:
Root cause re-verified with fresh API calls today: the main account's BWS pair (
porkbun.devtoday-limited-*, api-key sha fp52c1d102) lists all 39 domains fine, butdns/retrievefor any non-allowlisted domain returns 403 — "This API key is restricted to specific domains" (allowlist: security.cab only). drewrypope.com is a main-account domain, so this issue's CNAME cannot be created via API with the current pair. The unrestrictedporkbun.devtoday-full-*pair still does not exist in Bitwarden.Remaining blocker (unchanged, precisely): creating the full pair and setting backup emails both require a logged-in Porkbun web session. Neither account password is in Bitwarden or 1Password — both live only in the laptop browser's saved logins, so this leg needs a live-browser session on the laptop (saved-login sign-in for
developingtoday, thendezren3i) or Drew at the laptop. Steps queued for that session: create the unrestricted pair → vault asporkbun.devtoday-full-api-key/-secret-key; set backup email to popesdrew@gmail.com on both accounts; save the already-staged dezren3i backup-email form; click the Porkbun confirmation links from the popesdrew inbox; vault both logins into Bitwarden + 1Password.Terraform plan staged (infra/dns):
terraform.tfplan(sha256313db4b4…), computed against the correctly loaded state (152 instances): 0 to add, 0 to change, 1 to destroy — the destroy is the state-only remnantporkbun_dns_record.record["01b.us_linstor_LINSTOR-CONTROLLER_0_0"], a state-rm candidate at apply time. Note: this issue's mcpx CNAME is not in the terraform config (drewrypope.com has no terraform-managed records at all), so no mcpx add exists in the plan — the record itself is still blocked on the account leg above. Nothing was applied; the apply word remains Drew's.Hazard found in the consumer workflow:
./plan.shas-run today produces a WRONG plan —tofu initbacks the decrypted state up toterraform.tfstate.backupand initializes an empty state at the backend path, so the plan reads "151 to add, 0 to destroy". Do not run./plan/./applyuntil that init behavior is fixed; the staged tfplan above was produced with the state correctly loaded, andterraform.tfstate.encis byte-identical to before (sha21b74bb7…).Merge pull request #6498 from developing-today/fix/dns-terraform-init…
dezren39 commentedon Nov 6, 2026
Terraform plan hazard FIXED — PR #6498 merged
The
./plan.shwrong-plan hazard recorded above is fixed and merged: PR #6498, merge commit4f29a12ebfb69e1867383221ac2eeb5ec666a9a3.Root cause.
load.shdecrypts the state of record toterraform.tfstate— both the local backend's-backend-configpath AND the working directory's default state path. When the backend has never been initialized in that directory (no.terraform/terraform.tfstaterecord: fresh checkout/worktree, or aftercleanup_terraform.shremoved.terraformwhile the decrypted state stayed — cleanup without--allkeeps it),tofu inittreats the file as a legacy pre-backend state to migrate; in the local→local same-path case it installs an EMPTY state at the backend path and leaves the real state only interraform.tfstate.backup, so the plan runs against a void ("151 to add"). Reproduced deterministically in a clean worktree;-reconfiguredoes not avoid it; a state file at a non-default name is not migrated.Fix (infra/dns, 3 scripts, +61 lines).
init.sh: snapshot the decrypted state (sha256) beforetofu init; restore it afterwards if init replaced it (loud WARNING) and fail hard if it is not intact byte-for-byte; refuse to init at all if the loaded state is missing/empty.plan.sh: before planning, refuse (exit 1) ifterraform.tfstateis empty or its lineage differs from a fresh decryption ofterraform.tfstate.enc; refusal exits setSKIP_SAVE=1so the EXIT trap cannot save a refused state over the.enc.save.sh: ifterraform.tfstate.encalready decrypts to exactly the current state, skip re-encryption — read-only runs now leave the encrypted state of record byte-identical instead of dirtying it with fresh ciphertext of the same plaintext.Encrypted-state design and the cleanup scripts are unchanged.
Verification (worktree, hazard condition: no
.terraform, no state file, only.enc)../plan.shend to end: guard fired (snapshot → migration detected → restore → verified), lineage verified, final plan 0 to add, 0 to change, 1 to destroy — the destroy isporkbun_dns_record.record["01b.us_linstor_LINSTOR-CONTROLLER_0_0"](state-only), as expected.terraform.tfstate.encsha256 identical before/after:21b74bb79be1abf6….encuntouched in both.No apply was run. The remaining apply on this issue (1 add = mcpx CNAME; 1 destroy = the state-only LINSTOR remnant, via state rm per the plan of record) still waits for the unrestricted pair + Drew's explicit "apply it".
Reconciliation flag (recorded only, no change made). The terraform consumer authenticates with the sops-held pair in
secrets/sops/common/porkbun.yaml(fp ak2e4b92ec), which matches NEITHER BWS-tracked pair (not the restrictedporkbun.devtoday-limited-*, notporkbun.dezren-full-*). When the unrestrictedporkbun.devtoday-full-*pair lands, this consumer's credentials should be reconciled to it (or the sops pair explicitly adopted as canonical) so the DNS workflow does not keep running on an untracked third pair.dezren39 commentedon Nov 6, 2026
Porkbun main-account API leg — status after the 2026-11-06 browser session (Helium/CDP on the laptop):
Blocked at sign-in — one Drew-step remains. Creating the unrestricted
porkbun.devtoday-full-*pair requires a logged-in session on the maindevelopingtodayaccount. Findings from the session:developingtoday(x2) anddezren3i(verified by origin+username only; values never read).dezren3ionly, and it is being preserved untouched (logging it out would strand that account behind the same password wall).Drew-step (unchanged from the standing ask): sign in to the
developingtodayaccount on the laptop once (type the password — it is on your phone's Chrome sync). Once a main-account session exists, the fleet side can immediately: create the unrestricted pair, vault it as BWSporkbun.devtoday-full-api-key/porkbun.devtoday-full-secret-key(sha-verified), set the backup email to popesdrew@gmail.com, verify listAll + dns/retrieve for developing-today.com, and then run the staged terraform plan.No terraform was run (per the plan.sh hazard note). The sops-held terraform pair was not touched.