Git integration

Push-to-deploy works with GitHub and GitLab. Connecting is one button — the webhook is registered for you and, on GitHub, nothing long-lived is stored at all.

Connections belong to a team

A connection is what someone actually granted: a GitHub App installation on an organisation, or GitLab access as themselves. A team connects a provider once, and its functions reference that connection and add only their own repo, branch and subdirectory.

Ten functions in one GitHub org is one installation, not ten. The team's settings show what is connected, which account it covers, and how many functions deploy through it — so a disconnect can tell you what it would break before you attempt it.

GitHub

Install the GitHub App. Install it with "Only select repositories", so it can read what you pointed it at and nothing else.

• The App asks for contents: read — enough to fetch an archive, not enough to push.
• Deploy credentials are minted per deploy and expire in an hour. Nothing derived from the App key is ever written to the database.
• The credential belongs to the organisation, not to you. When you leave, the functions connected through it keep working.

If you ask an org owner to approve the installation rather than installing it yourself, nothing is recorded until the installation actually exists — a function claiming an installation that was never approved would fail every push.

You can uninstall or re-scope the App in GitHub's own UI at any time; GitHub is the source of truth for what is installed, and reinstalling does not require reconnecting each function.

GitLab

Authorise GitLab once. The connect flow then provisions, on the project you choose:

• A project access token with read_api at Reporter level. It reads the archive and cannot push to the branch it deploys from, so a leak of it is not an arbitrary code deploy.
• A webhook pointing back at Functions, with its own secret.

Pasting a token

The manual path still works and is not deprecated:

• A public repository needs no credential at all.
• An organisation that will not install the App needs an escape hatch.

You supply the token and a webhook secret, then register the webhook in the repository yourself. Functions shows you the URL to use — it is /hooks/git/<provider>/<functionId> on the console origin.

Stored credentials are write-only. The API reports whether one is set and never returns it, which is also why saving one settings tab cannot wipe another's secret.

What a push does

A push webhook is verified by the provider's signature, then:

1. The branch is checked. Only the configured branch deploys — main if you have not set one. A push to a feature branch is ignored, and says so.
2. The archive is fetched at the pushed commit.
3. A version is built and promoted, recording the commit and ref.

A push to a branch you have not connected is a normal, frequent event, not an error.

Branch and subdirectory

Both stay editable after connecting. Subdirectory builds from a path inside the repository, so a monorepo can back several functions — each with its own subdirectory, all on one connection.

Provider and repository are fixed once chosen. A function that should deploy from a different repository is a different function: re-pointing one silently destroys the meaning of every version already in its history.

Deploying without a push

Not every reason to redeploy is a push — a build that failed on a transient error, a repository that already had commits when you connected it, or a rollback you want to undo. Deploy from git builds the connected repository on demand, and can take a ref for that one deploy without re-pointing the branch push-to-deploy watches.

The editor goes read-only

Once a repository is connected, the console will not offer to edit the function's files. The workspace is replaced by every push, so an edit made in the browser would be destroyed later by something you would not connect to your edit.