Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.

Proposed Docker-first runtime topology

Historical CloudHub/tunnel alternative. ADR 0010 selects local Mac certification followed by hosted UI and cloud VPS with a BFF. The proposal below remains research, not the current deployment plan.

Status: revised proposal. The owner selected CloudHub for MuleSoft and confirmed no Anypoint access exists yet. ADR 0007 records that accepted hosting choice. Other runtime details and the proposed Internet-facing connectivity still require review in Choose the Docker-first runtime topology and external accounts.

This replaces the earlier standalone x86-host/Tailscale recommendation. It applies the accepted architecture and security contracts and does not provision or expose services. Runtime feasibility records source evidence and local observations.

Cloud alternative under review

The owner requested all services in the cloud with only the UI local. The local VM baseline booted but failed Mac-loopback containment, and is stopped. Cloud hosting is being compared before choosing the final runtime. The table below retains the earlier local proposal for comparison; it is not a provisioning instruction.

Component choices

Version families above are architectural choices, not floating installation instructions. Before setup, record exact compatible patches, image digests/architectures, lockfiles, Java/Node/SDK versions and license conditions in a version manifest. Reject unmaintained pins. React/Vite and UI library versions belong to the spec/setup compatibility matrix; no application dependencies are installed during discovery.

CloudHub prototype target

Use an Anypoint trial that includes CloudHub 2.0 when available. Verify its duration, eligible regions, deployment permissions, capacity, replicas and API-management capabilities after signup; do not assume free permanent capacity or private-space/VPN access. Start with one sandbox environment and one Mule application exposing separate logical experience/system contracts, at the smallest permitted capacity that passes the demo checks. Confirm runtime defaults explicitly rather than accepting an implicit Edge channel or Java version.

Private-space VPN is an alternative if the owner later obtains those entitlements and a compatible network gateway. A private space is not automatically a working VPN to the Mac. The initial recommendation avoids that additional infrastructure. If trial access or required API capabilities are unavailable, keep the integration gate blocked and present the concrete options instead of substituting a mock or buying capacity.

Use Anypoint CLI 4.x for agent-operated discovery, deployment and validation once access exists. The CLI does not create subscription entitlements or remove the need for initial account setup. Contentful remains SaaS; the local components retain their Docker-first proposal.

Mac resource and startup plan

Read-only checks found 64 GiB RAM, 16 logical CPUs, about 515 GiB available disk, and FileVault enabled. An unrelated stopped Colima profile has 2 CPUs, 4 GiB RAM and 10 GiB disk. Evaluate a separate atlas Lima ARM64 Linux VM using native Apple VZ and plain mode, with Docker Engine/Compose installed inside the guest. This replaces the Colima-profile candidate following the owner's request to investigate VM isolation. See Mac VM isolation for the unresolved network boundary and activation gates. Propose an initial 8 CPUs, 16 GiB RAM and 80 GiB virtual disk allocation. This is a starting budget to measure, not a verified minimum or performance promise. Keep the existing profile unchanged.

Use Docker Compose with named volumes, health checks, controlled migrations and idempotent synthetic seeding. Startup stages are local persistence/identity, engine/scanner/backend, then frontend and remote integration checks. Readiness must detect expired licenses, missing translations, stale scan signatures and unreachable identity/system dependencies. Developer-only partial profiles may run for focused tests, but the complete demo requires real Contentful release import and MuleSoft traversal.

Proposed network, identity, and storage protection

CloudHub cannot reach Mac [private service], Docker service names, or a private tailnet merely by deploying a Mule application. Recommend stable named HTTPS routes through a Cloudflare Tunnel connector running inside the dedicated Atlas VM. The connector initiates outbound connections. Published hostnames are reachable through Cloudflare's Internet edge; this is a change from the previous private-only proposal and remains subject to owner review. Cloudflare terminates edge TLS and is an additional processor in the synthetic demo path.

Use two routing boundaries. The backend hostname is protected by a Cloudflare Access Service Auth policy, default-deny routing and path allowlists, plus normal Atlas service/actor authorization. Mule supplies the Access client ID/secret through dedicated headers from protected configuration; these are separate from its Atlas [credential omitted] and never enter the SPA. Validate the Access assertion/audience at the origin or connector and block bypass paths. Do not rely on a hostname being obscure.

The authentication hostname exposes only the selected Atlas realm's required login, callback, static theme, OIDC discovery/JWKS and protocol routes. Browser users cannot hold a gateway service secret, and automated OIDC clients must not receive an Access HTML login page. Keep the realm's browser-facing protocol paths usable with Keycloak PKCE/TOTP and enforce appropriate client authentication on machine endpoints. Block master/administration, management, health and unrelated realm routes. Deny-by-default route tests, login abuse controls, and exact proxy-header trust are readiness requirements. Do not expose all Keycloak paths through a blanket proxy.

