Platform Support
CloudConfig shares its application API across Cloudflare, Vercel, and Azure.
Some features use different native infrastructure, and a successful app build
does not prove every vendor account, permission, or workload will work in
production. Use cloudconfig doctor and cloudconfig deploy --dry-run to check
the declared project before deployment.
Shared Application Features
Models, validation, access rules, REST routes, the typed client, server hooks, OpenAPI, and the MCP API use the same core on each host. Nuxt selects bindings per request. Standalone and Next projects use their generated mounts and the configured production database adapter.
Sign-in and Connect use the configured application database and server secrets.
OAuth callbacks, encrypted account credentials, API-key connections, and hosted
MCP connections share the same runtime. Provider credentials, redirect URLs,
vendor consent, quotas, and approvals still need configuration. Email
verification and OTP require a reachable email service; passkeys require the
correct public origin. Connect integration webhooks can hand off to durable jobs
and run scheduled maintenance on all three clouds when deploy.automations is
declared. See Deploy Automations.
Native Durable Features
The automatic Nuxt path deploys agents and automations through Cloudflare Agents and Durable Object alarms, Vercel Workflow and queue triggers, or a separate Azure Durable Functions app. Each includes persisted checkpoints, scheduled continuation, and scoped execution. Azure activities and Vercel step workers bind both platform ports for callbacks between agents and jobs.
Production does not fall back to process memory. Development uses a memory adapter whose jobs and timers end when the dev server stops. Other frameworks must compose the native adapters explicitly; automatic portable automation deployment currently rejects them. Raw Cloudflare Workflow classes, Queues, bindings, and managed Turnstile resources remain Cloudflare services. The archived automation editor is not an active cross-platform feature.
Database and File Storage
Cloudflare defaults to D1. Vercel defaults to a Turso database that you create and provide credentials for. Azure retains the D1 HTTPS default. Explicit D1, Turso, or libSQL selection is independent of the application host. Local development uses SQLite. All currently supported engines are SQLite-compatible; PostgreSQL, MySQL, Neon, Supabase, PlanetScale, Cosmos DB, and AWS-specific engine adapters are deferred. Changing hosts does not copy existing data or native run history. See Data Services.
Application uploads use R2 bindings on Cloudflare or S3-compatible HTTPS storage on any host. Azure's private execution-state Blob account is separate; a native Azure application Blob-storage adapter is not included.
Vercel limits Function request and response bodies to 4.5 MB. CloudConfig's
multipart upload and proxied download routes are subject to that limit even if
storage.maxSize is larger. Keep proxied files below 4 MB to leave multipart
overhead, or implement direct object-storage transfer in the application. Built-in
presigned browser uploads are not available yet. doctor warns when a Vercel
storage model declares a larger maximum. See Vercel Function limits.
Azure automatic custom-domain and certificate binding is not implemented; configure that separately. All hosts retain their platform execution, memory, payload, regional, and service-quota limits. A durable job can wait for a long time, but each action must fit the underlying activity's limits.
What Repository Checks Establish
Package E2E checks install packed npm artifacts into fresh consumers, exercise local API and sign-in behavior, and build Nuxt agents, automations, Connect, and scheduled jobs for all three targets. They inspect Cloudflare class exports and Vercel's compiled workflows and queue triggers. Real local workerd tests cover Cloudflare checkpoint continuation, event waits, schedule dispatch, and worker restarts. Azure tests build native Function artifacts and check replay-safe orchestration, private deployment settings, and invocation-bound cross-workload calls. Integration contract tests verify signatures, queue-failure responses, idempotent delivery identities, token refresh, and encryption-key maintenance.
These checks do not deploy paid cloud resources or certify every live OAuth provider. Before a production rollout, exercise deployment, a scheduled job, an agent approval, and one real integration with that environment's credentials. The repository checks alone do not establish “100% support” for every feature combination or third-party account.