deploy
Publishes your preview to your live site with no downtime: a test run first, then the publish, or one scheduled for a set time. Your AI publishes only when you ask.
Publish · Can change or delete · actions: preflight, publish, rollback, schedule, cancel
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.
For your AI: this page as Markdown · llms.txt