If your GitLab instance is not accessible from the public internet, configure a GitLab CI/CD pipeline that pushes code to Upsun and manages environments via the Upsun API. This method provides full deployment control while keeping your GitLab instance isolated.
1. Generate a token
To integrate your Upsun project with an existing GitLab repository, generate a project access token. Ensure the token has the following scopes:apito access your APIread_repositoryto read the repository
To create a project access token, you need to have a sufficient GitLab license tier.
If you don’t see Access Tokens under Settings, upgrade your GitLab tier.
Alternatively, you can create a personal access token,
but that’s attached to a specific user rather than the project as a whole
and grants more permissions.
2. Enable the integration
To enable the integration, use either the CLI or the Console.- Using the CLI
- In the Console
Run the following command:
PROJECT_IDis the ID of your Upsun project.PROJECT/SUBPROJECTis the name of your repository in GitLab.GITLAB_ACCESS_TOKENis the token you generated.GITLAB_URLis the base URL for your GitLab server if you self-host. If you use the publichttps://gitlab.com, omit the--base-urlflag when running the command.
https://gitlab.com/platformsh/platformsh-docs,
the command is similar to the following:| CLI flag | Default | Description |
|---|---|---|
fetch-branches | true | Whether to mirror and update branches on Upsun and create inactive environments from them. When enabled, merging on an Upsun environment isn’t possible. That is, merging environments must be done on the source repository rather than on the Upsun project. See note below for details related to this flag and synchronizing code from a parent environment. |
prune-branches | true | Whether to delete branches from Upsun that don’t exist in the GitLab repository. When enabled, branching (creating environments) must be done on the source repository rather than on the Upsun project. Branches created on Upsun that are not on the source repository will not persist and will be quickly pruned. Automatically disabled when fetching branches is disabled. |
build-merge-requests | true | Whether to track all merge requests and create active environments from them, which builds the merge request. |
build-wip-merge-requests | true | Whether to also track and build draft merge requests. Automatically disabled when merge requests aren’t built. |
merge-requests-clone-parent-data | true | Whether to clone data from the parent environment when creating a merge request environment. |
resources-init | false | To specify a resource initialization strategy for new containers. Once set, the strategy applies to all the deployments you launch through your source integration. See more information on available resource initialization strategies. |
fetch-branches and prune-branches options.
Source of truth
Sync, fetch, and prune
Optional: use a GitLab CI/CD pipeline
If your GitLab instance is not accessible from the internet (e.g. air-gapped or behind a firewall), the GitLab integration process outlined above, based on incoming webhooks, might not be the best option to use. Instead, set up a push-based GitLab CI/CD pipeline that pushes code to Upsun and manages environments using the Upsun API. This setup allows you to:- Deploy to production on
mainbranch updates - Create preview environments for Merge Requests
- Clean up environments when branches or MRs are removed
- Keep your GitLab instance fully private