How to Integrate Replit with GitLab

GitLab uses Personal Access Tokens (PATs) for API and HTTPS Git authentication — this is how Replit will authenticate when pushing and pulling to your GitLab repos. Log in to GitLab at gitlab.com. Click your avatar in the top-left corner, then select 'Edit profile.' In the left sidebar, click 'Access Tokens.' Click 'Add new token.' Give it a descriptive name like 'Replit Access' so you can identify it later. Set an expiry date — GitLab now requires an expiry for all tokens. Choose one year for long-lived projects or a shorter period if you prefer to rotate credentials frequently. Under 'Select scopes,' check read_repository and write_repository (these are the minimum needed for pushing and pulling code). You may also want api scope if you plan to use GitLab's API from Replit for automation tasks. Click 'Create personal access token.' The token value appears once — copy it immediately and keep it somewhere safe temporarily. You will paste it into Replit Secrets in the next step. Note that once you navigate away from this page, GitLab will never show you the token value again.

With your GitLab PAT in hand, store it securely in Replit Secrets so it can be used for authentication. Click the lock icon in the Replit left sidebar to open the Secrets panel. Click 'New Secret.' For the key name, enter GITLAB_TOKEN. For the value, paste your GitLab Personal Access Token. Click 'Add Secret.' The token is now stored with AES-256 encryption and is accessible as process.env.GITLAB_TOKEN or os.environ['GITLAB_TOKEN'] in your code. For Git operations specifically, you will use this token as part of the remote URL rather than in code. The authenticated remote URL format for GitLab is: https://oauth2:{token}@gitlab.com/{username}/{repo}.git. When you configure the Git remote in Replit's Git panel, use this format, substituting your actual token value, GitLab username, and repository name. This means the token is embedded in the remote URL — make sure you are using Replit Secrets (not the .replit file or any tracked file) for any references to your token.

There are two directions you can connect Replit with GitLab: pushing an existing Replit project to a new GitLab repo, or importing an existing GitLab repo into Replit. For pushing a Replit project to GitLab: first create a new empty repository on GitLab (go to gitlab.com, click the + icon > New project > Create blank project, give it a name, set visibility, and click Create project). Copy the HTTPS clone URL from the GitLab project page. In Replit, open the Git panel from the left sidebar (the branch icon). If the project has no Git history, click 'Initialize Git repository' or 'Connect to Git.' In the remote configuration field, enter the authenticated URL: https://oauth2:YOUR_TOKEN@gitlab.com/username/repo-name.git (replace YOUR_TOKEN with your actual PAT value). For importing a GitLab repo into Replit: go to replit.com, click Create Repl, select 'Import from GitHub' (Replit uses this for all Git providers), and paste your GitLab repo URL in the format https://gitlab.com/username/repo-name. If the repo is private, you will need to provide the token when prompted. Replit clones the repository and creates a new Repl with all the files.

1# In Replit Shell — configure Git identity and remote
2git config user.email "your@email.com"
3git config user.name "Your Name"
4
5# Set authenticated remote URL
6git remote add origin https://oauth2:${GITLAB_TOKEN}@gitlab.com/username/repo-name.git
7
8# Or update existing remote
9git remote set-url origin https://oauth2:${GITLAB_TOKEN}@gitlab.com/username/repo-name.git
10
11# Verify remote is configured
12git remote -v

With the remote configured, your standard development workflow is: edit files in Replit, commit changes via the Git panel, and push to GitLab. Open the Git panel in the Replit sidebar (the branch icon). You will see a list of changed files. Hover over individual files and click the + button to stage them, or click 'Stage All' to stage everything. Type a commit message describing your changes — be specific enough that the message is useful in the Git history (e.g., 'Add user authentication with JWT tokens' rather than 'update code'). Click 'Commit.' Once committed, click 'Push' to push your changes to GitLab. Replit uses the authenticated remote URL you configured to push the commit. After the push completes, go to your GitLab repository page and refresh — you will see your new commit in the repository's commit history. If you are working with branches, you can create and switch branches in the Git panel before committing. Each branch in Replit corresponds to a branch in GitLab, allowing you to manage feature branches, pull changes from others, and keep main/master protected.

1# Alternative: commit and push via Replit Shell
2git add -A
3git commit -m "your commit message here"
4git push origin main
5
6# Push to a feature branch
7git checkout -b feature/new-feature
8git add -A
9git commit -m "Add new feature"
10git push origin feature/new-feature

One of GitLab's most powerful features is automated CI/CD pipelines that run every time code is pushed to a branch. Adding a .gitlab-ci.yml file to your Replit project enables this. Create a new file called .gitlab-ci.yml in your project root. This file defines pipeline stages (like test, build, deploy), the Docker image to run each stage in, and the commands to execute. When you push this file to GitLab, the pipeline runs automatically on every subsequent push. For a Node.js app, the basic pipeline installs dependencies and runs your test suite. For a Python app, it installs requirements and runs pytest. More advanced pipelines can build Docker images, push to a container registry, and deploy to a server or Kubernetes cluster using GitLab's built-in deployment environments. Pipeline secrets (API keys, deployment credentials) are stored in GitLab's CI/CD Variables (Settings > CI/CD > Variables), not in Replit Secrets — those are used for the Replit runtime, not for the GitLab pipeline runner.

1# .gitlab-ci.yml — Node.js example
2image: node:20-alpine
3
4stages:
5  - test
6  - deploy
7
8variables:
9  NODE_ENV: test
10
11cache:
12  paths:
13    - node_modules/
14
15test:
16  stage: test
17  script:
18    - npm ci
19    - npm test
20  only:
21    - merge_requests
22    - main
23    - develop
24
25deploy_staging:
26  stage: deploy
27  script:
28    - echo "Deploying to staging..."
29    # Add your deployment commands here
30    # e.g., kubectl apply or ssh deployment
31  environment:
32    name: staging
33  only:
34    - main
35  needs:
36    - test