Architecture

Showly's public architecture is the delivery lifecycle customers can rely on. Infrastructure providers, regions, network topology, resource names, and internal service boundaries are implementation details and are intentionally not part of this documentation.

The delivery lifecycle

1. Connect a workspace. A human connects a site and decides which teammates, API tokens, and MCP clients may access it.
2. Prepare a change. An agent or integration reads only the context allowed by its scopes, proposes a plan, and submits the changed files.
3. Create a private Preview. Showly builds the change in an isolated environment, runs the requested checks, and returns a protected Preview URL. The current Live version is not changed.
4. Review and approve. A human reviews the Preview, diff, and check results. Workspaces with approval policies must complete those policies before publishing.
5. Publish Live. Showly promotes the reviewed version and records the action in the audit history. Previous versions remain available for rollback according to the workspace's retention and plan limits.

flowchart LR
  accTitle: Showly delivery architecture
  accDescr: Team members, agents, and automations enter through scoped access surfaces. Changes move through workspace authorization, a private Preview, human approval, Live publishing, and version history.

  subgraph access["Access surfaces"]
    direction TB
    member["Team member"] --> web["Showly Web"]
    agent["Agent"] --> mcp["MCP tools"]
    automation["Automation"] --> api["REST API"]
  end

  subgraph workspace["Workspace boundary"]
    direction TB
    auth["Scoped authorization"]
    change["Change plan and files"]
    preview["Private Preview and checks"]
    gate{"Human confirmation or approval"}
    auth --> change --> preview --> gate
  end

  subgraph delivery["Managed delivery"]
    direction TB
    live["Live site"]
    versions["Version history"]
    live --> versions
    versions -->|"Rollback"| live
  end

  web --> auth
  mcp --> auth
  api --> auth
  gate -->|"Approved"| live
  gate -->|"Changes requested"| change

Product boundaries

Workspace boundary. Sites, deployments, tokens, roles, and audit records belong to a workspace. Requests are authorized against that workspace before data is returned or changed.

Preview boundary. A Preview is separate from the Live site and is access-controlled. Creating or updating a Preview does not publish it.

Publish boundary. Production-changing actions require an explicit confirmation or the workspace's approval workflow. An agent cannot bypass that gate.

Version boundary. Each publish points to a specific reviewed version. Rollback selects a previous version rather than editing the current Live output in place.

Authentication and audit

• People use the Showly web application with their user session.
• Scripts use personal access tokens; agents use scoped MCP tokens.
• Tokens are limited to the workspace, resources, and actions granted to them.
• Agents and integrations do not receive Showly's hosting credentials.
• Read, build, publish, rollback, and destructive actions are recorded in the audit history when the relevant surface supports them.

See MCP scopes and tokens and RBAC and approvals for the public authorization contract.

Hosting and data location

Showly is a managed service. Its cloud provider, deployment region, network layout, storage technology, and service topology may change without changing the public API or delivery workflow.

Do not use repository code, response metadata, DNS records, or historical documentation to infer a contractual hosting location. If your organization has data-residency, regulatory, or own-cloud requirements, confirm the currently available options with Showly before onboarding production data.

Deployment modes

Showly supports static output and selected server-rendered applications. The enabled modes and capabilities can vary by workspace and environment; use the deployment-target capabilities returned by the product as the source of truth. The underlying infrastructure is managed by Showly and is not a customer configuration surface.

Where to read next

• Site manifest — the customer-controlled build and runtime contract.
• Previews and publishing — the Preview and Live workflow.
• RBAC and approvals — access, confirmation, and approval rules.