Imprint System

One mother, many imprints. A printing-press metaphor for spawning child projects from a single Docuget codebase without forking.

An imprint is a child project rendered from a YAML manifest. The mother codebase is never modified — docuget imprint build reads imprint.yaml, selects the API modules listed under modules.api, bundles owned assets (branding/, guides/, templates/), and writes a self-contained dist/ with a Dockerfile, compose.yaml, .env.template and metadata.

Same content-as-data philosophy as the guides and templates systems. Same regenerate-on-demand cycle as prisma generate.

Why

You have a side project that needs only some of Docuget's modules with custom branding and content. Forking is heavy and forks drift. An imprint is a thin manifest that stays in lockstep with the mother.

Manifest

imprint:
  id: knowledge-toolkit
  name: "Knowledge Toolkit"
  docuget_version: v0.10.0
  source:
    mode: local # https-public | ssh | pat | local
    path: /home/me/docuget_api_rest # for local mode

modules:
  api: [core, guides, templates, video]
  frontend: [guides_viewer, video_player]

services:
  postgres: { enabled: true, version: "16" }
  minio: { enabled: optional }

auth:
  mode: local

outputs:
  - { format: website, deploy: docker }
  - { format: pdf, deploy: r2 }

core is always required (auth, users, companies, files). Other modules are opt-in.

CLI

docuget imprint init knowledge-toolkit --from=knowledge_toolkit
docuget imprint validate knowledge-toolkit
docuget imprint build knowledge-toolkit
docuget imprint up knowledge-toolkit -d
docuget imprint logs knowledge-toolkit -f
docuget imprint down knowledge-toolkit
docuget imprint list

Source modes

How the build step obtains the mother source code:

docuget imprint up automatically enables BuildKit and forwards the right flags (--ssh default or --secret id=ghtoken,env=DOCUGET_GH_TOKEN) based on source.mode.

Build pipeline

1. Wipe previous dist/ so deleted source files actually disappear.
2. Render Dockerfile, compose.yaml, .env.template, README.md from the manifest.
3. Write imprint.json with the resolved manifest + _meta block.
4. Copy owned assets (branding/, guides/, templates/) into dist/.
5. Render guides if the imprint declares the guides module — invokes the mother renderer with GUIDES_ROOT pointing at the imprint's own guides directory. Outputs land in dist/guides/output/.
6. Write .generated marker warning humans not to hand-edit.

Asset serving

The api container mounts bundled assets read-only at /imprint:

A static-file router on api-rest exposes these over HTTP:

On the mother server IMPRINT_ASSETS_DIR is unset, so every /v1/imprint route returns 404. The router lives in the core module but is dead code outside an imprint.

Module catalogue

145 routes across 14 modules:

IMPRINT_MODULES=core,guides,finances at boot time filters which routers mount.

Status

See also

• Guides system — same content-as-data philosophy
• Plan: docuget-skills/plans/platform/imprint/plan_summary.md
• Guide: docuget imprint build then open dist/guides/output/imprint/en/guide.html