Journal

A local publishing example

Thu, 01 Oct 2026 00:00:00 GMT

This is example content for verifying the blog. It describes the publishing workflow, not the results of a completed experiment.

Start with a question

A useful experiment starts with something specific to find out. Write down the question, the setup, and what would count as a useful result before changing settings.

This notebook keeps articles as Markdown files. The site is built ahead of time, so reading a finished article does not require a model, a database, or a JavaScript server.

Keep the details

When writing up a test, include the software versions, hardware, prompts, and configuration. Separate what you observed from what you think explains it.

# Example article metadata
title: A question worth testing
draft: true
tags: [Local AI]

Show the trade-offs

Results become more useful when readers can see what failed, what changed between attempts, and the limits of the setup. A table can summarize the things you measured:

Item	What to record
Hardware	CPU, GPU, and available memory
Software	Model name, release, and configuration
Method	Inputs, repetitions, and evaluation criteria
Outcome	Observations and supporting material

Publish the finding

Change the draft flag when the article is ready. A build validates the Markdown, generates the pages, and packages the result for the server.

For an actual experiment, replace this example with your own measured findings and supporting material.

A voice for the notebook

Tue, 29 Sep 2026 00:00:00 GMT

This is an example article. Narration generation will be connected in the next milestone; this page does not claim a voice-model benchmark.

Generate once, listen whenever

Article audio should be prepared on the main server. The small public server only needs to send the finished recording to a reader.

Write for listening

Long code blocks and tables need a prose explanation rather than a word-for-word reading of punctuation. A good narrated article preserves the argument and gives listeners enough context to follow it.

Keep recordings in sync

Each recording belongs to an exact revision of the article. If the text changes, an outdated recording should disappear until the matching audio is ready.

Keeping a small server small

Sun, 27 Sep 2026 00:00:00 GMT

This is an example article describing the platform design. Resource figures will be added only after the actual deployment is measured.

Do the expensive work before publishing

Markdown parsing, frontend compilation, image preparation, and voice generation happen on the main server. None of those jobs need to run each time a reader opens a page.

Serve completed files

The public container runs a Go process that serves HTML, styles, scripts, images, and available article audio. The existing Caddy edge handles public HTTPS.

Measure the real deployment

Idle memory is only one part of the picture. Measure the container and the whole host while pages, images, and recordings are being requested together.