GitHub deployments
Keep your source in GitHub and let Shipped handle the deployment. Use the repository workflow that already fits your team.
Connect the repository you want to ship
Choose the repository and application you want Shipped to build. Define the build command, runtime, and services in the project’s deployment configuration. For a monorepo, keep the application directory and required shared source explicit so the build includes what it needs without treating every package as a separate public service.
Make releases easy to trace
A repository-based release ties the deployed application to a source revision and its build result. Review deployment progress, health checks, and logs from the same project. When a change causes trouble, release history helps you identify what changed and select a previous compatible build without reconstructing the original deployment by hand.
Keep infrastructure changes reviewable
Manage build settings, service definitions, and resource requirements alongside your application’s workflow. Shipped presents meaningful resource changes and their costs before they are applied. Keep secret values in protected configuration rather than committing them to the repository, and use separate environment bindings when the same source runs in staging and production.
A little more detail
Questions about GitHub deployments?
Is GitHub required to use Shipped?
No. You can also deploy directly from your coding agent using a local source snapshot. Choose GitHub when repository history and your existing review process suit the project.
Should I commit database passwords in the deployment configuration?
No. Store secret values through Shipped’s secret configuration and reference the appropriate resources for each environment. Your repository should describe the application without exposing its credentials.
From your workspace to the web