Reference architectures

These are recommended set-ups, not customer stories. Pick the pattern closest to yours and adapt it.

1. Multi-brand group

A holding company with several brand websites, each with its own team.

Organization: Group
├── Site: brand-a   (Development, Production)   editors: Brand A team
├── Site: brand-b   (Development, Production)   editors: Brand B team
└── Site: brand-c   (Development, Production)   editors: Brand C team
Approvers: group digital team (organization admins) + one reviewer per brand

• One organization, one site per brand. Content, media, tokens and people never cross between sites.
• Each brand keeps its own website code and contract, with its own components and design tokens. Atlas never forces a shared design.
• Brand editors get roles on their site only. The group digital team approves Production releases.
• Each website has its own delivery tokens and webhooks, so one brand’s deploy or outage does not affect another.

2. Regulated or approval-heavy company

Financial, healthcare, energy or government-adjacent teams, where every public change needs sign-off.

• Editors and marketers draft; a reviewer/publisher publishes in Development; a smaller group approves Production releases.
• Turn on phone approval for sensitive actions.
• Every release is checked (contract in sync, no publish problems, site health, recent backup) and signed. Rollback is one action.
• Export the audit log for your compliance records.
• Agree lead retention rules before go-live, and note that retention and CRM push cover Development leads only today.
• Confirm hosting location and data retention with us before signing (see Security).

3. Agency running client websites

An agency builds and maintains sites for several clients.

• Prefer one organization per client, so each client owns its data, people and plan. Agency staff are invited as members.
• Build a library of your own components in code and reuse it across client contracts, with client-specific design tokens.
• Use an AI coding agent over MCP for the content migration; the client’s reviewer publishes.
• Hand-over is safe: the client’s editors can only change typed fields, never the code.

4. Single corporate website

One company website, a small marketing team and an outside developer.

• One organization, one site. The developer connects the website and writes the contract once.
• Marketing edits pages, news and translations; the marketing lead approves Production releases.
• The developer is only needed for new components or page types.

What all patterns share

• Your website code, hosting and deploys stay with you.
• Development first; Production only through an approved release.
• A built-in fallback so the site stays up if Atlas is unreachable.
• Delivery tokens on the server, rotated before they expire.