# Deployment and trust boundaries

Deployment follows trust, resource and recovery boundaries, not the number of domains or pages; logically several platforms, physically a few controlled runtime units at first, extended step by step as security and load require.

> Document ID: MYRILUM-DOC-ARCH-026
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: 26e1b546d568520fc0d9c1fe54370bd2faae14b5ddd8b04e8ae0260197687df6
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/deployment-and-trust-boundaries

<a id="overview"></a>

## What this page covers

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

Logically several platforms; physically, a few controlled runtime units to begin with. This page states principles only; implementation details are not published.

<a id="boundaries-not-domains"></a>

## Deploy by boundary, not by domain

Deployment units are divided by trust level, resource needs and how they recover after a failure, not by how many domains or pages there are. The brand website, the customer application, the staff operations application, and the status page and documentation are separate entry points; the brand website carries only public information and cannot reach customer business data.

<a id="authenticated-connections"></a>

## Every connection is authenticated

Two components sitting side by side on a diagram does not mean they can reach each other on the network. Databases are never exposed directly to browsers or to arbitrary agents; every call is authenticated and allowed by resource-level permission.

<a id="isolation"></a>

## Customer runs, execution and release are isolated

Agents and tools run in restricted execution environments where files, network, processes and keys are kept apart, and work never depends on a web request staying open. Customer tasks cannot read production release credentials, and engineering automation never inherits full access to customer data. Keys and configuration are authorized separately by environment, purpose, service and region.

<a id="start-simple"></a>

## No premature complexity

At the start, having several platforms is no reason to duplicate accounts, payments and databases, and full microservices, active-active multi-cloud or self-built compute are not the default. Business services are organized by domain boundary and one domain never writes another domain's data directly; splitting happens only once measured load calls for it.

<a id="measure-first"></a>

## Choices are measured first

Backups go through restore drills and reconciliation; observability looks at technical operation, cost and business events together. Which providers are used, which regions host what, and what the capacity and availability targets are all get measured first; the architecture map does not decide them.

<a id="source"></a>

## Source

This page follows A26 of the MYRILUM architecture map v2.2. Under the public boundary it publishes principles only and carries no diagram. Related: “Unified experience and domain entry”; “Identity, authorization and access decisions”; “Regions, disaster recovery and exit”.

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.