Documentation migration notes

Canonical packages/docs vs legacy public site and apps/website MDX; repo docs/ for operators.

Written By Zoro

Last updated 3 days ago

Canonical customer documentation

Authoritative customer documentation is written in MDX under:

  • packages/docs/content/ in the dFlow monorepo.
  • The information architecture is encoded in packages/docs/IA.md. Navigation order and metadata are reflected in packages/docs/manifest.json. Authoring rules are in packages/docs/AUTHORING.md and packages/docs/CONTRACT.md.
  • Preview and in-app surfaces read that content; do not treat older trees as the source of truth.

Legacy public help centre

The legacy public documentation (historically associated with docs.dflow.sh) is tracked for URL inventory, redirects, and parity checks via:

  • packages/docs/LEGACY_PUBLIC_DOCS_INVENTORY.md
  • packages/docs/legacy-public-docs-articles.json

When a topic exists in both places, prefer the packages/docs page and update it to match the current Applications / Environments / Services UI.

Marketing website apps/website/content/docs

Gap note (Featurebase / Help Center tooling): a recursive search under apps/website/content/docs/ for Featurebase-specific publish or sync instructions found no dedicated MDX. Publish workflow for the public help centre lives in packages/docs/CONTRACT.md, packages/docs/GOVERNANCE.md, and packages/docs/scripts/featurebase-sync.mjs.

The repository still contains MDX under apps/website/content/docs/ (for example guides and fundamentals). Per packages/docs/CONTRACT.md, that tree is for gap analysis and redirects, not for expanding the canonical customer doc set during the rebuild.

Gap note (legacy terminology): content such as apps/website/content/docs/guides/fundamentals/projects.mdx describes the old “Project” flow (create project, server selection, naming rules). Use it only to infer what users were told before; rewrite behaviour in packages/docs using Application, Environment, and Service language, as in Create an application under Applications in the sidebar and Migrate from legacy Projects to Applications.

Other website MDX files that mention “project” in passing (setup, integrations, databases, architecture) should be checked for parity when those sections are ported, not copied blindly.

Gap note (Phase 9.3, legacy database-related MDX): the following paths under apps/website/content/docs/ were used for parity input only (legacy “Project” navigation and port-mapping language; not source of truth): databases/overview/index.mdx, databases/overview/postgresql.mdx, databases/overview/mysql.mdx, databases/overview/mariadb.mdx, databases/overview/mongodb.mdx, databases/overview/redis.mdx, databases/overview/clickhouse.mdx. Related fundamentals that mention databases or services: guides/fundamentals/services.mdx, guides/fundamentals/environment-variables.mdx, guides/fundamentals/volumes.mdx, integrations/providers/index.mdx, setup/(self-host)/docker-compose.mdx, setup/(self-host)/overview.mdx, setup/installation/running-on-docker.mdx, guides/templates/best-practices.mdx, team/index.mdx, index.mdx. Canonical database docs: packages/docs/content/databases/.

Repository docs/ (engineering)

Top-level docs/ in the repo holds runbooks and rollout plans (for example docs/projects-to-applications-rollout.md). Link them from customer pages when operators need procedures; keep end-user steps in packages/docs.

Related