Keep the integrated SPA and trusted HTTPS demo gateway inside the VM, with only an explicit Mac-loopback forward for the browser. A host development server is limited to focused development without tunnel exposure. It calls CloudHub through a same-origin local API proxy; local workers use authenticated CloudHub system routes. CloudHub calls the protected backend gateway and the required authentication endpoints. Document transfers stay authenticated and uncached. Cloudflare Access service credentials apply to the backend route only; they do not confer business access. CloudHub's externally reachable application endpoints must likewise validate bearer/service credentials and expose no diagnostic dump.

Use one stable HTTPS Keycloak issuer resolvable from browser, containers and CloudHub. Verify discovery, JWKS refresh, client credentials, sensitive-action session checks and redirect URLs across all paths. Named-tunnel setup requires a Cloudflare account and a domain configured there. Check the applicable service plan, request/upload limits and terms for the bounded synthetic document transfer; do not assume entitlements. Do not use changing Quick Tunnel URLs as a persistent issuer. Disable caching for authentication, private APIs and documents, and avoid request/response body logging at every gateway.

No router inbound ports are opened. Databases, scanner, document volumes, raw Camunda APIs and admin consoles remain local and nonpublished. Trusted HTTPS is required across browser and cross-host connections. The explicit local exception remains plaintext inside dedicated Atlas container networks between the connector/gateway and nonpublished containers, including the scanner protocol. If an origin uses HTTPS, validate its certificate; do not disable verification.

FileVault protects the local VM disk and host secret storage at rest, without protecting against a running host administrator. Store no authoritative business ledger or evidence on CloudHub replica disks. Preserve named volumes on normal shutdown; keep coordinated resets separate. A sleeping Mac, stopped tunnel or unavailable IAM/backend makes the demo unavailable or pending; neither CloudHub nor the tunnel makes this local prototype highly available.

Accounts, configuration, and setup gates

Required access: an Anypoint account/trial with CloudHub 2.0 deployment capacity, an appropriate sandbox and a least-privilege Connected App; a Contentful space with both locales and suitable limits; and, if accepted, a Cloudflare account/domain with Tunnel and Access service-token capability. Camunda non-production terms must be reviewed. Anypoint access is explicitly absent today; other required account rights are unverified. The owner chooses accounts and accepts terms; no purchases, signups or exposure were performed.

Keep nonsecret names and URLs in an example configuration: ATLAS_PUBLIC_ORIGIN, ATLAS_OIDC_ISSUER, ATLAS_OIDC_CLIENT_ID, MULE_EXPERIENCE_BASE_URL, MULE_SYSTEM_BASE_URL, CAMUNDA_REST_URL, CONTENTFUL_SPACE_ID, CONTENTFUL_ENVIRONMENT_ID, and locale/health settings. Host deployment secrets belong in ignored files under an owner-controlled directory such as ~/.config/atlas/secrets, with restricted permissions. Do not mount that host directory into the VM. Transfer only scoped Atlas runtime secrets to restricted guest files for container injection. Pass database credentials, service secrets, CMS tokens and license material through private mounts/configuration, never browser VITE_* variables, source files, image layers, or logs. Exact injection keys belong to deployment specs.

Before the integration slice is ready, verify access/license conditions, exact pins and architecture manifests, authenticated issuer/gateway reachability in both directions, owner API traversal through Mule, engine start/task response-loss behavior, TOTP/step-up claims, both locales, real scanner acceptance/rejection/outage, signature freshness, and persistence across restart. Measure combined CPU/memory/disk use and end-to-end latency under the selected demo journeys. Demonstrate a failed dependency without lost drafts, duplicate effects or fabricated success. Provisioning and tests follow the spec/issue gates; none has run here.

Connectivity decision still needed

The dedicated VM is a candidate, not proof of host isolation. Select and validate enforcement outside the workload guest that denies access to Mac/LAN/VPN services before activating any tunnel. Default NAT and plain mode do not provide that guarantee. The VM proposal records this unresolved prerequisite and the separate-host fallback.

The connectivity candidate remains a named Cloudflare Tunnel with a service-authenticated backend gateway and narrowly public Keycloak login/OIDC routes for synthetic data. It replaces the proposed private-only Tailscale path. A domain and Cloudflare access are additional setup prerequisites. The alternative is an entitled CloudHub private space plus a suitable VPN gateway, which requires a separate connectivity design.

Sources for the tunnel proposal

Cloudflare documents named public-hostname routes and domain/account requirements in Tunnel setup, and machine authentication headers in Access service tokens. These capabilities support the proposal; the Atlas routing and authorization design remains unconfigured and untested.

CloudHub's shared-space documentation distinguishes public application hosting from private-space network features. The tunnel recommendation is an Atlas design inference using public HTTPS, not a claim of private connectivity or a tested vendor integration. Anypoint VPN requires available network entitlements and an external gateway.