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.
How StackShift builds your app
- Shiftpack is the native build engine: it detects your framework and runtime, then builds straight to an OCI image without you writing a Dockerfile.
- It builds with BuildKit under the hood, so dependency caching and reproducible images come for free.
- If your repo has its own Dockerfile and you point StackShift at it, that takes over instead of Shiftpack.
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
Related guides
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.