What talks to what, and who checks.

Two paths leave your desktop: platform apps through the MCP server into the platform API, custom frontends through a build worker onto the CDN. Both start with the same token and end in the same audit trail.

Two paths, one identity

Platform apps — objects, forms, workflows, screens — are edited through the MCP server and stored by the platform API in Postgres and MongoDB. Custom frontends are standard static builds: a worker fetches a versioned source snapshot, builds it, and uploads the output to object storage that only the CDN can read. The desktop app, the MCP server, and the deploy chain all validate the same identity through the platform.

Authenticated on every request, authorized in one place

Authentication happens on every request, and authorization happens in one place. The MCP server is a gate, not a judge.

1. Your agent presents a bearer token. Every MCP request carries it. There is no environment-variable token fallback in hosted operation, and each request’s token is isolated from every other request in flight.
2. The MCP server validates the token against the platform on every call. A rejected request receives a bare 401 — no tool list, no schema, no server information. The only unauthenticated endpoint is the health probe, which returns {ok:true} and nothing else.
3. The token is forwarded, and the platform authorizes. The MCP server never decides who can do what. The platform evaluates your permissions, so the agent can never do more than the person running it.
4. One identity across every surface. The desktop app, the MCP server, and the custom-frontend deploy chain all validate sessions against the same platform, so a permission change applies to every surface. Validation results are cached for up to five minutes, so allow that window before a revocation is fully in effect.
5. SSO where you need it. The platform supports Auth0, SAML, Google, and Firebase as identity providers.

We operate it; you patch nothing

Apps run on managed cloud infrastructure we operate, built primarily on AWS. We operate it; you do not install or patch anything. The backend is not self-hostable: there is no on-premises or customer-cloud option.

• HTTPS everywhere. Every app URL, in every environment, is served over TLS with an auto-renewing wildcard ACM certificate.
• Outbound only. The desktop app makes outbound HTTPS calls to the MCP endpoint and the platform API and runs no listening service — there is no inbound firewall rule to open. What it sends and does not send is listed on the download page.
• CDN edge, multi-tenant by design. One distribution per environment serves every app as its own tenant with a version-specific origin path. That is what makes a version switch atomic and rollback fast — and it is also why we do not describe hosting as dedicated infrastructure per customer.
• Per-environment URLs. Each app gets a develop, staging, and production address on our domain. Custom domains are not offered yet.
• Region. A specific data-residency commitment is to be confirmed and is not promised until it is. See compliance status.

Least-privilege build worker

The worker that builds custom frontends holds the least it can. It fetches source with dedicated read-only credentials scoped to version snapshots only, and the API that orchestrates deployments does not share its credentials with the worker.

• Seven phases per build: fetch → install → build → verify → upload → promote → invalidate. Each phase and any error phase is recorded per deployment.
• Static output only. The pipeline builds and serves files; it does not run application servers for custom frontends.
• Promotion rebuilds per environment with that environment’s own configuration, and a frozen snapshot of the build environment is kept per deploy for forensics.

Closed buckets, signed files

• S3 artifact buckets are closed to the public. Build output is reachable only through CloudFront Origin Access Control, scoped to the specific distribution. A direct storage URL returns 403.
• Files move through signed URLs. Uploads and downloads in platform apps use time-limited signed URLs rather than open buckets.
• Path-traversal defense on every file write. Paths are normalized; leading slashes and . / .. segments are rejected before anything touches disk.
• Immutable version snapshots. Each custom-frontend version is a frozen source snapshot that never changes after it is written, which is what makes rollback a pointer move rather than a re-upload.

What we do not claim

• No server-side code for custom frontends — the pipeline builds and serves static output; custom backend functions are on the roadmap, not shipped.
• No region commitment yet — to be confirmed; ask before you rely on one.
• No uptime or response-time numbers on this page — we will publish commitments when we can stand behind them contractually. How incidents reach you in the meantime is on the status page.

The rest of what we do not claim — self-hosting, dedicated infrastructure, custom domains — is on the security hub.

Read the full references

This page summarizes the architecture references we maintain for the platform, the MCP server, and the deploy chain. They are being moved to our docs domain; until that is live, request them with the security overview.