Open source · GO · BSD-3-Clause
The AI-native static site generator
Build fast, hardened sites from Markdown and SQL databases. AI runs at build time, an MCP server drives SSG from your agent, and every page ships clean Markdown for the tools that read it — a 5 000-post site builds in 2.3 seconds, with nothing sent to the browser that does not have to be.
Why ssg
Built for speed, data and the AI web
-
Builds in seconds, not minutes
A 5 000-post site builds in 2.3 seconds — 5.25× faster than the previous release, after two costs that only appeared at scale were removed. Output is byte-identical however many workers run, so a shorter CI job is the only difference.
-
Reads your database directly
MySQL, MariaDB, PostgreSQL and SQLite are content sources like any other — no export step and no glue script. Queries run read-only at build time, so the database stays behind your firewall and never sits in the request path.
-
Built for AI agents, end to end
AI runs at build time — summaries, tags and related posts, cached by content hash and never reaching the browser. An MCP server lets agents create and edit content, and every page publishes clean Markdown and an llms.txt index for the tools that read it.
Deploys natively to
Guides
Documentation
Every guide below is built from this repository's own docs/
folder through content_sources — this site is its own
integration test.
-
Markdown for agents & AI search
SSG is Markdown-native, so it can hand language models and AI crawlers the authored Markdown of every page instead of making them parse rendered HTML. This…
-
Typed content components
A component is a directory with a contract, and a call that carries its arguments. Content asks for a thing, with the details that make it this thing, and the…
-
Configuration reference
SSG can be configured with command-line flags or a YAML, TOML or JSON file. This guide explains the configuration model and advanced features. The exhaustive…
-
Content guide
This document is the canonical reference for local Markdown content in SSG. For configuration keys, see CONFIGURATION.md. For values exposed to themes, see…
-
Running several projects at once
ssg --watch serves one project. Four sites means four terminals, four scrollbacks and four things to remember to restart. ssg daemon is that, declared once.
-
Deployment guide
SSG can package a generated site, publish it directly, or run as a GitHub Action. Deployment always happens after generation and enabled post-processing, so…
24 guides in total — the full directory is in the footer below.
Updates
Latest posts
-
The Client Wants to Fix a Typo
1.8.60 is about the work an agency does between builds: letting a client fix their own headline, and a GTM install that was only ever half there.
-
The Paragraph You Clicked Is Not in the File
Click-to-edit is easy to build and hard to make safe. Here is the rule that decides which paragraph a click means, and why the editor sometimes refuses to guess.
-
What Breaks If I Change This?
We built an incremental build for 1.8.60. It made a five-thousand-page site five per cent faster. Here is why we shipped it anyway, and what it is actually for.
-
One Sitemap Per Site Does Not Scale to Forty Clients
An agency has a different relationship with sitemap.xml than a site owner. Split sitemaps answer 'is it indexed' per section, without forty dashboards.
-
The Build Was Green and the Site Was Wrong
Almost every fix in four releases came from one place: a third-party crawler, weeks after a build that reported success. What those failures had in common.
-
Every January, Every Footer Is Wrong
A generator that reads the clock cannot promise the same bytes twice. Which is why the copyright year in your footer is a harder problem than it looks.