EXTENDED DOCUMENTATION
Deployment
Canonical Production Topology
Morpheus now deploys by responsibility, not by network.
| Layer | Service | Current role |
|---|---|---|
| Edge | Cloudflare gateway | public ingress, caching, optional abuse controls |
| Control | Cloudflare control plane | auth, validation, job persistence, queue/workflow dispatch |
| App | Vercel | docs, explorer, backend APIs used by control plane |
| State | Supabase | jobs, relayer state, automation, feed snapshots, encrypted refs |
| Confidential execution | Oracle CVM | request/response oracle, compute, NeoDID, confidential signing |
| Confidential execution | DataFeed CVM | isolated feed publication lane |
Source Of Truth
Recommended operator rules:
- keep one root secret set in
- render dedicated Phala env files per network
- keep for production
- never treat separate CVMs as separate networks; networks are selected by path and config
Step 1: Apply Supabase
Apply migrations in order:
Optional:
Key durable tables:
Step 2: Deploy The Web App
Deploy
to Vercel.Required environment:
- or network-scoped runtime URLs
- or /
- for operator-triggered feed sync probes
Recommended production environment:
After pulling or configuring Vercel production env, run:
The first command validates only key presence and never prints secret values. If
or is still , the web cron environment is not deployed or Vercel Cron is not triggering the routes. Root / values are intentionally ignored by this check because the Vercel deployment does not inherit them automatically.Do not set Vercel's special
on the production web deployment when Secure Compute is enabled. Vercel Cron requests are accepted by the user agent guarantee, while manual operator probes use through the header. If the control-plane feed endpoint rejects web dispatch credentials with 401/403, the cron route falls back to direct runtime feed sync by default; set only after the control-plane key mapping is confirmed.Step 3: Deploy Cloudflare Edge
Deploy
.Required bindings:
Optional:
Current public pattern:
Step 4: Deploy Cloudflare Control Plane
Deploy
.Required bindings:
Required secrets:
- or
Recommended:
Current public pattern:
Step 5: Render Phala Runtime Envs
Generate fresh env files before each deployment:
Notes:
- aliases mainnet generation
- signer drift should fail deployment review
- generated env files stay local and uncommitted
Step 6: Deploy The CVMs
Oracle CVM
- name:
- app id:
- role: request/response, compute, NeoDID, confidential signing
- baseline size:
DataFeed CVM
- name:
- app id:
- role: feed publication only
- baseline size:
Tracked launchers:
Deployment files:
Step 7: Configure The Relayer Modes
The relayer is split by role:
- Oracle CVM:
- DataFeed CVM:
Important relayer durability settings:
- on testnet
Step 8: Publish Keys And Verify
After the runtime is live:
If you are deploying a new updater path:
Current Service Anchors
- Oracle runtime:
- public runtime contract: ,
- Edge gateway:
- Control plane:
- Oracle attestation explorer:
- DataFeed attestation explorer:
- Neo N3 service anchors:
- NeoDID anchor contract:
- published in
Operational Notes
- DataFeed is isolated so price updates keep their own execution lane.
- Mainnet and testnet share the same Oracle and DataFeed CVMs.
- Network separation happens in config and request metadata, not in VM topology.
- Neo N3 remains the only supported production chain.
CURRENT DESIGNUPDATED FOR DUAL-CVM ARCHITECTURE