A preview needs two kinds of configuration
A branch preview needs more than credentials created for that branch. It also needs the ordinary settings every Preview deployment uses: application services, shared development integrations, feature configuration, and the deployment platform's own project settings. Asking a provisioning system to copy all of that would turn it into a second deployment platform. Letting Production configuration flow into every pull request would be worse. The reliable model is composition. Vercel provides the reviewed foundation for the Preview environment. Instaship adds a branch-scoped overlay containing the provider credentials and metadata it just created. The workflow pulls the combined configuration after minting, builds the exact pull-request commit, and deploys it to the URL the provider manifests already expect.
The branch should inherit its foundation and receive only what the branch changed.
Three homes with separate responsibilities
Workflow authority belongs in GitHub Actions. The scoped Instaship API key and the token used to deploy to Vercel are repository secrets; neither belongs in the running application's environment. Stable application configuration belongs in Vercel's shared Preview target, where every value can be reviewed before all branches inherit it. Generated provider values belong in Vercel's branch override, written by Instaship only after the provider resources exist. This separation makes rotation and cleanup understandable. Replacing a workflow token does not change application configuration. Updating a shared Preview value does not recreate a GitHub App. Cleaning one branch removes its generated credentials without deleting the foundation the next pull request still needs.
Choose the URL before anything exists
OAuth callbacks and webhooks need a concrete origin while the provider resource is being created. A deployment platform usually assigns its own generated URL later, which is too late for a deterministic manifest. Compute a DNS-safe URL from the branch first. Pass that address to Instaship, expose it to the application during build and runtime, assign it as the Vercel alias, and publish it in the pull request. One URL across those steps removes a subtle class of failures. The manifest cannot point at yesterday's deployment. The application does not generate links for a temporary Vercel hostname. A reviewer opens the same address that GitHub will call after installation.
Apply the branch schema before deployment
A Supabase branch is only useful when its schema matches the pull-request code. Instaship exports the connection for the database branch it created. The workflow loads that exact environment file, reconciles migration history, and applies the repository's additive migrations before Vercel builds the application. This ordering keeps code, provider credentials, and schema on one commit. It also avoids a dangerous shortcut: giving every preview a shared Production database connection merely because it is already available to CI.
Creation and cleanup are one contract
Use an explicit pull-request label to start provisioning, reject forks before loading secrets, and serialize work by branch without cancelling an active mint. When the label is removed or the pull request closes, remove the exact deployment and clean the Instaship environment using the same app and branch. Recording immutable environment and deployment IDs in the workflow's bot comment gives cleanup precise provenance. This makes the preview dependable to operate. The environment is easy to create, difficult to confuse with another branch, and expected to disappear when its work is finished.