Deploy and share a result
Use /deploy to host a built web artifact at a *.indigo-hq.com URL and pick the access gate that matches how sensitive it is.

Hosted result
/deploy hosts a web artifact at a URL; the gate controls who can open it.

Have a built artifact
/deploy is for web artifacts: a directory with an index.html or a framework build, not a backend or serverless service.
Confirm you have a buildable web artifact and that you are in the right company context before deploying.
Run the deploy
/deploy resolves your company, builds, uploads, and returns a live link on *.indigo-hq.com.
Run /deploy with the artifact path and wait for the engine to return the live link.


Pick the access gate
Access modes are public for anyone with the link, password for casual sensitive content, company for HQ Cognito org-only, and private for an email allowlist.
Use public for casual results and password, company, or private for anything sensitive, then share the link.
Keep the chapter executable.
Resolves the company, builds, uploads, and returns a live *.indigo-hq.com link with a chosen access gate.
Use this instead when you need to grant access to vault files rather than host a web app.
What goes wrong, and the fix.
Trying to deploy a backend or serverless app with /deploy.
/deploy is for web artifacts; host backends elsewhere or expose an ingest-only endpoint.
Leaving sensitive content on the default public gate.
Set the gate to password, company, or private before sharing the link.
Confusing /deploy with /hq-share.
Use /deploy for a hosted URL and /hq-share for vault file access.
What to keep in mind.
Deploy vs share
/deploy hosts a web app at a URL; /hq-share grants access to vault files. Choose deploy for a hosted page and share for file access.
Access gates
Public for casual links, password for casual sensitive, company for org-only, and private for an email allowlist.
