Compatibility Matrix · ViteHub

Queue

6 providers

Compare queue providers by delivery model, helper surface, and local-development fit.

Yes, No, and Partial describe the public ViteHub behavior in this release. Cells with short labels summarize the main provider behavior instead of every low-level option.

Capability	Platformatic	Cloudflare	Vercel	Netlify	QStash	Memory
Extra SDK required	@platformatic/job-queue	None	@vercel/queue	@netlify/async-workloads	@upstash/qstash	None
Hosting auto-detection	No	Cloudflare hosting	Vercel hosting	Netlify hosting	No	No-cloud runtime
Batch send	Yes	Yes	No	No	Yes	Yes
Batch consume	Yes	Yes	No	No	No	No
Retries / wait / result lookup	Strong	Provider-managed	Partial	Provider-managed	Provider-managed	No
Provider-native helper surface	Worker control	Batch handler	Callback helpers	Event helpers	Publish + schedules	Store helpers
Local development fit	High	Medium	Low	Low	Medium	High
Delivery model	Worker queue	Workers queue	Topic callbacks	Async Workloads	HTTP callbacks	In-process array

Email

3 providers

Compare email providers by batch support, shared template coverage, and provider-specific escape hatches.

Docs

Yes, No, and Partial describe the public ViteHub email surface in this release. Partial means the capability exists through the shared API but falls back to fanout or loses a provider-native behavior.

Capability	Resend	SendGrid	Postmark
Extra SDK required	resend	@sendgrid/mail	postmark
Hosting auto-detection	No	No	No
Batch send	Yes	Partial Portable batch sends fan out across single-send requests.	Yes
Shared template mapping	Yes Maps `delivery.template` into Resend template payloads.	Yes Maps `template.key` to `templateId` and `template.data` to `dynamicTemplateData`.	Yes Maps string keys to `TemplateAlias` and numeric keys to `TemplateId`.
Portable scheduling	Yes	Yes	No
Provider-only payload escape hatch	`delivery.transport`	`delivery.transport`	`delivery.transport`
Best fit	Modern transactional + native batch	Broad advanced payload controls	Transactional streams + templates

Workflow

4 providers

Compare workflow providers by run lookup, step support, and provider-native run methods.

Docs

Optional means the feature is available only when you configure the provider-specific hook for it. No means the portable ViteHub workflow surface does not expose that capability in this release.

Capability	Cloudflare	Vercel	OpenWorkflow	Netlify
Extra SDK required	None	workflow	openworkflow	@netlify/async-workloads
Hosting auto-detection	Cloudflare hosting	Vercel hosting	No	Netlify hosting
Run lookup	Yes	Yes	Optional	No
Portable step helpers	No	No	No	Yes
context.sendEvent()	No	No	No	Yes
Provider-specific run methods	pause/resume/restart	result lookup	result lookup	Minimal
Best fit	Workers-native durable runs	Vercel-native durable runs	Bring your own backend	Step-based Async Workloads

Cron

3 providers

Compare Node, Cloudflare, and Vercel scheduling behavior before choosing a cron provider.

Docs

Yes, No, and Partial describe the public ViteHub behavior in this release. Platform-triggered providers reject Node-only schedule fields such as timezone, overlap, startAt, stopAt, and maxRuns.

Capability	Node	Cloudflare	Vercel
Hosting auto-detection	No	Cloudflare hosting	Vercel hosting
In-process scheduling	Yes	No	No
Platform-triggered scheduling	No	Yes	Yes
Advanced schedule controls	Yes	No	No
Generated build/runtime output	None	Cron Triggers	Build Output + internal routes
Local or self-hosted fit	Yes	Partial	Partial

Browser

2 providers

Compare Browserbase and Cloudflare Browser Rendering before choosing a browser provider.

Docs

Yes, No, and Partial describe the public ViteHub behavior in this release. Partial means the feature exists with limits or only on one side of the provider surface.

Capability	Browserbase	Cloudflare
Extra SDK required	@browserbasehq/sdk + playwright-core	cloudflare
Hosting auto-detection	Vercel hosting	Cloudflare hosting
One-shot operations	Partial	Yes
Session support	Yes	No
Native provider handle	Yes	Yes
Best fit	Managed CDP sessions	REST extraction and crawl

Sandbox

6 providers

Compare sandbox providers by isolation model, runtime controls, and local-development fit.

Docs

Partial means the feature exists with limits. Cloudflare now has two sandbox providers: the Durable Objects-backed runtime and the Worker Loader-backed runtime. The dynamic provider stays explicit and does not expose the file or process surface.

Capability	Cloudflare	Cloudflare Dynamic	Vercel	Deno	Docker	Local
Extra SDK required	@cloudflare/sandbox	None	@vercel/sandbox	@deno/sandbox	None	None
Hosting auto-detection	Cloudflare hosting	No	Vercel hosting	No	No	No
exec() with cwd/env	Yes	No	Yes	Yes	Yes	Yes
File APIs	Yes	No	Partial	Yes	Yes	Yes
Long-lived processes	Partial	No	Yes	Yes	No	No
Isolation model	Managed remote	Managed remote loader	Managed remote	Permissioned remote	Local container	OS-level local
Local development fit	Low	Low	Low	Medium	High	High
Notable runtime controls	sandboxId, keep-alive	loaderBinding, compatibilityDate, sandboxId	runtime, CPU, ports	allowNet, secrets, volumes	workspace, template	Minimal config
Best fit	Durable Object sandboxes	Runtime-loaded worker bundles	Managed remote sandboxes	Permissioned remote sandboxes	Local containers	Local OS isolation

Analytics

2 providers

Compare Vercel and Cloudflare Analytics Engine by transport model and backend-specific tradeoffs.

Docs

Yes, No, and Partial describe the public ViteHub analytics behavior in this release. Partial means the feature exists with backend-specific limits.

Capability	Vercel	Cloudflare Analytics Engine
Extra SDK required	@vercel/analytics	None
Browser transport	Official browser SDK	Generated first-party route
Server transport	@vercel/analytics/server	Worker binding
Custom events	Yes	Yes
Page events	Yes	Yes
Filtering hook	Yes Expose `analytics.vercel.beforeSend`.	No
Best fit	Official Vercel analytics end to end	First-party ingestion on Cloudflare