Applications
Source control
Connecting GitHub or GitLab, how push-to-deploy is wired, and what breaks when a token expires.
Nautvia deploys from GitHub or GitLab. The connection is made once per team, under Source control, and only the team owner can make or remove it.
Only gitlab.com is supported. Self-hosted GitLab instances are not.
What access is requested
| Provider | Scopes |
|---|---|
| GitHub | repo, admin:repo_hook |
| GitLab | api |
repo is needed to download the commit you are deploying; admin:repo_hook is what lets Nautvia register the webhook that makes push-to-deploy work.
A provider only appears as an option if it has been configured on the platform side. If neither is available, the create-site page says so instead of offering a dead button.
How your code is fetched
Nautvia does not git clone. It downloads a tarball of the exact commit from the provider's API and unpacks it into a new release directory. There is no .git directory on the server, and nothing on the server can push back to your repository.
The token is passed to curl through a file readable only by the deploy user, and deleted when the build finishes.
Push to deploy
Creating a site registers a webhook on the repository. Pushes to the environment's branch then deploy automatically.
Nautvia verifies every delivery — GitHub's X-Hub-Signature-256 HMAC or GitLab's secret token — and ignores anything that is not a push to that branch: tag pushes, branch deletions and other event types are dropped.
If a push arrives while a deploy is running, it is remembered and starts when the current one finishes. Only the newest is kept: three pushes during one deploy result in one further deploy, of the last commit. This is deliberate — deploying every intermediate commit in sequence wastes minutes for a result nobody wanted.
Webhook registration is best-effort. If it fails — usually because the token lacks hook permission — the site is still created and deploys still work from the dashboard; only automatic deploys are missing.
Disconnecting
Removing a provider under Source control does not remove webhooks from your repositories, and does not disable your sites. What it does is break the next deploy of any site that used it, with "The site has no connected git provider."
Reconnecting fixes it. Delete the stale webhook in your repository settings yourself.
When a token expires
Nautvia stores the access token but does not refresh it. If you revoke access, or the provider expires the token, two things break quietly:
- the repository picker on the create-site page shows an error with a Retry button;
- builds fail while downloading the tarball.
The fix in both cases is to disconnect and reconnect the provider.
Private repositories and monorepos
Private repositories work — that is what the token is for. Monorepos are not supported: the tarball is unpacked at its root and Magento is expected to be there. There is no subdirectory setting.