chore(site): point published URLs at www.ferrosa.ai - #31
Merged
Conversation
Phase C of the domain migration. The site moved to www.ferrosa.ai on 2026-08-24 and ferrosadb.com now 301-redirects here with the path preserved, so nothing was broken before this change -- this is so newly published content and newly downloaded install scripts name the current domain. Replaced `https://ferrosadb.com` and `https://www.ferrosadb.com` with `https://www.ferrosa.ai` across the install scripts, the docs HTML, and the cosmetic source comments. Used `www.ferrosa.ai` rather than the bare apex deliberately: the apex currently 404s (GitHub has not wired its apex->www redirect and no Cloudflare rule covers it yet). Publishing the apex in an install one-liner before it resolves would break installs. Switching to the bare apex is a trivial follow-up once it is confirmed serving. NOT changed, deliberately: - Email addresses (ben@, security@, conduct@). ferrosa.ai is verified in Google Workspace but whether it is a domain ALIAS (receives mail) or a SECONDARY domain (needs users created) cannot be determined from DNS. Publishing a security@ferrosa.ai that does not receive would bounce security reports. - `specs/docs-repository-migration.md`, which records the state at the time the docs repo was split out. That is a historical design record, not live instructions. README's "Production Cutover" section was rewritten rather than search-replaced. It described the cutover as pending work against a domain that is no longer used, so renaming the domain in place would have left misleading "when ready to move production traffic" instructions for something already done. It now states the live URL and records the two facts that cost time during the migration: this repo uses an Actions-based Pages deployment, so `docs/CNAME` does NOT control the custom domain (it is a repository setting, and a fresh deployment is required before a new hostname serves); and the old domain must keep resolving and redirecting indefinitely because `/LATEST` and the install scripts are compiled into already-installed clients. Verified: all four install scripts pass `bash -n`, and https://www.ferrosa.ai/{install.sh,install-memory.sh,LATEST} all return 200.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase C of the
ferrosadb.com→ferrosa.aimigration.The site moved to
www.ferrosa.aion 2026-08-24 andferrosadb.comnow301-redirects there with the path preserved, so nothing was broken before this
change. This is so newly published content and newly downloaded install
scripts name the current domain.
Replaced
https://ferrosadb.comandhttps://www.ferrosadb.comwithhttps://www.ferrosa.ai.Why
www.and not the bare apexhttps://ferrosa.aicurrently 404s — GitHub hasn't wired its apex→wwwredirect and no Cloudflare rule covers it yet. Publishing the apex in an install
one-liner before it resolves would break installs. Switching to the bare apex is
a trivial follow-up once it's confirmed serving.
Deliberately not changed
Email addresses —
ben@,security@,conduct@,invites@,ferrosa@.ferrosa.aiis verified in Google Workspace, but DNS can't tell whether it's adomain alias (receives mail) or a secondary domain (needs users
created). Publishing a
security@ferrosa.aithat doesn't receive would bouncesecurity reports. Needs an Admin-console check first.
proxy.ferrosadb.com:29143(ferrosa-osx) — a DBaaS proxy endpoint, not thedocs site.
proxy.ferrosa.aidoesn't exist in DNS; rewriting it would break thefeature.
BASE_IRIand thedikw:prefix inferrosa-workbench/crates/ferrosa-workbench-app/src/ontology.rs— these areRDF/OWL identifiers, not links. The constant is documented as "the base IRI
for terms this workbench MINTS" and is written into Turtle output as an
@prefixdeclaration. Renaming it means every triple already persisted underthe old IRI stops matching newly minted terms — the same concept silently
acquiring two identities in the graph. That's a data migration with its own
reasoning, not a URL sweep.
Dead links fixed in passing
Only because these exact lines were being rewritten — shipping a link I'd just
touched and knew was dead is worse than leaving it alone:
/getting-started.html→/database/getting-started.html(ferrosa-dbaasspecs). The old form 404s and always did; the redirect only moved where the
404 happens.
/brand.html,/design-system.html→/internal/…(ferrosa-workbench ui).Those pages moved to
/internal/in ferrosa-docs Move brand, design system and compare to /internal; make footers consistent #29.Verification
Every rewritten URL was actually fetched, not assumed:
https://www.ferrosa.ai/LATESTv0.20.0https://www.ferrosa.ai/LATEST-MEMORYv0.28.0install.sh,install-memory.shsetup.sh,setup-memory.shdatabase/getting-started.htmlferrosa-memory/design-system.htmlEvery changed shell script passes
bash -n. The installer default now readsFERROSA_LATEST_URL:-https://www.ferrosa.ai/LATEST, and that URL serves.Part of t_dbbcc0a8.