Why the standard GitLab integration won’t work
The standard Upsun GitLab integration relies on a webhook-based architecture:- GitLab sends webhooks - When you push code, create branches, or open Merge Requests, GitLab sends HTTP webhooks to Upsun’s servers
- Upsun pulls your code - Upon receiving the webhook, Upsun attempts to connect back to your GitLab instance to pull the repository
- The connection fails - Since your GitLab instance isn’t accessible from the internet, Upsun can’t reach it to pull the code
The push-based solution
Instead of relying on Upsun pulling from GitLab, you can implement a push-based workflow where your GitLab CI/CD pipeline actively pushes code to Upsun. This approach works because:- Your GitLab runners can reach external services (including Upsun)
- No inbound connections to your GitLab instance are required
- You maintain full control over when and how deployments occur
- Your GitLab instance remains completely isolated from the internet
main production environment when the branch is updated and will create preview environments whenever a new merge request is created.
Prerequisites
Before setting up your pipeline, you’ll need:- A GitLab runner with internet access to reach Upsun
- An Upsun project
- An Upsun API token for environment management
- SSH keys configured on Upsun for Git operations
Setting up authentication
Generate an SSH key pair
Create a dedicated SSH key for your GitLab CI/CD pipeline:
Configure GitLab CI/CD variables
Add these variables to your GitLab project’s CI/CD settings:UPSUN_PROJECT_ID: Your Upsun project ID (e.g.,abcdefgh1234567)UPSUN_API_TOKEN: Your Upsun API token (masked variable)UPSUN_SSH_PRIVATE_KEY: Contents of your private SSH key (It unfortunately can’t be a masked variable due to the key format)UPSUN_GIT_REMOTE: Your Upsun Git remote URLUPSUN_REGION: The Upsun region the project is hosted on (us-3.platform.sh,fr-1.platform.sh, etc.)