/
Menu

Deploy targets

Send a new key from your browser to a Vercel project, GitHub repository or Netlify site and redeploy it, without the value passing through StackHangar.

A deploy target is a place a value is sent to: a Vercel project, a GitHub repository or a Netlify site. Add one to an item and the Rotate, Leaked key and Launch playbooks can send the new value there and redeploy for you. One value sent to one target is a delivery.

#Before you start

  • You need the Solo plan to send and redeploy from your browser. Without it, every step still works by hand. See Plans.
  • The item needs a saved value.
  • You need a token for the provider saved as an API key item in your vault, with its value saved. This is the token StackHangar uses to call the provider. It must be a different item from the one you're sending.

#Add a deploy target to an item

  1. Open the item and find the Push targets section. It shows how many targets the item has, out of 10.
  2. Under Add a target on, choose Vercel, GitHub or Netlify.
  3. Pick the token item, enter the details below, then choose Add target.

Edit or remove a target with Edit and Remove. Removing a target doesn't change anything at the provider.

#Vercel

  • Variable name: the environment variable, such as STRIPE_SECRET_KEY. Letters, digits and underscores only.
  • Project ID: in Vercel, open the project, then Settings, General. It starts with prj_.
  • Team ID (optional): only for a project owned by a team. It starts with team_.
  • Environments: Production and Preview. The value is stored as a sensitive variable at Vercel, which Vercel doesn't allow in Development.
  • Redeploy production afterwards: needs the Production environment.

#GitHub

  • Variable name: the name of the secret.
  • Owner and Repository: the two parts of owner/repo.
  • The value is saved as a repository Actions secret. It is sealed on your device with the repository's public key before it is sent.
  • Run a workflow afterwards: enter the Workflow file, such as deploy.yml, and the Branch. The workflow needs a workflow_dispatch trigger, because a workflow reads the secret when it starts.

#Netlify

  • Variable name, Team slug or ID and Site ID.
  • Contexts: All contexts, Production, Deploy previews, Branch deploys or Local development (netlify dev).
  • Start a new build afterwards: environment variable changes only apply to a new build.
  • A Netlify token can't be limited to one site. Whoever holds it can change every site in the account. You have to tick I understand this token can change every site in my Netlify account before the target can be saved. Use a personal access token with an expiry and keep it in your vault.

#Where the token is kept

The token is an ordinary item in your vault, encrypted on your device like everything else. Your browser decrypts it only at the moment it calls the provider, and it goes only in the request to that provider.

#Send a value

When a playbook reaches a push step, the run shows a Send to your deploy targets card. It lists exactly which variable goes to which target and environment, and any redeploy that follows. Nothing is sent until you press the button, which reads like Send 2 values and redeploy.

  1. Check the list.
  2. Press the button. Your browser sends each value in order, then redeploys.
  3. The steps show Sent from this browser. when they succeed.

Steps are done one at a time and stop if your vault locks. A step that went through but couldn't be saved can be run again safely, because sending the same value twice is safe.

#Production values

If an item is in the Production environment, sending its value needs a passkey check first, unless you did one in this tab in the last 2 minutes. The card says so. Public values and redeploys don't need it. See Unlock your vault and Passkeys.

#Redeploying

A redeploy is a separate step after the push, and only appears if you turned it on for the target:

  • Vercel: starts a new production deployment of the project.
  • GitHub: runs your workflow on the branch you chose.
  • Netlify: starts a new build of the site.

A redeploy step waits for its push step. If the push fails, do it by hand, and the redeploy becomes available.

#If a send fails

A failed step stays pending and shows a fixed message, never the provider's own text. For example the provider didn't accept the token, the token lacks permission, the target wasn't found, or the provider is limiting requests. Below it is the by-hand route:

  1. Set the variable yourself at the provider. The step shows the variable and where it goes.
  2. Use the copy button to copy the new value. It needs the same passkey check as copying a value on the item page.
  3. Use the provider link to open the right page.
  4. Choose I did this by hand.

If the target was removed from the item after the run started, the step says so. Skip it, or do it by hand.

#What StackHangar's server sees

Nothing. Your unlocked browser calls Vercel, GitHub or Netlify directly. The token, the value and the provider's answer never pass through StackHangar's servers. The run keeps only a fixed failure kind and the HTTP status of a failed try, in your encrypted vault.

Your browser is limited to those three providers' API addresses for deliveries.

For an agent's secret request, which can also lead to deliveries, see Secret requests.

#Launch and deploy targets

In a launch, a connect step picks the target for the host (Vercel, Netlify) or for CI (GitHub). You choose a token, then Find my projects, Find my repositories or Find my sites, and pick one, or enter it by hand. The launch then sends public values and your keys there and redeploys once at the end, not once per value. See Launch.