OPS Content Platform
How a Rust CLI validates Markdown content, keeps private drafts out of the public build and produces a static website with RSS and a dry-run-first deployment path.
Problem
Technical notes, drafts and publishing steps can easily end up in separate tools. That makes it difficult to review one source, keep private material out of the public build and reproduce the final site.
Platform today
The platform now focuses exclusively on the website. Markdown files with TOML frontmatter are the source of truth. They are stored in content/ and grouped into private ideas and drafts or public-facing articles, notes, projects and pages.
A Rust CLI creates content from templates, validates the content model, shows review prompts and builds a responsive static website. The same reviewed sources generate detail pages, listings, topic pages and the RSS feed. There is no social-media publishing integration.
The public website is available at ops.kiepe.dev.
Workflow 1: capture and develop an idea
An early thought can remain private while it is being developed:
ops-content new idea "Working title"
ops-content new draft --from-idea <idea-id>
ops-content review <draft-id>Ideas and drafts are deliberately excluded from the website. This makes it possible to collect context, open questions and source requirements before a public format is chosen.
Workflow 2: create website content
The CLI provides separate templates for the main public formats:
ops-content new article "Detailed technical topic"
ops-content new note "Short operational check"
ops-content new project "Project name"An article explains a topic in depth, a note captures one concise operational lesson, and a project page documents a problem, approach, working state and limitations. Existing fixed pages such as About, Imprint and Privacy are maintained directly in content/pages/.
After editing, the author runs validate and review, checks facts and sensitive details, then deliberately changes the status. Only reviewed, ready, published and archived content crosses the public website boundary.
Workflow 3: build and inspect the website
ops-content validate
ops-content build-siteThe build recreates site/public/ from the source files. Before publication, the generated start page, navigation, content pages, topic pages, legal pages, mobile layout and RSS feed can be inspected locally. Generated files are not committed.
Workflow 4: publish with a controlled deployment
Production deployment is a separate, explicit operation. The infrastructure wrapper first validates the sources, runs tests, builds the site and verifies required artifacts. A deployment dry-run shows the exact synchronization changes without modifying the server:
scripts/ops-content-platform.sh deploy-site --dry-runOnly after reviewing that output is the production deployment run without --dry-run. The deployment synchronizes the static build and then verifies DNS plus selected public pages against the local artifacts.
What works
- Content creation, validation, review guidance and static-site generation are available through one Rust CLI.
- A shared visibility gate is applied consistently to detail pages, listings, topics and RSS.
- The generated layout covers the complete public site, including legal pages and topic navigation.
- Dry-run and production deployment paths use the same verified build.
- Production smoke tests compare selected public artifacts with the local output after deployment.
Examples published through the platform include a compact DNS check, the detailed workflows for adopting an existing nginx configuration with Ansible and operating SSH securely on WSL2, and the production case study of modernizing Relevante Ökonomik.
Limitations
- Editing and review remain file- and command-line based; there is no browser admin interface.
- Status changes and editorial approval are intentionally manual.
- Deployment is environment-specific rather than a general CI/CD service.
Next improvements
- Add more real articles, notes and project pages.
- Extend review assistance where recurring editorial checks justify it.
Operational lesson
A reproducible build is only useful when the publication boundary is explicit. In this platform, private ideas and drafts stay outside the generated site, and only content with a documented public status crosses that boundary. Validation happens before deployment, and the production change remains a separate, deliberate operation.