Deploy and update
A project deployment includes one built ESM handler file, its agent configurations, table exposures, and SQL migrations. The CLI reads stead.json from the current directory by default.
npx --yes getstead@0.2.1 deploy# Or select a configuration file:npx --yes getstead@0.2.1 deploy --config ./stead.jsonnpx --yes getstead@0.2.1 doctorPaths inside the configuration are relative to that file. The deployment response reports the bundle hash, newly applied migrations, and agent names. A successful command does not automatically test your customer UI or provider credit; run the starter journey and the optional provider check as needed.
Update code or configuration
Section titled “Update code or configuration”Edit your handlers and rebuild any bundled dependencies, update stead.json, and deploy again. Keep the bundle below the hosted size limit. Do not ship node_modules, source maps containing secrets, or provider keys in the bundle.
Deployment publishes the supplied agent set. Include every agent intended for new runs. Previously started runs keep their recorded deployment, so an update does not silently replace a pending approval’s program.
For schema changes, add a new numbered migration. Do not edit or delete applied migration files. Review destructive SQL yourself: a migration can delete your project’s data, and publication does not provide an automatic rollback for it.
Interrupted deployment
Section titled “Interrupted deployment”Check Diagnostics and the current project state before retrying. A committed database migration can be waiting for deployment publication to recover. Retry the same unchanged files after recovery; the migration receipt identifies already applied work. Do not create a new filename to bypass a hash mismatch.
If validation fails, fix the reported bundle, configuration, exposure, or migration issue and deploy again. A SQL permission error means the operation is outside the restricted project role’s capabilities; changing the spelling of the SQL does not grant server administration.
Deploy from automation
Section titled “Deploy from automation”Create a named project credential in the console’s Credentials page. Store it in your CI secret store and supply STEAD_PROJECT_SECRET and STEAD_API_URL=https://api.getstead.dev to the deployment process. This avoids an interactive developer login.
Project credentials are administrative. Do not place them in stead.json, commit them, or expose them as frontend environment variables. Rotate them using the credentials guide.
Delete a project
Section titled “Delete a project”Use the console or getstead projects delete "$PROJECT_ID" --confirm-name "$PROJECT_NAME". This permanently deletes the project and its associated resources. Deletion is asynchronous; the project list reports its progress. Do not use deletion as a routine remedy for a failed deployment or a stuck run.