Projects
Deploy from GitHub
LiveUse 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.
Goal
Create a project that follows the GitHub-driven build and deployment path.
Current status
Live
This area is documented as current, user-reliable behavior.
Workflow
- 1Create a project from a GitHub repository.
- 2Confirm framework/runtime detection and review the Advanced / Runtime section.
- 3Override service type, workload type, resource preset, timeout, web3 detection, or persistent storage if the defaults are wrong.
- 4Trigger the initial build and watch build output and deployment state.
- 5Use 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-, Truffle-, 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