Skip to content
duxt

Publish Terraform provider docs

Turn a tfplugindocs Markdown tree into a versioned provider reference with provider-aware navigation.

tfplugindocs already writes Markdown. duxt does not parse it as another generated artefact; it reads the directory as a source whose established file and heading conventions carry more structure than an ordinary manual.

Steps

  1. Generate the provider documentation in its own repository. Keep the docs/ tree tfplugindocs writes, including its provider, resources, data sources, functions and guides directories. duxt reads that output; it does not run tfplugindocs during the Nuxt build.
  2. Declare the repository as a source flavour.
    export default defineAppConfig({
  duxt: {
    sources: [
      {
        repo: 'acme/terraform-provider-acme',
        path: 'docs',
        slug: 'terraform',
        name: 'Terraform Provider',
        flavor: 'tfplugindocs',
        releases: { select: 'minor' }
      }
    ]
  }
})
  3. Choose the versions readers should retain. releases discovers provider tags using the same all, minor and major policies as any other source. Use an explicit { tag } when the reference must remain pinned to one release, or add a branch beside the releases for upcoming documentation.
  4. Build and inspect the provider navigation. duxt derives the provider title from the first H1, orders the known tfplugindocs categories, and keeps subcategory groups as navigation structure rather than pretending they are pages. The Markdown remains ordinary Content data, so search, locale fallback, version switching and machine-readable routes need no provider integration of their own.

What the flavour changes

Without flavor, the directory is an ordinary Markdown source and its folders are shown as Content finds them. With flavor: 'tfplugindocs', duxt recognises the generator's categories and frontmatter, derives the provider-aware tree and normalises the page metadata needed by the shared documentation layout.

It does not rewrite Terraform syntax, run examples, invent missing category pages or turn provider docs into an OpenAPI-style request client. The source flavour only interprets the structure already present in the generated Markdown.

Checklist

  • tfplugindocs has generated the Markdown tree before the Nuxt build.
  • The source has an explicit repo when it uses tags, branches or release discovery.
  • path points at the generated documentation directory.
  • flavor is exactly 'tfplugindocs'.
  • The source has a stable slug and a reader-facing name where several repositories share the site.
  • The chosen release policy preserves every version that existing links must keep reaching.
  • A production build shows provider categories without synthetic group routes.
Was this page helpful?