Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.
Cloud deployment with a local UI
Historical alternative with the UI local and original MuleSoft assumptions. ADR 0010 now governs local certification followed by hosted UI, cloud VPS and Contentful SaaS. The proposal below remains research, not the current deployment plan.
Status: recommendation for owner review, 2026-09-23. Research cloud hosting for all Atlas services except the local UI contains the research resolution. This alternative has not been selected or provisioned. Existing business, identity and API decisions still apply.
Integration-provider follow-up
The owner subsequently asked to explore replacing MuleSoft/CloudHub. See free integration alternatives. The owner subsequently selected the local BFF; this document retains the prior proposal for comparison.
Free-tier follow-up
The owner subsequently requested a free-tier comparison and reported an existing AWS account from 2025. See free-tier hosting assessment. Paid Lightsail remains the predictable-cost option below; it is not an always-free recommendation. AWS eligibility and OCI free capacity are unresolved account-specific inputs.
Recommendation
For this synthetic prototype, host the custom backend and supporting services on a dedicated AWS Lightsail Linux VM, retain MuleSoft CloudHub 2.0 and Contentful SaaS, and keep only React/Vite and developer tooling on the Mac. This removes the need for a tunnel into the Mac and keeps the existing Docker-oriented design with fewer paid managed-service contracts.
This is cloud hosted, with self-managed software on the VM. It does not outsource Keycloak, Camunda, database or scanner operations. If minimizing operations is more important than recurring cost, use the managed alternative below. Do not infer a preference for AWS beyond this recommendation; no existing AWS account or entitlement has been verified.
Component placement
| Component | Recommended prototype placement | Responsibility |
|---|
| React/Vite SPA | Mac, fixed loopback HTTPS origin | Local UI and public OIDC configuration only |
| MuleSoft Experience/System APIs | CloudHub 2.0 shared space initially, if entitled | Anypoint deployment/configuration; vendor runtime hosting |
| Content and bilingual form templates | Contentful SaaS | Authoring and release permissions; immutable release compilation in cloud |
| Domain simulator, outbox/workflow/scanning workers | Separate Docker services on Lightsail | Atlas code, service authorization and durable delivery |
| Keycloak | Docker on Lightsail, normal server mode and PostgreSQL | Mandatory TOTP, en-US/es-US theme, exact origins, upgrades and recovery |
| Camunda | Self-Managed 8.9 lightweight configuration on Lightsail | Non-production terms, OIDC, durable engine storage and backups; no unmodified public quickstart |
| PostgreSQL | Private Docker service, separate business and IAM databases/roles | Backups, migrations, patching and recovery |
| Document quarantine, accepted bytes and immutable form releases | Separate private VM volumes initially | Only backend adapters and narrowly scoped scanner access; no public file server |
| ClamAV and signature updater | Private Docker service on Lightsail | Real scans, signature freshness and adequate memory |
| TLS entry gateway | Dedicated HTTPS routes on Lightsail | Narrow backend routes and selected Keycloak realm paths; admin/engine/data ports remain closed |
A US region is the proposed default for the fictional US demo. Confirm availability, transfer allowances and account regions before setup. Choose a supported host/image architecture from the actual catalog and pin each container digest for that architecture.
flowchart LR
UI["Mac: React/Vite + loopback proxy"] -->|"HTTPS business requests"| M["MuleSoft CloudHub"]
UI -->|"Browser login + PKCE"| K["Cloud Keycloak"]
M -->|"Service-authenticated HTTPS"| B["Cloud Atlas backend"]
W["Cloud workflow/outbox workers"] --> M
W --> C["Cloud Camunda"]
B --> DB["Private PostgreSQL + document volumes"]
B --> S["Private ClamAV"]
R["Cloud release compiler"] --> CMS["Contentful SaaS"]
The diagram shows major responsibilities, not every call. Business operations continue through MuleSoft; workflow workers use Camunda's authenticated engine APIs as required. CloudHub authenticates to Keycloak where needed. No cloud component calls the Mac. An OIDC redirect to the local UI is the browser navigating locally, not a server opening an inbound connection.
Local UI and cloud security
Keep the accepted SPA public-client authorization-code/S256 PKCE flow, in-memory tokens and TOTP. Use one fixed trusted local HTTPS origin and exact callback/logout URLs. Configure Keycloak Web Origins narrowly. Silent SSO may be constrained by third-party-cookie settings, so test the normal redirect login and session-expiry behavior. Never give the SPA cloud deployment, CMS management, database or machine-client secrets. Keycloak JavaScript adapter.
Retain the accepted loopback-only development/demo proxy for same-origin business API calls to CloudHub. It forwards the user's [credential omitted] without acquiring its own business identity or storing a server session. It is local UI serving infrastructure, not a new BFF. If direct browser-to-CloudHub requests are later selected, explicitly decide the CORS change and allow only the exact local origin, methods and headers. CORS is not authorization.
CloudHub shared space does not supply private endpoints or static application source IP addresses. Its calls to the cloud backend therefore use a narrow public HTTPS endpoint with dedicated service authentication and Atlas actor authorization. Do not rely on source-IP allowlisting or a secret hostname. A private network design requires different CloudHub entitlements. Shared-space constraints.
Expose only the HTTPS gateway publicly. Restrict management SSH to approved operator sources and keys; disable SSH-agent forwarding. Remove permissive default firewall rules for both IP families. Keep PostgreSQL, ClamAV, Camunda management and Keycloak administration off public routes. Confirm Docker port publication against the external firewall. Lightsail firewall rules.
Use a dedicated cloud account/project boundary, scoped deploy credentials, redacted logs, private volumes, patched images and coordinated database/engine/document backups. Test restoration and a dependency outage before relying on the demo. A single VM is one failure domain and provides no high-availability claim. Moving the backend off the Mac removes the guest-to-Mac connection path only if no VPN/tunnel/host mounts are added back. Browser code, developer dependencies and locally held deployment credentials still need normal protection.
Cost and alternatives
The published Lightsail general-purpose Linux bundle with public IPv4, 16 GiB memory, 4 vCPUs and 320 GB disk costs $84/month. Capacity is an unmeasured starting point, not a performance promise. Add snapshots/backups, domain, taxes and any transfer overage; evaluate the 32 GiB tier if scanner reloads and engine activity exceed the budget. Stopping an instance does not by itself establish zero billing. Confirm the provider's current billing rules. Lightsail pricing.
That $84 is infrastructure only. CloudHub subscription cost remains account-specific and could dominate the total. Contentful's Free plan may fit two locales and prototype content limits; confirm the modeled content types, records and requests before relying on it. Camunda advertises free non-production Self-Managed use; the owner must confirm applicable terms for the intended demo. No production-license entitlement is inferred. Camunda pricing, Contentful pricing, MuleSoft pricing.
| Alternative | Advantage | Tradeoff |
|---|
| Managed application services on Render, managed PostgreSQL, Camunda SaaS, managed Keycloak, private object storage | Provider-operated compute/data platform and fewer VM administration tasks | More accounts, cross-provider networking, object-store adapter, trial expiries and higher subscription cost |
| AWS ECS/Fargate, RDS and S3, plus SaaS IAM/workflow or separately operated instances | More granular network/IAM controls and independent scaling | More infrastructure configuration, networking charges and deployment complexity than the first demo needs |
| Local isolated VM | Existing local resources and no cloud VM charge | The actual VZ baseline permits guest access to Mac loopback; an external network-control solution and further proof are still required |
A managed prototype estimate starts with Render API $25/month, worker $25, private scanner $85 and PostgreSQL $19: $154/month before database storage, object storage, bandwidth and workspace charges. Phase Two managed Keycloak Starter adds an advertised $149/month, bringing that illustrative subtotal to $303/month before Camunda SaaS, CloudHub and other extras. These are sizing assumptions, not a tested minimum. Camunda SaaS's current page offers a 30-day execution trial and sales-priced continuation. Phase Two's trial auto-converts unless cancelled. Cloud-IAM's free tier excludes custom themes, and dedicated hosting starts at €225/month. Details and source links: managed-services research, application-hosting research.
Render's private services cannot receive CloudHub calls directly across providers. A public authenticated API service is still needed. Independent services also cannot share one Render persistent disk, so use private object storage and adapter-mediated document transfers for that option. Keep presigned browser downloads deferred as already decided.
Agent operation and next decision
AWS CLI v2 can manage Lightsail instances, network rules and snapshots. Keep infrastructure definitions and deployment scripts in Git; use Anypoint CLI for CloudHub, Keycloak Admin REST/CLI for realm configuration, and the existing Contentful/Camunda APIs for their artifacts. Dedicated credentials and environment targeting remain required. Lightsail CLI operations, CloudHub agent contract.
Choose between the recommended self-managed cloud prototype and the managed-services alternative before changing the runtime ADR. Then confirm the all-in budget, cloud accounts, domain, licenses, exact supported images and teardown/backup policy. No accounts were created, money spent or cloud resources deployed during this research. The local VM experiment remains open and stopped while these alternatives are reviewed.