First Deploy — signup to live URL

The customer-journey view of Anatomy of a Deploy: the path a new user walks from signing in to a running service, targeting under 10 minutes. A composition of already-designed pieces — no new machinery. (Small section; to be refined.)

1. Sign in with GitHub or Google — account auto-created, verified-email linking (Auth & Sessions).
2. Create a workspace, then a project — the project picks its default region (FR-077); production (protected), staging, and dev environments are created with it (§15).
3. Install the GitHub App and pick a repo (§16.11).
4. Create the service — wizard defaults: type web, branch main → production, auto_deploy: true, tier from the plan; Railpack detects the framework, no Dockerfile required (§16.5). Default deploy target is production (instant gratification; the customer can retarget).
5. First deploy runs automatically — webhook → build → push to the region registry → desired state → Shuttle applies → the five-stage progress view → live at <service>-<rand4>.starform.app; logs + metrics appear (FR-049 / FR-050).
6. Next steps the UI surfaces — add a database (Mininova one-click), set a health-check path (§20.3), add a pre-deploy command (FR-086), link another service (Connections), or invite a teammate (§15).

---

Cross-references

The system-level version of this thread → Anatomy of a Deploy · auth → Auth & Sessions · build → Starforge · the service model → Services & Environments. Canonical map: Canonical Sources.