The new carmencloud.com is live. The visible change is a new site, but the more important change sits behind it: Carmen Cloud now has a clearer separation between content management, the public production frontend and the application services customers use every day.
We kept WordPress as the familiar editorial environment. At the same time, the public site no longer depends on a traditional WordPress runtime for every request. Authentication, AI-assisted documentation, forms and backend processes are connected as independent services, while the production frontend can be published as a static experience.
That architectural shift happened alongside a broader redesign of Carmen Cloud itself. Workspaces are now real collaboration and billing boundaries, API keys can be managed per integration, and usage can be understood at both workspace and key level. The result is not just a faster website. It is a more practical foundation for teams building production systems with recognition APIs.
The old model had reached its limits
The earlier Carmen Cloud account model grew from a simpler product. A user, a company, a subscription, a workspace and an API credential were treated too much like one combined entity. That was understandable when the typical journey was one person creating one account and obtaining one key. It became restrictive as customers moved from experiments to shared, long-running integrations.
Real teams need more flexibility. A developer may work across several customer or environment-specific contexts. Finance may need invoice access without operational permissions. A production backend and a staging integration should not have to share the same credential. Rotating a key should not interrupt unrelated systems, and investigating unexpected usage should not begin with guesswork about which integration generated it.
These are not cosmetic dashboard issues. They are signs that identity, access, billing and consumption need separate, explicit boundaries.
Workspaces are now the organizing boundary
The redesigned model starts with the workspace. A user can own or be invited to multiple workspaces, and access can be granted according to role. Owners retain control of the workspace, administrators can manage operational settings, and billing users can work with subscriptions, credit purchases and invoices without receiving every other permission.
Each workspace brings together the resources that belong to one customer context or operational boundary:
- subscriptions and prepaid credits;
- API keys and their permissions;
- usage data;
- stored recognition events and hook settings;
- the people who are allowed to manage them.
This gives companies a clean way to separate clients, products, environments or business units while still allowing the same person to participate in more than one workspace. It also makes the commercial model easier to understand: subscriptions and billing belong to the workspace that consumes the service, not implicitly to one individual user.
