What is most worth mentioning about this phase is not that a few more features were added, but that the platform's form has changed.
In the past it was one system installed on customer servers. Now there are two: one is still installed on customer servers and handles content, pages, and APIs; the other is on our side and handles license issuance, customer and instance ledgers, release packages and updates, official managed storage, and official AI. The two systems cooperate through signed APIs, are independent, and do not share a database.
This is not architectural fastidiousness. Whether to split them depends on whether three things are settled: whether licenses can be revoked, whether versions can be delivered, and whether problems can be diagnosed. A system that goes dark after installation cannot do these three things, so we built these three things first.
I. Why Divide It into Two Halves
The biggest problem with a system installed on customer servers is that it is invisible after delivery. The domain changed, the certificate expired, the disk filled up, the version has been stuck at six months ago—if the customer doesn't tell us, we don't know. By the time we know, it has usually already affected the business.
The central console addresses exactly this gap. When a customer instance is activated, it exchanges an activation code for a license file, and the central console derives the storage prefix from the customer profile; after that, the instance periodically reports instance information—domain, IP, version, and health—forming a ledger. This is not surveillance; it is making sure someone is still responsible after delivery.
A few specific practices illustrate the measure of this setup:
Licensing remains offline. A customer instance can run even when disconnected from the network and does not depend on our services running. The online part only handles activation, renewal, and update verification; it does not perform real-time control. This is deliberate: binding a customer's critical business to our availability is an irresponsible way to deliver.
Managed storage uses temporary credentials. A customer instance exchanges a signature for STS temporary security credentials, with permissions narrowed to the customer's own prefix, and uploads directly to the official storage bucket. The credentials are temporary and the bucket is isolated, so we cannot see the customer's other files.
Official AI passes through four gates. License signature verification, request signature headers, feature bits, and credit balance, plus an IP rate limit layer. If any one fails, the request stops outside the door.
Updates go through a mailbox, not push. The central console manages release packages; customer instances retrieve upgrade requests from the update mailbox, and scripts on the host machine execute them. When to upgrade and whether to upgrade are decided by the customer.
II. Four Things Added on the Product Side
Member system. The member runtime is attached to frontend sites by script injection; the login entry is a draggable, snap-to-edge floating ball, and the login panel is a right-side drawer. Why not embed it in the page structure? Because customers' frontends are customized individually, and the member entry cannot require them to redesign their layouts—the capability must be attachable, rather than requiring the page to make way for it.
Template version repository. Online templates, template editor, preview, copy, plus three coexisting tiers: development slot, production slot, and historical versions. A redesign can first be done in the development slot, previewed, and then switched; if the switch is wrong, it can be rolled back to the previous version. We use this chain every day when changing our own official website, and it is also the foundation of "conversation as redesign" mentioned in the previous article.
Digital asset statistics. Work statistics, file combinations, website visits, API and MCP calls, crawler statistics, and log archiving were completed across eight phases end to end, with a data dashboard configured in the admin panel. The reason for doing this is simple: when customers ask "Is this site actually useful?", we cannot always answer only "It looks okay."
Payment signature verification was moved to a new scheme. In 0.9.42, WeChat Pay signature verification was switched from "platform certificate" to "WeChat Pay public key", with both sides modified in sync, and the old scheme completely removed, with no fallback left. Leaving a fallback sounds safe, but in reality it means maintaining two paths, and sooner or later one of them will go untested—and when something really goes wrong, the broken one will certainly be the untested one. The cost should also be stated clearly: existing sites that have already configured a platform certificate must go to "Payment Settings" in the admin panel and change to the public key and public key ID; otherwise WeChat callbacks will still fail signature verification and orders will remain unpaid. We have notified each of these customers one by one.
Also fixed a small issue along the way, but the trade-off is worth noting. Recycle bin thumbnails used to go through an authenticated relay API, and kept spinning in production. Now they are direct: deletion in object storage copies the file to the trash/ prefix in the same bucket before deleting the original, and the copy remains directly accessible. The cost is that the recycle bin address can be derived from the original address—deleted files can theoretically be guessed. We accept this cost because the recycle bin itself has the semantics of "recoverable"; trading a bit of knowability for no more endless spinning is worth it.
III. Product Maturity Is Hidden in the Deployment Chain
This part does not produce any features, but it determines whether "going live" is an adventure or a process.
The deployment script now runs in this order: environment check, with random keys automatically generated for missing configuration; dependency verification, probing software source availability before deciding whether to clean and reinstall, avoiding the intermediate state of "dependencies deleted but unable to install"; pre-deployment checks for major version, disk space, memory, and swap; build; automatic backup before migration, with destructive statements pre-checked to block table-dropping operations, and failed migrations automatically marked for rollback and retried once; idempotent injection of nginx configuration, generating a copy based on this site's port to avoid cross-site issues when multiple sites share a machine; finally restart, poll the API to verify whether all migrations have been applied, and clear the page cache.
Two details are worth mentioning separately: the frontend build first outputs dist.new, and only after verifying that index.html exists does it replace dist as a whole—historically, an interrupted build left half a product and directly caused a 403 in the admin panel; the owner of the runtime directory is corrected during deployment—directories created by root cause the application to fail when writing to disk, yet the error reported is a 500.
These were all learned from incidents. Product maturity is not reflected in the feature list; it is reflected in these places.
IV. The Ledger for This Phase
Digital Platform 0.9.42: 59 database migrations, 54 service files, 27 system submodules, and 52 admin pages; the central console: 39 migrations, 16 modules, 20 pages, and 23 services.
Testing: 775 test cases, 775 passed; all 105 test cases for the central console passed. The numbers look ordinary, but for a system that is constantly changing, only when the full regression suite runs cleanly do we dare release a version.
V. Next Steps
The platform side will continue in three directions: a platform-level AI capability center, an external canvas tool that interoperates with the content system through APIs, and an online template service for CRM. All three are still in progress; I will write about them separately once they take shape.
Afterword
Looking back at this phase, most of what was done is not on the surface: licensing, ledgers, release packages, credentials, deployment scripts, and migration backups. They do not produce good-looking screenshots, but they determine whether this platform can be used over the long term.
Our understanding of "productization" has only three points: changes can be rolled back, operations can be audited, and versions can be updated. Only when these three hold can we talk about letting customers operate on their own—after all, the premise of handing a system over to others is that problems can be brought back under control.
This road is still being traveled, and progress will continue to be written here.