Identity, not node access
A random Ugla account ID; Apple or Google provider plus their stable subject ID; optional email returned by that provider; account status; hashed, expiring login challenges and service sessions.
Trust · privacy · sovereignty
The cloud is not your agent.
Ugla Cloud coordinates a service account and, when managed hosting becomes available, dedicated infrastructure. Your node remains the runtime and ordinary plaintext data boundary.
Current status: account login and the control-plane model exist in code. Managed hosting, billing, and production launch are not live.
Plain-language data map
What the control plane can store.
This list is derived from the current database migrations and public Rust types—not a promise about features that have not shipped.
Bounded operational facts
Ugla node ID, account ownership reference, managed or user-owned infrastructure flag, lifecycle state, requested region, release identity, bounded health observation, and private provider resource provenance.
A short handoff, not a node credential
Claim ID, node and account references, device public-key fingerprint, expiry, use time, and only a hash of the random claim secret. The ordinary app credential is minted by the node and does not pass through Ugla Cloud.
No billing or analytics store
The current schema has no billing records, marketing profiles, analytics events, advertising identifiers, or retained Apple/Google access and refresh tokens.
Outside the plaintext cloud plane
Ordinary agent data belongs on the node.
Ugla Cloud has no current table, API, or credential for reading the following categories.
- Conversations and memory
- Files and ordinary node configuration
- Connector credentials
- LLM/API credentials
- Vault records
- Tool inputs and results
- Ordinary app-to-node credentials
This boundary describes the current architecture. It does not claim that a managed infrastructure operator can never access a virtual machine, or that dedicated infrastructure equals dedicated physical hardware. Provider and operator access must be minimized and disclosed before a managed service launches.
Managed and self-hosted
Same node boundary, different operations.
Self-hosting is a first-class path: you provide and operate the infrastructure. Managed hosting is intended to provision and maintain a dedicated node as a convenience. It is not live today, and this page does not claim stronger encryption, isolation, recovery, or availability than the implementation proves.
An already-paired app and running node use their direct API and ordinary node credential. Signing out of Ugla Cloud does not revoke that credential or rewrite node storage.
Deletion first produces an explicit plan for every non-destroyed managed node. It does not silently destroy provider resources or node data as an identity side effect.
Third parties and diagnostics
No invisible marketing stack.
The public site loads no analytics, advertising, external fonts, or third-party scripts. Its pages, styles, and images are served by the Ugla Cloud process.
When you choose their sign-in method, that provider processes the authentication. Ugla validates an identity assertion and does not retain provider API access or refresh tokens.
Source code, issues, and repository automation currently use GitHub. The public support link may take you there; ordinary node data is not part of that workflow.
The managed service is not live. Every provider materially involved in the launched website, account, or hosting path must be named here before production use.
No product telemetry or diagnostics collection is implemented in this repository. Structured operational logs exist, with assertions, sessions, claim secrets, node credentials, and provider tokens forbidden from log fields.
Security contact
Report vulnerabilities privately.
Send a minimal first report without credentials, live tokens, or user data. Operational details can move to an appropriate private channel.
Email a security report