Trilium Blog: Turning Trilium Notes into a Real Publishing Workflow

[harveyTon]

I have always liked the way Trilium Notes works.

It is flexible, structured, and powerful enough to serve as both a personal knowledge base and a long-form writing environment. But once your notes start to grow into something larger, one question becomes harder to avoid:

How do you turn writing inside Trilium into something that is actually pleasant to publish and read on the web?

That question is what led to trilium-blog.

This project is not trying to replace Trilium, and it is not trying to become yet another full CMS. Instead, it aims to be a lightweight publishing layer on top of Trilium: write in Trilium, organize in Trilium, tag in Trilium, and then publish selected notes as a clean, searchable, reader-friendly blog.

What problem does this project solve?

Rendering notes as HTML is not the hard part.

The hard part is turning them into a real blog experience.

A usable blog should not only display articles. It should also provide:

• a homepage that helps readers enter the content
• article pages that are comfortable to read
• search that is actually useful
• good handling for code, images, tables, and headings
• a mobile experience that feels intentional
• summary, featured content, and pagination flows that still work when the content set grows

That is what trilium-blog is trying to build: not just a note renderer, but a publishing experience.

How the project is structured

The project is a monorepo with a clear frontend/backend split:

• backend/ uses Go + Gin and handles API routes, content processing, summaries, and assets
• frontend/ uses Vue 3 + Vite and handles the homepage, search, article pages, and UI behavior

Trilium remains the content source. The blog does not replace the writing workflow; it layers on top of it.

The flow is straightforward:

Trilium Notes → ETAPI → trilium-blog backend → frontend → published blog

That means content management still happens where it belongs: inside Trilium. The blog’s job is to read, transform, and present that content well.

How content becomes a blog post

The publishing model is intentionally simple.

If a Trilium note is tagged with:

#blog=true

it becomes a publishable blog post.

If it is also tagged with:

#blogtop=true

it appears in the featured section on the homepage.

This works well because it avoids a second admin panel and avoids syncing content between two systems. You keep using Trilium as your writing environment, and the blog simply reflects the notes you choose to publish.

The homepage: from note list to content entry point

One of the main areas of refinement in recent versions has been the homepage.

Right now, it is centered around two primary sections:

• Featured posts
• Latest posts

The idea is simple:

• featured posts act as a curated entry point
• latest posts preserve the chronological browsing flow

On desktop, featured posts are presented as a carousel-style browsing experience. On mobile, they collapse into a single-card interaction with arrow navigation and swipe gestures. The goal is not to add motion for its own sake, but to make the homepage feel like a useful front door rather than just a raw list of notes.

Latest posts remain paginated, and the current page is reflected in the browser URL. That means individual pages can be linked directly, and readers can land on the exact page instead of always being dropped back at page one.

Search is a first-class feature

Search is no longer treated as a secondary utility.

The project now supports:

• a global search box in the header
• search preview results
• a dedicated search results page
• debounced input behavior
• mobile-specific search interaction

On desktop, search remains visible in the header as a persistent site-wide entry point. On mobile, it becomes a modal-based experience triggered from the header, preserving screen space while keeping search immediately accessible.

For content-heavy sites, search matters a lot. Once you have enough writing, not every reader wants to browse page by page. Many would rather type a keyword, get a relevant result, and jump straight into reading.

Article pages: reading comes first

The article page is designed around one rule:

reading must come before enhancement.

The current reading experience includes:

• a table of contents
• a reading progress bar
• syntax highlighting for code
• image grouping and enhancement
• comments
• light and dark themes

These may look like separate features, but together they answer the same question: how do you turn a Trilium note into something that feels like a real web article rather than a raw export?

For technical writing and long-form content, details like heading navigation, code presentation, image handling, and progress indication matter more than people often expect.

AI summaries: the most interesting part of the project

The part I find most interesting in the current version is the summary system.

This is not just “call an LLM and display a summary.” Instead, the project now uses a two-layer model:

• code summary
• ai summary

Why two layers?

Because a production-friendly system should not depend entirely on AI.

If summaries are fully AI-dependent, two problems appear immediately:

1. generation latency becomes unpredictable
2. article rendering becomes vulnerable to AI failures

So the current design is:

• code summary is generated synchronously and stored immediately
• ai summary is generated asynchronously and written back later

That means article pages always prioritize loading the actual content. AI is an enhancement layer, not a prerequisite.

How AI summary works now

When a reader opens an article and AI summaries are enabled, if that article does not yet have an AI summary:

• the backend immediately enqueues an AI summary job
• the frontend shows a “generating” state
• the article itself still loads normally
• once the summary is ready, the frontend polls and updates automatically

That makes the feature feel live and responsive without making the page hostage to the LLM response.

Title is now part of the AI context

This is a small but important improvement.

The AI summary input no longer uses only the article body. It now includes:

• the article title
• the article content

In practice, the title often contains the clearest expression of topic and intent. If the model sees only the body, it may generate a weaker or less focused summary. Including the title makes the result much more stable.

Why code summaries still matter

Because availability matters.

The code summary layer acts as a practical fallback:

• it guarantees that list pages always have something to display
• it guarantees that article pages do not depend on external AI services
• it guarantees that the system still works when AI is disabled, slow, or failing

So this is not a story of “AI replacing the old system.” It is a story of AI being added on top of a reliable baseline.

That feels much closer to a real publishing product than simply wiring in an LLM endpoint.

Stability and deployment improvements

A project like this does not stop at frontend features. Once it starts running for real, backend and deployment issues matter just as much.

Recent improvements in that area include:

• internal management of the summary SQLite database
• persistent summary storage in Docker deployments
• avoiding full AI summary regeneration after container rebuilds
• fixing SQLITE_BUSY / database locked issues under concurrent summary activity

These are not flashy changes, but they are the difference between a demo feature and a usable long-running system.

Who is this for?

I think trilium-blog is especially useful for people who:

• already write long-form notes or articles in Trilium
• want to publish selected knowledge-base content publicly
• prefer self-hosted, lightweight systems
• want AI-enhanced content workflows without making AI a hard dependency

If your writing already lives inside Trilium, the point of this project is not “learn a new CMS.” The point is:

keep your existing writing workflow, but upgrade the publishing experience.

Where it can go next

The current version already feels like a solid publishing layer, but there is still a lot of room to grow:

• smarter AI summary refresh behavior
• richer featured-content layouts
• stronger search ranking and filtering
• better SEO and social sharing metadata
• a more mature theming system

But even now, trilium-blog is no longer just a tool for exporting notes. It is becoming a real publishing surface built around Trilium’s writing model.

Closing thoughts

What I like most about this project is that it stays relatively light.

It does not try to replace Trilium, and it does not try to force a second editorial workflow. Instead, it respects the way content is already being created, and then focuses on the parts that make publishing and reading actually work.

That is what gives tools like this long-term value.

If you already use Trilium and want a more natural way to publish the notes you care about, trilium-blog is starting to feel like a very good place to begin.