The journal is live
susipere.de now has a publishing surface. How it is built, why it is static, and what it takes to get a post onto it.
Until today susipere.de had nowhere to put a finished piece of writing. The site was a single React application: every URL returned the same HTML shell, the same title, and a canonical pointing at the homepage. A post dropped onto that surface would have been invisible to search engines and would have rendered as SUSIPERE Platform in every social preview.
So the journal is deliberately not part of the React application.
How it is built
Every post is a markdown file. A dependency-free build script turns it into finished HTML — one file per post, with its own <title>, its own description, its own Open Graph fields, and a canonical pointing at that exact post.
content/en/2026-09-26-the-journal-is-live.md
-> /var/www/susipere-web/current/en/journal/the-journal-is-live/index.html
No router, no hydration, no additional service on the server. What gets served is a file on disk.
The reasons, in order of weight:
- Pre-rendered HTML is the requirement, not a side effect. Title, description and
canonicalhave to be in the source before JavaScript runs. - Cost per box. This machine shares RAM and disk with live customer work. Static files cost nothing but disk space.
- Rollback. Unpublishing a post means: remove the file, run the build. No service restarts.
If it has to stay up, take the boring option.
What this means for editorial
Create a file, fill in the frontmatter, run one command. The build refuses to publish anything if a required field is missing, a date is not YYYY-MM-DD, or a slug is used twice. A broken post cannot break the site.
Bilingual pairing works through translation_key: two files sharing a key are linked automatically as language variants — in the page header, in the hreflang tags, and in the sitemap.
This post is the smoke test for the surface. It can stay or go; either one is a single command.