How to Integrate Bolt.new with GitLab

Bolt.new does not have a native GitLab integration, so the export process is manual. In your Bolt project, click the download or export button (typically in the project menu or settings panel) to download a ZIP file of the entire project. The ZIP contains the complete codebase including package.json, all source files, and configuration files like vite.config.ts or next.config.js. Extract the ZIP to a folder on your computer. Before doing anything else, check the extracted folder for any files that should not be committed: node_modules/ (too large, always reinstalled), .env or .env.local files (contain secrets), and .bolt/ (Bolt editor state). Create or edit the .gitignore file to exclude these. Now initialize a Git repository. Open a terminal in the extracted folder and run: git init, then git add ., then git commit -m 'Initial export from Bolt.new'. This creates the first commit with all your project files. If you want to verify the project builds correctly before pushing, run npm install and npm run build locally — catching build errors before they reach GitLab CI saves debugging time. For future exports from Bolt, you do not need to re-initialize. Simply extract the new ZIP, copy the files into your repository folder (replacing the old ones), check for any accidental .env files, and commit the changes with a descriptive message.

1# Create a comprehensive .gitignore for Bolt-exported projects
2node_modules/
3dist/
4build/
5.next/
6.env
7.env.local
8.env.*.local
9.bolt/
10*.log
11.DS_Store
12Thumbs.db

With your local repository initialized, connect it to your empty GitLab repository. On GitLab, create a new project (gitlab.com/projects/new) — choose a blank project, give it a name, set visibility to Private, and uncheck 'Initialize repository with a README' since you already have commits locally. GitLab will show you the push commands on the empty repository page. Copy the remote URL — it looks like git@gitlab.com:username/project-name.git (SSH) or https://gitlab.com/username/project-name.git (HTTPS). In your terminal, run: git remote add origin https://gitlab.com/yourusername/your-project.git, then git push -u origin main. If you get an authentication error with HTTPS, GitLab requires either a personal access token or SSH key — your GitLab account password alone is not accepted for git push. Generate a personal access token at gitlab.com/-/user_settings/personal_access_tokens with the read_repository and write_repository scopes, and use that token as the password when prompted. For SSH authentication (recommended for ongoing use), add your SSH public key in GitLab at gitlab.com/-/user_settings/ssh_keys and use the git@ remote URL format instead. SSH authentication works without password prompts once configured.

1# Push an existing local repository to GitLab
2# 1. Add the GitLab remote (use your actual repository URL)
3git remote add origin https://gitlab.com/yourusername/your-project-name.git
4
5# 2. Push to GitLab (creates the main branch)
6git push -u origin main
7
8# If your default branch is 'master', use:
9# git push -u origin master
10
11# To verify the remote is set correctly:
12git remote -v
13# Should show: origin https://gitlab.com/yourusername/your-project-name.git (fetch and push)

GitLab CI/CD is configured through a .gitlab-ci.yml file in the repository root. When you push code, GitLab reads this file and runs the pipeline on its shared runners (free minutes included on gitlab.com). The pipeline below has three stages: test (runs the build to catch errors), build (creates the production artifact), and deploy (ships to Netlify). The image keyword specifies the Docker image the CI runner uses — node:20-alpine is a small Node.js 20 image that matches the Node.js version Bolt uses. The cache section stores node_modules between pipeline runs so npm ci runs faster on subsequent builds. The artifacts section saves the dist folder so the deploy stage can access it. For deployment secrets (Netlify auth token, site ID), use GitLab CI/CD variables rather than hardcoding them in .gitlab-ci.yml. Go to your GitLab project → Settings → CI/CD → Variables → Add variable. Create NETLIFY_AUTH_TOKEN and NETLIFY_SITE_ID as masked, protected variables. They will be automatically available as environment variables in your pipeline. For Vercel deployment, replace the deploy stage with a vercel --prod command using a VERCEL_TOKEN variable. For Cloudflare Pages, use the wrangler pages deploy command with a CF_API_TOKEN variable. The pipeline structure stays the same — only the deploy stage changes.

1# .gitlab-ci.yml — CI/CD pipeline for a Bolt-exported Vite or Next.js app
2image: node:20-alpine
3
4stages:
5  - build
6  - deploy
7
8cache:
9  key: '$CI_COMMIT_REF_SLUG'
10  paths:
11    - node_modules/
12
13build:
14  stage: build
15  script:
16    - npm ci
17    - npm run build
18  artifacts:
19    paths:
20      - dist/     # Use 'out/' for Next.js static export, '.next/' for SSR
21    expire_in: 1 hour
22  only:
23    - main
24    - merge_requests
25
26deploy_production:
27  stage: deploy
28  script:
29    - npm install -g netlify-cli
30    - netlify deploy --prod --dir=dist --auth=$NETLIFY_AUTH_TOKEN --site=$NETLIFY_SITE_ID
31  environment:
32    name: production
33    url: https://your-site.netlify.app
34  only:
35    - main
36  when: on_success

The initial setup is complete, but you will continue making changes in Bolt over time. Establishing a repeatable export and push workflow prevents the GitLab repository from falling out of sync with what is in Bolt. The simplest ongoing workflow: make changes in Bolt, download the updated ZIP when you are satisfied with a set of changes, extract it to a temporary folder, and copy the changed files into your GitLab repository folder. Run git status to see what changed, review the diff with git diff, commit with a descriptive message, and push to GitLab. The CI pipeline picks it up automatically. An alternative approach: connect Bolt to GitHub (its native integration) and then set up GitLab's repository mirroring feature. In your GitLab project → Settings → Repository → Mirroring repositories, add your GitHub repository as a pull mirror. GitLab will periodically fetch updates from GitHub, keeping both repositories in sync. This means you get Bolt's seamless GitHub sync AND GitLab's CI/CD without manual exports. The mirror update interval is up to 5 minutes on gitlab.com. For teams where multiple developers contribute both through Bolt and through local code changes, use GitLab's merge request workflow: make Bolt changes on a feature branch, push to GitLab, and merge to main after review. This prevents direct pushes to the main branch and gives developers a chance to review AI-generated code before it ships.

1# Ongoing workflow script — export from Bolt, update Git, push to GitLab
2# Run this after downloading and extracting a new Bolt ZIP
3
4# 1. Copy new files into your repository (from extracted ZIP folder)
5# cp -r /path/to/extracted-bolt-zip/. /path/to/your-gitlab-repo/
6
7# 2. Check what changed
8git status
9git diff --stat
10
11# 3. Stage all changes (verify .gitignore is working first)
12git add .
13
14# 4. Commit with a descriptive message
15git commit -m 'Update from Bolt: add user authentication flow'
16
17# 5. Push to GitLab and trigger the CI pipeline
18git push origin main