Launching & reading the logs

This is the moment your app goes online. When you press Launch, The Deployer carries out the plan from your Workflow — provisioning, building, and deploying — while you watch every step happen in real time. You don't run any commands; you just follow along.

Starting the launch

On the Launch tab, click Launch architecture setup (later runs show Deploy again). The Provisioner agent turns your workflow into a detailed, step-by-step plan and starts executing it immediately. Live logs begin streaming right away.

Following along

The screen has two halves:

• On the left, a step-by-step timeline grouped into four clear phases:
  1. Provision infrastructure — set up the servers or managed hosting
  2. Configure servers — prepare them to run your app
  3. Deploy your app — build and start it
  4. Verify everything — confirm it's actually reachable
• On the right, a live log — the detailed play-by-play, scrolling as it happens. You can watch all steps together, follow the current step, or click any step to see just its logs.

Each step shows a status icon so you always know where things stand:

If a step fails, it usually fixes itself

A failure is rarely the end of the road. The Deployer works through an auto-recovery ladder before ever asking you for help:

1. Auto-retry. Many hiccups are temporary (a slow network, a service still warming up). The system simply tries again.
2. The Recovery Agent. If a retry isn't enough, an AI agent steps in to actually diagnose and repair the problem. It can connect to your server, read and edit files, run commands, search the web for solutions, and even fix your app's code, rebuild it, and commit the fix back to your repository — then continue the deployment. A great many failures are resolved here without you lifting a finger.
3. Only then, it asks you — or stops. If something genuinely needs a human (for example, a step marked Waiting on you), you'll get clear instructions and an "I've done this — continue" button. If a credential was rejected (say, an expired GitHub or cloud key), you'll get a one-click card to replace it and redeploy.

So if you see a step go red and then recover, that's the system working as designed. Give it a moment before stepping in.

It won't pretend to be done

The Deployer is fail-closed on reachability: it will not report success unless your app is genuinely reachable. The final Verify phase actually checks your live URL, waiting as needed for everything to come online. If your main app can't be reached, the deploy is marked failed rather than falsely green. The check covers your main app's URL; it doesn't test every page or feature.

Getting your live URL

When the run finishes successfully, your app has a public URL (web address) you can open and share. You'll find it, along with everything else about your running app, on the Dashboard. Want a custom web address instead of the default one? See connecting a custom domain.

Redeploys on your own servers are health-gated

Deploying again later (for a code update or a settings change) to an app already running on your own servers is a health-gated rolling update: the new version is brought up and health-checked beside the old one before traffic switches over. If the new version fails its check, the old one keeps serving.

The first deploy isn't rolling, since there's nothing running yet. Managed targets (such as App Platform, Cloud Run, Azure Container Apps or a static-site CDN) use the provider's own rollout. Some changes, such as database migrations or resizing a single server, can still cause downtime; a single-server resize typically takes the app offline for 1 to 3 minutes.

If you're still stuck

• Open the Chat tab and ask, "why did my deployment fail?" — the Diagnostics agent explains it in plain English. See using the AI assistant.
• You can Cancel a running deployment at any time, and re-open any past run from the Deployment history dropdown.
• More fixes live in common problems & fixes.