Provider Roadmap

Today deplo.ai deploys frontends to Vercel and backends to Render. The platform was built provider-agnostic from day one — this page explains how new providers slot in, and which ones are under consideration.

How the provider abstraction works#

Nothing in the platform is hard-wired to Vercel or Render. Credentials live in a provider-agnostic ProviderConnection table (one encrypted connection per user per provider); each provider is an adapter behind a small API-client interface; and the mapping from a detected framework to its deployment target is centralized in one place — the DeploymentStrategyResolver's PROVIDER_RULES table, which the analysis engine consults instead of scattering provider logic through the orchestrator. Adding a provider means one new adapter, one connect/disconnect flow, and new rows in that table — not a rewrite. See Architecture for the deeper dive.

Providers under consideration#

These are candidates we're evaluating — not commitments or dates. Order and inclusion will follow real demand.

Railway Planned — an alternative backend target alongside Render: Node and Python services would map to Railway services in your own Railway account.
Cloudflare Pages / Workers Planned — an alternative frontend target (Pages for static and framework builds) with Workers as a possible home for lightweight APIs at the edge.
Fly.io Planned — backend services as Fly Machines in your Fly organization, interesting for apps that want regions close to users.
Netlify Planned — an alternative frontend target mirroring the Vercel integration: framework-aware builds deployed into your own Netlify team.

Same trust model

Whatever ships, the rule stays the same: deployments run in accounts you own, connected per-user with encrypted credentials — never in platform-owned infrastructure. See Authentication & Security.

Want one of these prioritized — or a provider that isn't listed? Tell us: deploai201@gmail.com. Provider requests directly shape this roadmap.