Connect GitLab to Voroa and deploy on every push
Connect your GitLab account to Voroa, deploy a GitLab project, ship automatically on every push, and understand exactly what access Voroa asks for and why.
Deploying from GitLab is not available on Voroa yet. This page describes how it will work when it is, so you can see whether it fits before it lands. Today, deploying from a repository means GitHub.
Connecting GitLab will let Voroa do two things for you: read a project so it can clone and build it, and hear about a push so it can start a deploy without you asking. It works the same way as connecting GitHub, and you will be able to use both at once.
Connect your account
- In Voroa, open New and start creating a service, or use Connect GitLab on the dashboard.
- Select Connect GitLab. You are taken to GitLab to authorise Voroa.
- Review what is being asked for and confirm. GitLab sends you back to Voroa, and your projects appear in the repository picker.
Each person connects their own GitLab account. If you work with teammates in a Voroa workspace, a teammate cannot deploy through your connection — they connect theirs. This is deliberate: it keeps every deploy traceable to the account that actually has access to the code.
Which projects you can deploy
The picker lists projects where you have Maintainer access or above.
That is not an arbitrary cut-off. Voroa adds a push webhook to the project so a git push can start a
deploy, and GitLab only allows that at Maintainer level. Listing a project you cannot add a webhook to
would offer you something that could never auto-deploy.
If a project you expect is missing, check your role on it in GitLab under Project information → Members.
What Voroa does with the access
- Clones your project at build time, using a short-lived token that is refreshed automatically.
- Adds one push webhook to each project you deploy, so a push starts a build.
- Nothing else. Voroa does not write to your code, open merge requests, or change your project settings.
Your access token and its refresh token are stored encrypted, and there is no screen anywhere in Voroa that can display them — not for you, and not for our support team.
Deploy on every push
Once a project is connected and a service is created from it, pushing to the branch that service tracks starts a deploy automatically. This is the same auto-deploy behaviour as GitHub, including build filters and the deploy history — see how to enable auto-deploy on every push.
To stop automatic deploys for one service without disconnecting anything, turn Auto-deploy off in that service’s settings.
If Voroa loses access
If you remove Voroa’s authorisation in GitLab, or the access expires there, Voroa marks the connection
as needing attention and emails you. Deploys from a git push stop until you reconnect.
Nothing is deleted when this happens. Your services keep running the version they last deployed, and reconnecting takes a few seconds — you do not set your services up again.
Disconnect GitLab
Disconnecting is done from GitLab, under Settings → Applications → Authorized applications. Find Voroa and revoke it.
Voroa stops receiving pushes from that account straight away, so no further deploys are triggered. Your existing services keep running on the version they last deployed; nothing is deleted.
What is not supported
Git submodules are not fetched. This applies to every provider on Voroa, not just GitLab: the build clones your repository alone, so a project whose build depends on submodule contents will fail to find them. Vendor the code, publish it as a package, or fetch it in a build step instead.
Self-managed GitLab instances are not supported — Voroa connects to gitlab.com. Bitbucket is not supported.