November 2026 update. I wrote the first version of this post while containerizing Antsand was still a plan. The useful question now is not whether containers are fashionable. It is what became easier to build, what still needs care, and how an independent website comes out of the system.
What changed
Antsand's core application now runs in containers on EC2. That gives us a more repeatable way to assemble PHP, the databases, the web server, and supporting services. It does not move us off AWS by itself, and a container is not a backup, a security boundary, or a deployment test.
The more interesting change is the SaaS factory pattern growing around that application. We create content and choose the pages, features, and branding for a site; shared templates and styles turn those choices into an independent HMVC website. That site has its own routes and runtime data. A visitor does not need the Antsand editor to render each page.
ShivasNotes is where this has become concrete for us: articles, member pages, protected reading, comments, and commerce are being developed against a generated site. This Antsand blog is moving through the same factory pattern. We can reuse the machinery without forcing two brands to have the same pages, voice, or access rules.
The boundary that matters
There are two kinds of state in this system. A generated template, stylesheet, or route can be rebuilt. A reader's account, comment, purchase, or uploaded file cannot be treated as disposable build output. That distinction changes how we deploy. We need to know what the factory publishes, what each site owns, and what must survive regeneration before pressing a button labelled deploy.
It also changes how I work with agents. I can ask an agent to prepare a page section or run a test, but a plausible answer is not release evidence. The useful artifact is a reviewable change: source revision, generated output, test result, known skips, and a rollback route. When a dependency is missing, I would rather see not certified than a green-looking summary.
What containers did not solve
The original post talked about moving to on-premises servers and adding more infrastructure. Those are still choices, not completed migrations. Data sovereignty depends on where data and backups live, who can access them, and whether we can actually restore the service somewhere else. Swapping a cloud VM for a box in my office would not answer those questions on its own.
The same caution applies to one-click generation. It is easy to demonstrate a fresh site. The harder test is regenerating a populated one without losing accounts, comments, entitlements, or links people already use. That is the work I want to keep showing here: not only the happy path, but the failure and recovery paths too.
Why I am writing this down
Antsand began as software I needed for my own projects. The factory, its design system, and the release process are becoming a practical way to build internal platforms without starting from zero every time. That is the work behind our consulting story, not a claim that Antsand is already a mass-market website builder.
If you run a small team with several products or sites, the question may sound familiar: what should be shared, what must stay independent, and who is responsible when a deployment goes wrong? I will use this blog to show the decisions and the evidence as the system evolves.