Skip to content

eliza-cloud-rollout.md

Latest commit

 

History

History
125 lines (89 loc) · 5.23 KB

eliza-cloud-rollout.md

File metadata and controls

125 lines (89 loc) · 5.23 KB

Eliza Cloud Integration Plan

This document defines the Eliza Cloud rollout as three user-facing hosting paths that all share one onboarding entry point.

Product paths

  1. Local The backend runs on the user's machine with the current full-local behavior and full local permissions.

  2. Eliza Cloud The frontend provisions and connects to a managed container through Eliza Cloud at elizacloud.ai.

  3. Remote Milady backend The frontend connects to an already running Milady backend by address plus access key (MILADY_API_TOKEN).

Architecture

App onboarding

  • Add a hosting-choice screen before provider setup.
  • Local continues into the existing provider selection flow.
  • Cloud splits into:
    • Eliza Cloud: submit onboarding with runMode: "cloud" and cloudProvider: "elizacloud".
    • Remote Milady: switch the frontend API base to the remote backend and restart app bootstrap against that target.
  • Persist the selected API base in session storage so reloads and popouts keep the same backend.
  • Keep the existing RPC step, but treat Eliza Cloud as ready when the user is authenticated or has entered a cloud API key.

Self-hosted remote backend

  • The backend stays the canonical Milady API server.
  • Browser clients must send a bearer token using MILADY_API_TOKEN.
  • CORS must explicitly allow the frontend origin with MILADY_ALLOWED_ORIGINS.
  • The onboarding access key shown to the user is the same value as MILADY_API_TOKEN.

Eliza Cloud control plane

  • elizacloud.ai is the canonical managed control plane.
  • There is no separate Milady-specific cloud API service.
  • Eliza Cloud is the control plane, OAuth handler, billing surface, and user store.
  • Managed launches redirect into app.milady.ai with a one-time launch session that injects the selected backend connection and skips onboarding.

Browser transport

  • app.milady.ai already exchanges managed launch sessions directly with Eliza Cloud.
  • The hosted Milady frontend should use Eliza Cloud APIs directly for browser-safe managed flows.
  • The local desktop/backend keeps same-origin /api/cloud/* passthrough routes so it can persist the user's Eliza Cloud API key into local config and runtime state.
  • If a Milady-owned origin is ever required for browser routing or enterprise policy, use the Cloudflare Worker proxy template in deploy/cloudflare/eliza-cloud-proxy/ instead of standing up a separate application server.

Operator checklist

Milady app and API

  • Restore hosting-choice onboarding in the app.
  • Add Eliza Cloud and Remote Milady cloud sub-options.
  • Allow the frontend client to rebind to a remote backend during onboarding.
  • Persist the rebound API base for the current session.
  • Update cloud defaults and user-facing copy to Eliza Cloud.
  • Persist an Eliza Cloud API key during onboarding when the user chooses API-key auth.

Self-hosted remote flow

  • Document secure remote backend deployment in the README.
  • Document address + access-key connection flow in the README.
  • Document Tailscale as the preferred private-network exposure path.
  • Add a dedicated in-app "switch backend" settings surface after onboarding.
  • Add a remote-backend connectivity diagnostic screen for auth/CORS/WS failures.

Eliza Cloud control plane

  • Point managed launch onboarding at cloudProvider: "elizacloud".
  • Keep Milady-managed launch sessions flowing through Eliza Cloud.
  • Make the browser-facing Eliza Cloud auth/compat endpoints callable cross-origin when needed.
  • Remove active Milady Cloud labels from the managed auth/runtime surfaces.
  • Verify post-login session redirects and popup flows end-to-end against the Milady app.

Infrastructure and release

  • Run a production smoke test:
    • Local onboarding
    • Eliza Cloud provisioning
    • Remote self-host attach by URL + token
    • Desktop download flow from the homepage
  • Cut a Milady release after the hosted flow is verified on the public domain.

Remote backend deployment recipe

Use this when the user wants to host their own backend and connect from the Milady web frontend.

  1. Install Milady on the target machine.
  2. Set a non-loopback bind, a strong API token, and explicit allowed origins.
  3. Expose the service over HTTPS or a private Tailscale URL.
  4. In onboarding, choose Cloud -> Remote Milady, then enter:
    • backend address
    • access key (MILADY_API_TOKEN)

Recommended environment:

MILADY_API_BIND=0.0.0.0
MILADY_API_TOKEN=$(openssl rand -hex 32)
MILADY_ALLOWED_ORIGINS=https://app.milady.ai,https://milady.ai,https://elizacloud.ai,https://www.elizacloud.ai

Optional Tailscale exposure:

tailscale serve --https=443 http://127.0.0.1:2138

For a public Tailscale-hosted URL:

tailscale funnel --https=443 http://127.0.0.1:2138

Optional Cloudflare proxy

Use this only if a Milady-owned browser origin is required for policy or routing reasons.

  1. Deploy the Worker template in deploy/cloudflare/eliza-cloud-proxy/.
  2. Point the Worker at https://www.elizacloud.ai.
  3. Route only browser-facing auth/compat/launch-session paths through the Worker.
  4. Keep Eliza Cloud as the only upstream control plane.

The concrete proxy setup now lives in docs/eliza-cloud-deployment.md.