Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

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

​
Prerequisites

  • GitHub connected
  • A repository StackShift can access

​
Workflow

1
Create a project from a GitHub repository.
2
Confirm framework/runtime detection and review the Advanced / Runtime section.
3
Override service type, workload type, resource preset, timeout, web3 detection, or persistent storage if the defaults are wrong.
4
Trigger the initial build and watch build output and deployment state.
5
Use subsequent pushes or manual redeploys as needed.

​
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

The project is connected to a GitHub repo and can build and deploy through StackShift.

​
Common failures

  • Repo permissions are incomplete
  • Build settings do not match the app runtime
  • Build succeeds but deploy fails due to runtime config

Connect GitHub

Link GitHub so project-style deployments can pull repositories and deployment metadata cleanly.

Builds, deployments, and logs

Understand the project execution lifecycle: build output, deploy state, rollback behavior, and where to inspect logs.

Project 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.