Privacy

A CV contains things a website should not: a private address and phone number, referees, an exhaustive talk list, sometimes a cover letter written for one application. vitakit is built so that keeping those off the web is structural rather than a matter of remembering.

The model

Assume your repository is private. That is where the sensitive material lives, and it is the natural place for it. What needs controlling is not the repository but what the website build emits.

content/*.yml   visibility: public | cv | private
                      │
      website build ──┴── hard-wired to `public`, not configurable
      cv-tex/*.tex  ──── document's own `visibility:`, default `cv`

Marking content

- date: { from: 2019, to: 2019 }
  position: Visiting Researcher
  institution: Uppsala University
  visibility: cv          # in the PDF, never on the website

Level	Website	PDF (visibility: cv)	PDF (visibility: private)
public (default)	yes	yes	yes
cv	no	yes	yes
private	no	no	yes

A document's visibility: sets the highest level it may include, so an application dossier with a cover letter would use private, while a CV you hand out uses the default cv.

Three independent guarantees

1. The website loader is hard-wired to public. It is not an option in nuxt.config.ts, so there is no flag to set wrongly.
2. cv-tex/prose/ is never read by the website build. Cover letters and statements are plain LaTeX in a directory the web pipeline does not look at.
3. vitakit verify verifies the output. It reloads your content with private entries visible and fails if a non-public entry's title appears in the visible text of any generated page — the backstop for a page that prints something it should not. Only title-like fields are compared, because an institution or co-author name is usually public for some other entry; if a match is still a coincidence, run vitakit verify --no-leak-check.

pnpm

$ pnpm check
  ok  4 page(s) generated
  ok  1 non-public entr(ies) absent from the site

npm

$ npm run check
  ok  4 page(s) generated
  ok  1 non-public entr(ies) absent from the site

Run it in CI (the scaffolded workflows do) so a leak fails the deployment.

PDFs are not published

vitakit pdf writes to cv-tex/. Nothing copies a PDF into public/, and the CV workflow attaches it to the run as an artifact rather than deploying it. The website already renders your CV information directly, so there is usually nothing to gain from publishing the PDF as well.

If you do want /cv.pdf on your site, copy it into public/ yourself — knowing that it may carry cv-level material.

A note on GitHub Pages

A GitHub Pages site built from a private repository is still served publicly; private source does not mean a private site. And on the free plan, Pages requires a public repository at all.

Cloudflare Workers is recommended for new Cloudflare deployments: it can serve the static site while your GitHub source repository stays private, and Cloudflare now recommends Workers over Pages for new projects. The included GitHub Actions workflow checks the build and uploads only .output/public. The Pages preset is still available for existing projects. Static hosting and CI usage limits apply.

GitLab Pages also supports public sites from private source projects on Free; set Pages access separately from repository visibility. Codeberg Pages uses git-pages to upload built files, but Codeberg-hosted Actions runners require public, freely licensed source. If your CV source contains private data, use your own compatible runner rather than making the repository public to get hosted CI.

See publishing for account requirements, URLs and the other deployment choices.