> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy from GitHub

> Use the repository-backed project flow when you want StackShift to detect the app, build from source, and let you override runtime behavior before the first deploy.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Create a project that follows the GitHub-driven build and deployment path.

## Prerequisites

* GitHub connected
* A repository StackShift can access

## Workflow

<Steps>
  <Step>
    Create a project from a GitHub repository.
  </Step>

  <Step>
    Confirm framework/runtime detection and review the Advanced / Runtime section.
  </Step>

  <Step>
    Override service type, workload type, resource preset, timeout, web3 detection, or persistent storage if the defaults are wrong.
  </Step>

  <Step>
    Trigger the initial build and watch build output and deployment state.
  </Step>

  <Step>
    Use subsequent pushes or manual redeploys as needed.
  </Step>
</Steps>

## What this path includes

* Repository-backed project creation
* Build and deployment lifecycle visibility
* Project-level logs, domains, and rollback surfaces after deploy

## What usually decides success

* Repository access and installation scope
* Correct build/runtime detection for the app
* Post-build runtime configuration such as service type, workload type, ports, env vars, timeouts, and domains

## How web3 detection behaves

* StackShift can auto-detect common web3 frameworks and dependencies and mark the project as web3-enabled.
* The detected value is still user-overridable in case the repo shape or dependency tree gives the wrong signal.
* Hardhat-, Foundry-, and Anchor-style contract repos often fit contract-build workloads better than always-on web services.

## Expected result

<Check>
  The project is connected to a GitHub repo and can build and deploy through StackShift.
</Check>

## Common failures

<Warning>
  * Repo permissions are incomplete
  * Build settings do not match the app runtime
  * Build succeeds but deploy fails due to runtime config
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Connect GitHub" href="/getting-started/connect-github">
    Link GitHub so project-style deployments can pull repositories and deployment metadata cleanly.
  </Card>

  <Card title="Builds, deployments, and logs" href="/projects/builds-deployments-and-logs">
    Understand the project execution lifecycle: build output, deploy state, rollback behavior, and where to inspect logs.
  </Card>

  <Card title="Project environment, domains, and previews" href="/projects/environment-domains-and-previews">
    Configure the project surfaces that most often decide whether a deployment works after it builds, including runtime shape, domains, previews, and storage.
  </Card>
</CardGroup>