What the app can't (yet) do
The Deployer does a lot automatically, but it's not magic, and we'd rather be upfront than have you hit a surprise. Here's an honest list of things it can't do yet, or can't do for every setup — with what to expect and, where there's one, a simple workaround.
Hetzner isn't available yet
Hetzner shows up in the provider list marked "Coming soon," but you can't deploy to it today. For now, use one of the four supported clouds: AWS, Google Cloud, Azure, or DigitalOcean. See supported cloud providers.
Some extras are fully automated only on AWS
Every supported provider can run your app and connect a custom domain. The difference is polish: on AWS, connecting a domain is completely hands-off, while on Google Cloud, Azure, and DigitalOcean it may need one guided step where you update your domain's nameservers. It's a normal, one-time task and the app tells you exactly what to change, then checks it worked. Not a blocker — just a little more involved.
The AI won't fix every failure
When a deploy hits a snag, The Deployer's recovery agent diagnoses supported failures and tries to repair them automatically. It makes a limited number of attempts on purpose, so it can't loop indefinitely or keep creating resources. Occasionally a deploy fails in a way that needs you to adjust something in your code and try again. When that happens, the logs explain what went wrong so you know where to look.
It deploys apps, not "anything"
The Deployer is built for web apps, APIs, static sites, and background workers that live in a Git repository. It is not a general-purpose "run anything" platform. Very unusual stacks, or apps that need special hardware like GPUs, may not be supported. If your project is a fairly standard web app, you're well within bounds — see supported languages & frameworks.
Costs shown are estimates, not your final bill
The price you see in the app is a helpful estimate to set expectations. The actual charges come from your cloud provider and depend on real usage. It isn't a spending cap. Treat the number as a ballpark, and check your provider's own billing dashboard for exact figures. More detail in costs & billing.
Supported Git hosts
The Deployer reads code from GitHub, GitLab.com and Bitbucket Cloud. Self-managed GitLab and Bitbucket Server/Data Center aren't supported. See connect GitHub or connect GitLab or Bitbucket.
Cloud access uses long-lived, broad credentials
Cloud connections currently use long-lived keys, and deploys need broad permissions because we don't yet publish least-privilege policies per architecture. Use a dedicated cloud account or project for The Deployer. Role-based and federated access are planned. See permissions & security.
Not every deploy is downtime-free
Health-gated rolling updates apply to redeploys of server-based apps that are already running: the new container must pass its health check before the old one is removed. A first deploy isn't rolling, managed targets use the provider's own rollout, and resizing a single server takes it offline for about 1 to 3 minutes.
Your cloud's own limits still apply
Brand-new cloud accounts often start with low limits (for example, a cap on how many servers you can create, or Amazon's email starting in a restricted "sandbox"). Those limits come from your cloud provider, not from The Deployer, and only they can raise them. We cover how to check and lift them in cloud provider limits & quotas.
None of these are dead ends for a typical web project — they're just the honest edges of what The Deployer does today.