Source Control

Primcloud deploys from git. You connect a repo once, and every push to a mapped branch triggers a build and a rolling release. This page covers the connection itself: how to set it up, what it grants, and how to change or revoke it later.

Supported providers#

GitHub is the supported provider today. Other providers are on the roadmap and will be listed here once they're live.

Connecting GitHub#

The connection is a GitHub App installation. From your account settings, click Connect GitHub and you'll be handed off to GitHub's installation flow.

GitHub asks whether to grant Primcloud access to all repositories in your account or only select repositories. Both work, so pick whichever matches how you manage access. You can change it later without disconnecting.

Once you complete the install, GitHub sends you back to Primcloud and the installation shows up in your Providers list. From then on, every repo the App can see is selectable when you create or edit an application.

Repository access#

Repository access is managed on GitHub's side, not Primcloud's. You have two knobs:

• Add a repo to Primcloud's access. Go to your GitHub account settings → Applications → Primcloud → Configure, and add the repo to the allowlist. It shows up in Primcloud's picker immediately, no re-connect needed.
• Revoke a repo. Same screen: remove the repo from the allowlist, or hit Suspend to pause the App entirely.

If you remove access to a repo that has an application deployed from it:

• Running pods keep running. Removing access doesn't take your app offline. The deployed image already lives on Primcloud, independent of GitHub.
• New pushes stop triggering deploys. Primcloud stops receiving webhooks for the repo, so future commits won't build.
• Release-only actions still work: a rollback, or a deploy from a secret or compute change, re-runs the last built image without fetching code. Anything that rebuilds (a push, a manual deploy, a redeploy) needs to clone the repo and fails until access is restored.

Branch to environment mapping#

An environment tracks exactly one branch. Push to that branch and the environment redeploys. On Standard every application has a single production environment, so production tracks the branch you picked at import, commonly master or main. On Pro and Team, each additional environment tracks its own branch.

Change the tracked branch any time from the application settings page. The branch picker fetches your repo's branches live from GitHub. The next push to the new branch triggers a deploy, and the old branch stops driving the environment.

You can also trigger a deploy by hand from the dashboard. A manual deploy rebuilds and releases the current commit again, without waiting for a push. See Deployments for the full deploy lifecycle.

What happens on push#

When you push to a mapped branch, GitHub fires a webhook at Primcloud. Primcloud finds the environment that tracks that branch, kicks off a build against the pushed commit, and, if the build succeeds, releases the resulting image with a rolling update. No traffic gets dropped during the swap. If the build fails, nothing changes for the running app; the failed deployment is recorded and you can inspect the log.

Disconnecting#

Three ways to disconnect, from most direct to most drastic:

• Disconnect the provider from Primcloud. In your Providers list, hit Disconnect on the connection and confirm with your password. Every application using repos from that account loses its source: it is no longer linked to a repository, pushes stop deploying it, and a manual deploy or redeploy is refused until you pick a repository again in the application's settings. Running pods keep running.
• Remove a single repo from the allowlist on GitHub (Settings → Applications → Primcloud → Configure). The App stays installed for your other repos; deploys stop for the removed one.
• Uninstall the App entirely (same GitHub screen, Uninstall). All repos lose Primcloud access at once. When GitHub tells Primcloud about the uninstall, the provider disappears from your Providers list and every application using repos from that account loses its source, just as with a disconnect.

The "running pods keep running, new pushes stop deploying" behavior applies to all three. An application without a source shows a banner saying so; pick a repository from its settings page (Change on the Source card) to link it again, which also deploys the latest commit on the chosen branch. A rollback to an earlier release works without a source.

Troubleshooting#

A repo you just granted access to isn't showing up. Primcloud caches the repo list for a minute, so wait a moment and refresh the page. If it's still missing, open your GitHub App configuration (Settings → Applications → Primcloud → Configure) and confirm the repo is on the allowlist.

"No repositories available" when creating an app. The GitHub App is either not installed on your account, or installed with zero repos in the allowlist. Reinstall from Primcloud's Connect GitHub button, or edit the allowlist to grant at least one repo.

Pushes aren't triggering deployments. Check three things: the branch you pushed is actually the one the environment is tracking (typos happen); the GitHub App still has access to the repo; the last recent commit in the deployments list has a webhook timestamp. If GitHub's App configuration page shows recent webhook deliveries failing, forward the delivery ID to support and we'll dig in.

Deployments started failing right after removing repo access. Restore the access. Primcloud needs to clone the repo to build. Deploys that were queued while access was revoked will need to be retriggered manually after access is back.