GitHub Integration

Connecting your account

Dashboard → Deploy → Connect GitHub, or simply Sign in with GitHub — SSO login is the connection. SnapDeploy requests three scopes:

• repo — list and clone your repositories (private ones included) and install the deploy webhook
• read:user and user:email — your login and verified email, used to match the GitHub identity to your SnapDeploy account

Repositories owned by an organisation appear only after the organisation has approved the SnapDeploy app (GitHub → organisation settings → Third-party access). One GitHub identity connects to one SnapDeploy account; signing in with GitHub on an account that has the same email asks for your password once and links them.

Linking a repository to a container

1. Choose repository and branch. The link is repository + branch → container; the same branch cannot be linked to two containers, but different branches can (a main container and a staging container from one repo is the usual pattern).
2. Optional root directory for monorepos — the folder that contains the app's package.json, requirements.txt, go.mod or Dockerfile. Detection, the env-var scan and the build all run relative to it.
3. Linking triggers the first build. SnapDeploy installs a webhook on the repository, clones the branch with your authorisation, runs detection and builds. What happens next is on the deployment guide.

Automatic deployments

Every push to the linked branch starts a new build; pushes to other branches are ignored. The deployment history records the commit message and the GitHub login of the pusher, so a team can see who shipped what. Rules worth knowing:

• Each push counts toward the free tier's deploy limit — 10 a day, 5 per rolling 12 hours — and a failed build still counts. Always-On containers have no limit.
• A push while a build is already running is refused with "a deployment is already in progress"; push again when it finishes.
• A redeploy never takes traffic until the new task is healthy; if it never becomes healthy the previous version keeps serving and the deployment is marked failed.
• Manual redeploys from the dashboard, the API or an AI assistant use the same pipeline and appear in the same history with their own attribution.

Monorepos and multiple apps

One repository can back several containers — apps/web and apps/api as two containers, each with its own root directory, environment and domain. Because the link is per branch, both are rebuilt on every push to that branch; if that is too eager, deploy them from separate branches. Shared packages outside the root directory are not visible to the build — vendor them or publish them.

Unlinking, disconnecting, revoking

• Unlink a repository on the container page: the webhook is removed and the container keeps running its last image. Link a different repository, or the same one again, at any time.
• Disconnect GitHub in Settings: SnapDeploy discards its token; existing containers keep running, but no pushes are received and no new links are possible until you reconnect.
• Revoke from GitHub (Settings → Applications) has the same effect; reconnecting from the dashboard repairs it.
• Unlinking is an interactive action — API keys and AI-assistant tokens cannot do it (403 INTERACTIVE_SESSION_REQUIRED), which is deliberate.

Deploying from scripts and assistants

POST /api/mobile/deploy creates a container, links a repository and starts the first build in one call; POST /api/mobile/github/link/{repoLinkId}/deploy rebuilds a linked one. Send an Idempotency-Key so a CI re-run inside ten minutes returns the original deployment instead of a second build. The MCP connector does the same from Claude Code, Cursor, Codex CLI and Gemini CLI with scoped tokens. Reference: API.

Troubleshooting