Building an owned technical publication
A technical publication should be as dependable as the systems it describes. For Ireti, that means the source, build, domain, and deployment path remain under our control.
The publishing contract
Our articles begin as Markdown or MDX in Git. A production build turns that content into static HTML, CSS, JavaScript, feeds, and metadata. Azure Static Web Apps serves the resulting artifact at the canonical domain:
Git content -> Docusaurus build -> build/ -> Azure Static Web Apps
This arrangement gives the publication a few useful properties:
- Every content change has reviewable history.
- The generated site can be tested before release.
- Hosting can change without moving the source of truth.
- Readers receive cacheable static pages without a permanent application server.
Why Docusaurus
Docusaurus supplies the publication mechanics we need without introducing a hosted content platform. Authors, topics, archives, pagination, reading time, RSS, Atom, JSON Feed, sitemap generation, and MDX are part of the repository build.
The framework is not the owner of the content. It is a replaceable compiler for an artifact we own.
The marketing website links to this publication, but article content and releases remain in a separate repository. A blog release cannot accidentally modify the main Ireti.cloud application.
Syndication without surrendering the canonical URL
Selected articles can also appear on DEV Community, where the published copy declares its original blog.ireti.cloud URL as canonical. LinkedIn receives a short introduction and a link back to the original article.
That distinction matters: syndication expands distribution, while the first-party publication remains the durable record.
What comes next
Future articles will focus on the engineering decisions behind financial infrastructure, healthcare delivery platforms, cloud systems, and applied AI. We will favor concrete architecture, measured tradeoffs, and lessons that can be reused beyond a single product.