AkurAI Platform is the boundary, not the bundle

AkurAI Platform is the front door for a private software suite. Its job is not to make every service look like one application. It gives the suite one public catalog, one managed-workspace plan, and a delivery path I can inspect.

The catalog says what exists

The Platform catalog is deliberately specific. Mail, Auth, VPN, PassVault, Drive, Notes, Tasks, Router, Monitor, DNS, Build, Framework and Platform are visible and available. CRM is present as a development entry, marked unavailable and without a public URL. The agent gateway is hidden and unavailable. That is more useful than a flat feature list because it keeps planned work from being sold as a service.

The live site follows the same rule. It reports 14 listed products and one managed workspace, and it declines to publish a suite-wide performance comparison without dated workload, hardware, command and revision evidence. The older portfolio card's roughly-30-MB claim does not meet that bar, so I am not repeating it here.

One release boundary

The recent work has been at the operational seam. The Platform itself serves through the shared AkurAI Framework binary, while its payment gateway is a separate compiled service. Its pipeline packages the pinned Framework artifact, the site bundle and the payment binary separately, then checks both local health endpoints and the public split edge during deployment.

The latest Platform revision, 5fb1e6e, is a small example of why that boundary is worth keeping honest. It changed the TypeScript check from bunx to bun x because the CI job's PATH did not provide bunx. The preceding run failed with bunx: command not found; the new revision passed verify and package before its production deployment started. That is not product work users see, but it is what keeps a release record meaningful: a green result has to prove the command actually existed in the environment that ran it.