New: Launch and Move, hands-on deployment and migration help with a clear delivery guarantee.
See optionsDeployment and operations in your cloud
Connect a repository and choose AWS, Google Cloud, Azure or DigitalOcean. The Deployer analyzes the application, proposes an architecture and estimated cost, shows you what it plans to create, then deploys it into your account. After launch you get deployment history, logs, health checks and operational tools in one place.
Built for developers, technical founders, agencies and small teams without a dedicated platform or DevOps team.
No credit card for the Free plan. Cloud infrastructure is billed separately by your provider. Need hands-on help? See Launch and Move.
Deploys into your account on
Four providers supported today. Capabilities vary by provider. See the support matrix.
A repository still needs compute, networking, TLS, environment configuration, deployment automation, health checks, monitoring and a plan for failures. Small teams often assemble that layer from provider consoles, scripts and tutorials. The Deployer puts those steps into one reviewed deployment workflow.
The Deployer coordinates the deployment. Your application runtime, database, storage and the other resources you select are created in the AWS, Google Cloud, Azure or DigitalOcean account you connect. You keep the provider relationship, the cloud bill and control of the resources.
If you stop using The Deployer, what it created stays in your account. Nothing is moved to us, and nothing is deleted because a subscription ended.
The Deployer uses AI where interpretation is useful and deterministic application logic where infrastructure changes need control. You can see what it has learned, what it proposes and what it is about to change.
Choose a repository and a supported cloud account. The Deployer verifies the connection before any deployment begins.
See permissions and security →The repository scanner identifies frameworks, services, ports, build commands, environment variables and other deployment requirements. Analysis does not make cloud changes.
See supported architecture options with their tradeoffs and an estimated monthly infrastructure cost. The estimate is not a spending cap; actual provider charges depend on usage.
See the services, environment requirements and infrastructure changes before deployment. Nothing is created in your account until you start the deployment.
The deployment engine applies the plan and streams each step. If a supported step fails, recovery logic can retry or propose a correction. Some failures still need your input.
After launch, use the dashboard for deployment history, health, logs, domains and supported operational changes. Your application runtime stays in your cloud account.
Common deployment and day-two operational components in one workflow. What is available depends on the architecture you choose and the provider you deploy to.
Build and deploy supported web applications, APIs, workers and static sites into AWS, Google Cloud, Azure or DigitalOcean. One deployment workflow across supported providers; the exact services and features vary by provider.
Common deployment failures can be retried or diagnosed automatically, and some can be corrected and re-run. Recovery attempts are limited on purpose and may still need a developer.
Deployment logs for every run, and application and server health from the project dashboard. Server-level metrics are set up for supported VM-based architectures.
On supported server-based topologies, the previous version keeps serving until the new one passes its health check. Some changes, including certain database or infrastructure operations, can still need downtime.
Connect supported custom domains and provision HTTPS. Some providers and registrars need a guided DNS step from you.
Add supported databases, caches, queues, storage and email services when the application needs them. Connection settings are stored encrypted and wired into the service that uses them.
Manage environment variables and apply them with a targeted redeploy. On server-based architectures, open a browser terminal to your own servers.
Make supported changes through the dashboard or the project copilot: attach a service, add a domain, scale a server, redeploy. The copilot proposes a change and you confirm it before it runs. Redeploys and resizes appear in the project's deployment history.
AI helps analyze the repository, explain architecture choices, diagnose failures and propose changes. Privileged actions run through defined application operations, not free-form model output.
Deterministic scanners read manifests, lockfiles and configuration to find deployment facts. AI interprets how the pieces relate and explains the findings; it does not overrule what the scanners detected.
The planner turns repository findings and your choices into a structured deployment proposal: which services, which provider resources, which steps.
Deployment steps come from the engine's own step definitions, not from model-written scripts. Server commands proposed by the recovery agent or the copilot are checked against a list of blocked destructive patterns before they run.
Infrastructure actions are performed by the deployment engine through provider APIs. Plans carry references to secrets rather than their values; the engine resolves them at the moment of use, outside model prompts.
Depending on the architecture you choose, The Deployer uses familiar tools and provider-native services for containers, TLS, databases, monitoring and deployment. The exact stack varies by application and cloud provider. Open-source-first, with provider-native services where they are the better fit.
The scanner works out the language, the framework, the port your app listens on and the lock files it pins, then prepares build and run steps. These are the stacks it understands today.
Built with something else? If your repository already has a Dockerfile or a Compose
file, The Deployer can use it. Every scan ends with a verdict on whether the project deploys
automatically, needs input from you, or is not a fit yet, before you connect a cloud account.
See supported languages
and app limitations.
The Deployer needs permission to create and manage infrastructure for the projects you authorize. The security model should make that access understandable, limited, revocable and auditable. Here is where it stands today.
The docs list, per provider, the credential you create, the access it grants and how to revoke it. Today most connections use long-lived provider keys or tokens you create; we say so plainly.
You choose the architecture and start the deployment. Changes proposed by the copilot are shown for confirmation before they run.
Cloud credentials and secret values are kept out of AI prompts by design. AI produces proposals; the deployment engine performs authorized actions.
Every deployment, redeploy and resize is listed in the project's history. Sensitive account actions, such as revealing or replacing a stored credential, are written to an audit log. A view of that log in the app is not available yet.
The Deployer is useful when owning the cloud account, seeing the infrastructure, or moving beyond a closed hosting platform matters to you. It is not automatically the best option for every project.
A static host or CDN may be simpler.
Staying on Vercel may be the easiest choice unless you specifically need customer-owned cloud infrastructure or a different architecture.
A simple managed host may be faster and cheaper to operate.
GPU workloads, unusual networking, regulated workloads or highly customized enterprise infrastructure may need capabilities outside current support.
| Option | Best when | Infrastructure ownership | Operational effort |
|---|---|---|---|
| Vercel, Render, Railway | You want the fastest managed path and their platform fits your app | Provider-managed runtime | Low |
| Direct AWS, GCP or Azure | You need maximum control and have infrastructure expertise | Yours | High |
| The Deployer | You want the application in your cloud but do not want to assemble the deployment workflow alone | Yours | Medium to low, depending on architecture |
| DevOps or platform engineer | You need deeply customized infrastructure or organization-wide platform engineering | Yours | Managed by your team |
You can build and debug the application, but do not want to spend the next week learning provider-specific infrastructure.
Your developers need a repeatable deployment path without maintaining a separate internal platform.
You need to hand a client an application that runs in the client's own cloud account.
You built the application quickly in Cursor, Claude, Lovable, Bolt, Replit or a similar tool and now need a transparent path to a real cloud environment.
Not sure your project fits? Run the public repository check before creating an account.
Your cloud provider bills you directly for infrastructure. A Deployer plan covers the deployment and operations platform. If you cancel, resources already running in your cloud account are not shut down. Infrastructure estimates are estimates, not billing caps. Paid plans upgrade from inside the app.
Loading current prices
Launch puts a supported repository live in a cloud account you own. Move brings an app that already runs elsewhere into your account, alongside the original, and switches traffic only after you approve. Both are fixed-price, with delivery conditions written down in the Refund Policy.
Loading current offers
How Launch works · How Move works · Your cloud provider bills you directly for what your app runs on.
Public documentation, no account needed: permissions, providers, supported stacks, limits, billing and troubleshooting.
Run the public repository check first. No account, no cloud connection. When you are ready, the Free plan includes one deployed project, with no credit card.
Questions about a stack we haven't listed, a deployment, billing or a partnership? Send a message and we'll reply by email. To report a security issue, write to hello@thedploy.com instead, as described in our disclosure policy.