How the platform is built
Static public pages are delivered through a content network. Separate services handle forms, publishing and client access.
A visitor's request
Every page is generated ahead of time and served as a static file from a content delivery network. Ordinary public page requests do not query a CMS or an application database. Forms and other platform actions use separate service endpoints.
- Static output, built from a version-controlled repository.
- No server-side rendering at request time, and no user session on the public site.
- Form submissions post to a separate, isolated endpoint that writes durably before any downstream call.
Tenancy and isolation
Platform services use site identifiers and tenant-scoped access controls to separate client data. Console and assistant permissions are checked when actions are performed.
Infrastructure policies and application tests support that separation. The documented architecture describes credential scope and lifetime for the relevant service.
Change management and rollback
Every change is a version-controlled commit that passes a gate before publishing. Platform changes and content changes are versioned. Recovery procedures identify which version is restored and how current content is retained or rebuilt. Compatibility is checked before republishing.
- Gates cover accessibility, contrast, performance budgets, headers, links and structured data.
- A failed gate stops the publish and names what failed.
Sub-processors
Infrastructure runs on Amazon Web Services and Cloudflare. What each processes, and on what basis, is published on the trust pages and in the data processing terms of your agreement.
Records you receive
- Security-questionnaire assistance where included in your plan or agreement.
- A current sub-processor list with what each one does.
- Data processing terms in your agreement, covering retention, breach notification and notice of sub-processor changes. On Business, a separately signed data processing agreement on request.