# deploy (https://lazyfrog.dev/docs/tools/deploy)

{/* Generated by scripts/generate-docs.ts from the gateway's registered tools. Do not edit. */}

**{"Publish"}** · Can change or delete · actions: `preflight`, `publish`, `rollback`, `schedule`, `cancel`

<p>{"Publish the preview to production at https://<slug>.lazyfrog.app, with no downtime. Publish only when the user asked for it in this conversation, with user_asked: true; finishing the build, an agreed plan or \"go ahead\" isn't asking. Going live needs a paid plan: on Free, preflight, publish and rollback are refused up front with plan_limit (limit live_sites, the plans page as upgrade_url); tell the user once that going live needs a paid plan and their preview stays free to share while it's awake, then keep building in the preview. action \"preflight\": a dry run (a job): checks secrets (every preview secret name set for production), services.json (a start command for each web service, a worker with only dev runs on the preview only, healthcheck_path on web services, which must answer 200 without login), builds a copy, applies pending migrations to a copy of production, starts every service as production does (on $PORT, which apps must listen on) and health-checks it; reports the pending migrations, what makes any destructive, test results, the commits since the last publish, and keys, passwords or salts written in the code (secrets_in_code: ask the user once before moving them to the secrets tool; publishing refuses code that contains them). A first publish starts the live site empty unless seed_live_from_preview is true (nothing else is copied from the preview's database or /data): tell the user, and offer the copy when preflight's seed_offer says it is available; once the live site has data, preview and live keep separate data and publishing never changes live data. action \"publish\": the same, then commits and tags the preview's work, snapshots, migrates production and switches to the new release once it is healthy; the old one finishes its requests. When the live site runs an older platform version (project get says), a publish moves it to the current one first, with a restart of a few seconds. Follow both with the job tool; publish's result has the URL. summary: one or two sentences for the user about what changed, written from the commits. Destructive migrations (dropping tables or columns, deleting or updating every row, changing a column's type) need confirm: true. action \"rollback\": an earlier deployment live again in seconds (to: its number, default the one before; deploy_list shows which can be). The database stays as it is unless with_database: true, which restores it (and /data, when that deployment ran a migrate command that changes data there) to just before the first later deployment changed it (only when rolling back, and only if one did; content written on the live site since that publish, such as posts, pages and orders, is lost from the live site, though kept in a snapshot: tell the user; needs confirm and, when you ask, the owner's approval in the portal; the site is down for a few seconds). Destructive migrations, and restoring the live site's database or files from a snapshot, also need the owner's approval when you ask: the first refusal requests it. action \"schedule\": a change the user wants live at a later time (\"new prices from the 1st\", \"put the sale page up on Friday at 8\"): at is that time with the business's UTC offset (2026-12-01T00:00:00+02:00), 10 minutes to 62 days ahead, user_asked true and a summary; the preview's work is committed and built and rehearsed now like a preflight (a job: follow it), and that version goes live at its time, rehearsed again on the live data as it is then, even if the preview changes meanwhile. One per project; it can't include destructive migrations. A publish or a rollback going live before then cancels it (it would replace that change), except a publish with keep_schedule: true, which puts live only what the preview added after the scheduled one and keeps the schedule (it is built again on top, as a new deployment number, same time); the owners are emailed when it runs. action \"cancel\": cancels the scheduled publish (to: its number, optional). deploy_list shows what is scheduled."}</p>