The smartest CMS. Because it works with the smartest AI.The smartest CMS. Because it works with the smartest AI.

Visor is built by Xtremax, and its foundations come from technology deployed and tested running Singapore Government websites, where services have to stay secure, governed, and available through periods of intense public demand. The platform is shaped around those requirements: static delivery that absorbs traffic spikes, content that moves through approvals, multiple sites operating under one standard, and deployment to cloud or intranet. Xtremax professional services can also work alongside your team on the build.

Yes. Visor is engineered for multisite management, letting you launch and manage multiple websites from a single hub. The Sites module is the core tenant data store, where each site entry represents a tenant and holds its own configuration, including CMS URL, developer preview URL, active theme, and frontend linkage. Settings modules are restricted to Admin roles only, and a site must be created before its frontend can be configured.

Your team designs and builds with the AI tools they prefer, such as Claude. DaaS (Data as a Service) is the backend behind every Visor site, holding its content, settings, roles, and permissions. AI tools connect to it through an MCP server, so they work from the real content model and permissions instead of guessing. That way a site built with AI, or one already live, can be brought onto the platform and into the CMS without a manual rebuild. AI can then prepare new sites, new pages, and edits to existing content. The connection is read-only by default, and anything AI prepares goes live only after a person reviews and approves it. For developers, skills such as convert-html run in Claude Code, Antigravity, VS Code, or Kiro and turn a design into Visor's theme, layouts, and widgets.

Every Visor website has built-in ways for visitors to say what works for them and what doesn't. AI can read that feedback alongside the site's content, suggest improvements, and prepare the changes. A person reviews and approves each one, and it goes through the same workflow as any other change.

No. Page Builder is the core module for content editors, providing a built-in drag-and-drop interface for assembling pages with widgets and acting as the central configuration point for slugs, layouts, status, and content blocks. Editors build, update, preview, and publish page content without writing code. Widgets are dragged into placeholder areas and configured through a settings form on each widget.

Editors can only use what developers have built and registered. Widgets are React components that receive content from Visor, split into platform widgets shipped with the template and site widgets added per project. Each widget exports a configuration object that Visor Studio uses to register it, and the fields defined in that configuration are what appear in the editor's form. A corresponding widget definition must be created in Visor Studio before editors can add it to pages through Page Builder.

Yes, and without changing application code. A workflow definition is a JSON-based configuration describing the states and transitions content can move through, for example Draft to Review to Approved to Published, and acts as a reusable template that can be assigned to one or more content collections. You can model anything from a simple two-step approval to a complex multi-stage editorial pipeline. States and actions are composed in a drag-and-drop builder that generates the JSON automatically, and a workflow assignment then activates the definition for a collection.

Static pages need far fewer servers. New websites join the existing platform, so each one doesn't need its own setup. And because security is part of how the platform works, there is much less patching and extra tooling to pay for over time.

Visor is headless, so content management is separate from the frontend. The DSS Base Template is a Next.js application that acts as the frontend head, fetching content from Visor Studio through the DaaS API, resolving layouts and widgets from configuration, and rendering the final HTML. It follows a config-driven rendering pattern where a route resolves its page and layout config from Visor, the layout renders placeholder zones, and each placeholder renders its assigned widgets. Three rendering modes are supported, SSR, SSG, and ISR, switched through an environment variable and a prebuild script.

Edits are stored as versioned records first, and the item is promoted to the main version when you transition its status, for example to Published. Publishing Execution then gives a read-only log of every static site generation build trigger on the platform, recording when each build ran and its context, which is useful for monitoring build activity. For pre-launch review, Dev Mode routes the Visor preview to your local Next.js server instead of the live deployment, so content changes appear in real time during development.