> ## Content Index
> Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# A new home for this publication
- URL: https://www.mohammadsiddiqui.com/a-new-home-for-this-publication/
- Published: 2026-08-04T12:55:54.000Z
- Updated: 2026-08-29T04:24:47.000Z
- Author: Mohammad Siddiqui
- Tags: Newsletter

*On owning your platform, and what comes next.*

This publication now lives at mohammadsiddiqui.com my own domain, running on Ghost. It is a move I had been considering for a while, and I am glad I made it.

Here is why it matters, and what changes from here.

**The domain is the asset**

For the last stretch I have been publishing VCF architecture material at an auto-generated subdomain on a hosted platform. It worked. But every URL I published, every link shared in a Slack thread or bookmarked by someone debugging an upgrade at 2am, pointed at an address I did not own.

That is a design decision, and I had made it by default rather than deliberately.

Now the domain is mine. If the platform underneath ever stops suiting me, I point the DNS somewhere else and every link keeps working. The content moves; the address stays. That is the difference between owning a presence and renting one.

**Posts are web pages again**

This is the change I am most pleased about.

Technical writing has a long tail. The people who benefit most from a detailed write-up on a VCF upgrade path are not the ones reading it the week it publishes they are the ones who hit that exact problem eighteen months later and search for the error string. That traffic only finds you if your posts are indexable web pages accumulating authority against a stable domain.

Ghost is a CMS that also sends email, rather than a newsletter tool that also has a website. Every post here is a full page on my domain, structured for search, with proper code block rendering and the formatting that technical content actually needs. The newsletter goes out at the same time, to anyone who wants it in their inbox.

Same material, better foundations.

**Export is a first-class function**

I can pull my complete content archive and member list at any time, in open formats, without asking anyone's permission. Ghost is open source, so if the managed service ever stops fitting, I can run it myself on infrastructure I control.

I want to be clear about why this matters to me, because it is not paranoia about any particular vendor.

Recently I ran into a support issue on the previous platform that left me unable to reach my account settings. It is being worked through, and I have no interest in litigating it here. But it prompted a question I had genuinely never asked about my own publishing setup: *if this stopped working tomorrow, what is my recovery path?*

I did not have a good answer. That is not the platform's fault it is mine. I have asked exactly that question in customer design reviews for years, and I had simply never turned it on myself.

**The architecture point, briefly**

Since this is a publication about enterprise architecture, let me put it in those terms.

Every platform you build on is a dependency. The useful question is not whether the vendor is competent most are but what your position looks like when a component fails and you need to recover without their cooperation. Where does your data live? Can you retrieve it unilaterally? Does your recovery path share a failure domain with the thing it recovers?

We design against this deliberately in enterprise identity work: break-glass accounts, out-of-band recovery, secondary paths that do not depend on the primary being healthy. The principle generalises well beyond identity.

If you publish anywhere a newsletter, a blog, a portfolio it is worth ten minutes this week. Export your content. Export your subscriber list. Confirm you could point a domain you own at your site. If any of the three is not possible today, that is worth knowing before you need it rather than after.

**What is not changing**

The content. VMware Cloud Foundation architecture and operations, design decisions, upgrade paths, and lessons from running this at scale in large enterprise environments. Detailed technical write-ups rather than product announcements. The archive is being republished here, and new material continues.

If you followed the old feed, please subscribe here directly I am not able to bring subscribers across automatically, so it needs the few seconds from you. It remains free.

And if there is a design problem you would like covered, or you think I have got something wrong, reply to any post. I read everything, and corrections from people running this in production are the most useful mail I get.

Thanks for reading. Good to have you here.

Mohammad Siddiqui