AI-assisted delivery and prompt history
End-user flow
Connect GitHub once for the workspace. For customer Azure, also authorize a deployment target once. Create an application with its repository and branch connected, then choose Copy prompt in AI setup. Paste it into your coding tool and describe the application. The tool connects the local project, builds, verifies, commits relevant changes, and runs the CLI shipping command. Both hosting paths use GitHub as the deployment source of truth.
Generating a setup prompt requires source-management permission and a connected repository. The prompt contains only the agent guide URL and public app reference; it has no credential or expiration and creates no CLI session. The guide bootstraps a fresh machine and invokes browser authorization. The user signs in, selects the application's organization, and explicitly approves 7, 14, 30, or 90 days of app-scoped CLI access. The CLI saves the credential outside the repository with restricted filesystem permissions. Production still requires an explicit request and existing server approval policies. Legacy pairing commands remain supported.
The CLI obtains a short-lived GitHub App credential restricted to the connected repository with Contents write permission. It is supplied to Git through process environment configuration, never persisted in the remote URL or project files. Workspace GitHub installation consent remains necessary. The CLI does not bypass coding-tool confirmations or branch protection.
The setup page does not display an executable, unauthenticated preview. Copy prompt generates a fresh paired prompt and displays that same prompt for manual copying if browser clipboard access is unavailable. The displayed prompt is held in page memory, not browser storage, and is cleared after 15 minutes or when changing applications; treat it as a temporary application-access credential. Handoff failures never fall back to an unpaired prompt. Supply application requirements alongside the prompt: setup alone cannot tell the coding tool what to build.
Configure the API's PublicApiUrl with its externally reachable HTTPS origin (an optional /api suffix is normalized). Both setup and handoff use that address rather than internal reverse-proxy HTTP addresses. Without configuration, non-loopback requests use https://api.backify.dev/api; local loopback development may use HTTP. Insecure or malformed configured addresses are rejected before connection.
CLI workflow
The copied prompt contains only the public app reference and agent-workflow link. The guide constructs browser connection and initialization commands and supplies the public API URL (https://api.backify.dev/api). Organization and credentials come from explicit browser approval; repository, branch, and hosting details come from authenticated CLI status.
The root agent site serves instruction version 18, and the copied prompt points to https://agent.backify.dev. Its complete workflow is served at https://agent.backify.dev/v18/delivery.md (with /delivery.md and /BACKIFY.md as latest-version aliases) and installed as BACKIFY.md, referenced from the agent instruction files. Both use the same source so request-history privacy, initial-request capture, hosting requirements, checks, commits, shipping, failure recovery, and policy gates remain consistent. Archived versions 1-17 remain unchanged. Safe authenticated source updates run automatically when connecting an existing repository and before agent edits for each new user request, using backify pull: clean fast-forward only, with dirty or diverged histories reported instead of stashed, reset, or rebased. The agent guide explains when to add --clone, including workspaces with populated tool-metadata directories and default work/outputs directories, and how to proceed safely without routine user deployment input.
Commands introduced in CLI 0.3.0:
connect: pair or use browser login, verify application access, and optionally clone its repository.connect --reauthopens the authorization browser, lets the user approve 7, 14, 30, or 90 days, and replaces an expired/revoked application credential automatically. Authenticated commands retry once after browser recovery on expiration/401; unattended agents can use--no-browser --jsonand ask the user to run the returned reconnect command. See CLI browser reconnection and rollout.status: inspect hosting, reports, releases, and the latest failed deployment.report --check: run doctor and available typecheck, lint, test, and build scripts; send only bounded metadata and check statuses. Without--check, scripts are marked not-run.prompt record --stdin --id <UUID> [--filename <basename> ...] [--model <model>] [--ai-tool <tool>] [--access-level <access>]: append one user request, using the same UUID on retries.ship [--production-deploy] [--timeout <seconds>]: verify the repository-root project, branch, clean committed source, checks, and packaging; push without force; wait for the exact source's healthy preview and return its URL. Production publication requires explicit--production-deployor promotion from the preview in the portal. The legacy--preview-onlyflag remains supported but cannot be combined with--production-deploy. Retries recognize already-pushed source and its direct Backify CI build commit without pushing backwards. A failed preview can be retried; an in-progress preview is awaited. Other remote changes require a clean fast-forward pull or explicit history reconciliation.disconnect: revoke application sessions and remove the local application credential.logoutonly removes local credentials.
Backify Cloud requires static output containing index.html. New workflows detect dist, build, out, or repository-root output after building and commit an output marker with the artifact. The worker honors that marker while retaining path containment checks. Private dotfiles, Git metadata, node_modules, and Backify agent/configuration files are excluded from static publication. Generated build commits retain their original source SHA so the CLI waits for the correct release, then fast-forwards the clean local branch to the tested build commit before the next request.
Customer Azure requires a repository-root Dockerfile with its HTTP server listening on 0.0.0.0:8080. GitHub builds and pushes an immutable image; Backify deploys it. Neither the CLI nor application code provisions Azure directly.
The ship command never stages or commits files. The coding tool commits only changes relevant to the user's request. Shipping is preview-only by default; coding tools must not add --production-deploy unless the user explicitly requests production publication. It never attests to preview testing. With --production-deploy, required testing stops at a preview URL and required approval creates an approval request. A production URL is reported only after the exact preview has been activated and verified healthy. Existing permissions, organization/workspace policy, and server-side deployment checks remain authoritative.
Prompt history and privacy
The CLI automatically records the current device hostname, operating system, architecture, installed CLI version, and Git HEAD with each prompt. If Git HEAD is unavailable, the commit remains unrecorded. Use --commit-sha <full-SHA> to pin the original commit when retrying after HEAD changes, and reuse the original AI and device metadata. Device details fall back to the authenticated application-scoped session for older clients. These details are self-reported context, not authorization evidence.
The history API resolves each recorded user ID to the user's current display name on the server; the portal displays that name under User, not the raw UUID. Missing historical metadata or an unavailable user name displays Not recorded. Attachments remain filename-only and display None when absent.
Application People & access → CLI access provides per-device session inspection, last-use/network metadata and individual revocation. See CLI access for permissions, trusted-proxy/offline country lookup configuration, historical limitations and rollout requirements.
New initialization writes instruction version 18 and BACKIFY.md, referenced only from the current coding tool's instruction file. Select that tool with --agent codex, claude, copilot, gemini, cursor, cline, or windsurf; or --instruction-file
Prompt history appears under the application. Requests are paginated oldest-first using server-assigned sequence numbers. UUID-based idempotency prevents duplicate records on retries; reusing an ID for different text is rejected. Records include user text, attachment basenames, recording time, user identity, and an optional full source commit SHA. Attachment paths are reduced to basenames on both client and server. No attachment is opened by the recording command. File bodies, images, extracted content, and arbitrary extra JSON fields are not accepted by the API. Each prompt is limited to 32000 characters and 50 filenames. Record the model, AI coding tool, and effective access for each request with --model, --ai-tool, and --access-level whenever known. Access is a short description of the tool’s actual filesystem, network, and approval permissions at the time of the request, not its Backify role. Use only exposed session information; never guess unknown values or inspect credentials to discover them. Omit unknown fields; older or incomplete records display “Not recorded”. These values are self-reported metadata, not verified authorization. Reuse the same metadata on retries. Model and tool names are limited to 200 characters each; access descriptions to 500. Never include secrets, tokens, full paths, or configuration file contents.
App readers can view history; source managers can append it. Tenant/application access checks apply to both. Prompt text is rendered as plain text rather than executable HTML. Reports are advisory local claims, not independently verified release evidence. Do not put credentials or confidential file contents directly into prompt text.
There is no universal coding-tool chat hook. Capture relies on the tool following the persistent instructions, or an integration explicitly invoking the command. Backify cannot guarantee that an arbitrary tool submits every request; submission failures must be surfaced rather than silently ignored.
Rollout
Publish CLI 0.3.0 before exposing copied prompts that reference it. Deploy the API, worker, and portal together; startup applies the additive ApplicationDevelopment migration. No live database migration or npm publication is performed by source implementation alone. Refresh workflows for previously connected repositories through the Code connection flow to adopt output detection. Existing sessions are not automatically granted production-publication permissions.
This delivery flow does not implement missing shared-hosting function runtimes or SDK brokers. Unsupported runtime paths remain blockers; successful static delivery does not establish full-stack SDK support. See wildcard routing and preview releases.