Builder and swarm

Two products sit on this shelf. The site builder is how we intend to hand a customer a finished site they can edit. The swarm console is the operator’s screen for the Docker Swarm that already serves the group’s public sites, including this one. That console will be published at swarm.cpt-technologies.com.

The builder is the studio’s answer to a familiar trap. A canvas site is easy until someone drags it into a mess, or wants a new look and has to copy every sentence by hand. A headless CMS avoids that and then waits on a developer for every layout change. The product in between is a small set of finished templates, and content that is stored as what it means — a hero, a service, a testimonial, a post — rather than as a pile of boxes.

A signed-in editor sees the page and a side panel. They change words and pictures. They do not change the design. An author can add a page or a service. An editor can update what is already there and cannot create new ones. An owner can switch template. The switch is a refit: matching regions keep their documents, empty regions stay empty, and documents the new template cannot show are parked and listed. Nothing is deleted. The public site does not change until someone who is allowed to publish does so. The everyday path is an emailed link, a named site, a template that arrives with sample copy, and publish. Public sites in the first version live on a subdomain of the builder.

The swarm console is signed in. The dashboard shows services, volumes, containers, disk, and a live feed of what the cluster is doing. Domain routing sends each public hostname to the service that should answer it. Certificates are issued and renewed from the same place. An operator can deploy a workload, read logs, scale, restart, or roll back. A desired state is stored and brought back into line when a service goes missing or the image drifts. CPU and memory can raise or lower the replica count, with a cooldown so it does not flap.

An operator can also type the change in plain English. The assistant, Grok by default, returns a tool plan. Shadow mode records the plan and leaves the cluster alone. Human review waits for an approval before a mutating step. Autonomous mode may carry a lower-risk plan out, under a rate cap, and a high-risk step such as a delete or a rollback still waits for a person. A dry run simulates and changes nothing. Viewers can read plans. Only an admin can submit or approve one. Someone who has asked for texts on a service is told when its state changes. An admin can be told by text when a recommendation is waiting.

The builder is fully specified and in development; the screens shown here follow that specification directly. The swarm console is built and already hosts these sites today, moving shortly to swarm.cpt-technologies.com.