How to Integrate Bolt.new with Jenkins

Bolt.new builds everything inside a browser-based WebContainer, but Jenkins needs access to your code through a Git repository. The cleanest export path is Bolt's built-in GitHub integration. In your Bolt project, open the menu and look for the GitHub connect option. If your project is not already linked, Bolt will walk you through OAuth authorization and repository creation. Once connected, every change you make in Bolt gets pushed to the main branch automatically. If you prefer a one-time export, Bolt also offers a ZIP download. Download the ZIP, extract it locally, run git init inside the project folder, and push to your GitHub repository using standard git commands. The exported project contains a standard package.json, a vite.config.ts (or next.config.js for Next.js projects), and all your source files — no Bolt-specific lock-in. Verify the export worked correctly by opening the GitHub repository and confirming you see package.json at the root. Jenkins will fail silently if it clones a repository where package.json is nested in a subfolder rather than at the root, so this check matters. At this stage you are not touching Jenkins at all — you are just establishing the source of truth that Jenkins will pull from on every build.

A Jenkinsfile is a text file that lives in the root of your repository and defines your CI/CD pipeline as code. Jenkins reads this file automatically when it discovers or processes the repository. Create a file named Jenkinsfile (no extension) at the project root and paste in the pipeline definition below. The pipeline has four stages: Checkout (Jenkins clones your repo), Install (runs npm ci for a clean install), Build (runs npm run build to produce the dist folder), and Deploy (ships the output to your target platform). The NodeJS tool reference in the agent section tells Jenkins to use the Node.js installation you configured in the global tools settings — change 'Node 20' to match the exact name you gave that installation. For Vite projects, the build output lands in dist/. For Next.js projects it lands in .next/ (or out/ if you use static export). Adjust the deploy stage path to match your framework. The pipeline also references credentials by ID — you will create those credentials in the Jenkins UI in the next step, so use the IDs shown here as placeholders and update them to match what you create.

1// Jenkinsfile
2pipeline {
3  agent any
4  tools {
5    nodejs 'Node 20'
6  }
7  environment {
8    // Reference credentials stored in Jenkins Credentials Manager
9    NETLIFY_AUTH_TOKEN = credentials('netlify-auth-token')
10    NETLIFY_SITE_ID    = credentials('netlify-site-id')
11  }
12  stages {
13    stage('Checkout') {
14      steps {
15        checkout scm
16      }
17    }
18    stage('Install') {
19      steps {
20        sh 'npm ci'
21      }
22    }
23    stage('Build') {
24      steps {
25        sh 'npm run build'
26      }
27    }
28    stage('Deploy to Netlify') {
29      steps {
30        sh 'npm install -g netlify-cli'
31        sh 'netlify deploy --prod --dir=dist --auth=$NETLIFY_AUTH_TOKEN --site=$NETLIFY_SITE_ID'
32      }
33    }
34  }
35  post {
36    failure {
37      echo 'Build or deploy failed. Check the console output above.'
38    }
39    success {
40      echo 'Deployed successfully.'
41    }
42  }
43}

Jenkins stores sensitive values like API tokens and deploy keys in its Credentials Manager, keeping them out of your Jenkinsfile and out of your repository. Navigate to Manage Jenkins → Credentials → (global) → Add Credentials. For Netlify deployment, create two Secret text credentials: one with the ID netlify-auth-token (value: your Netlify personal access token from app.netlify.com/user/applications) and one with the ID netlify-site-id (value: your site's API ID from Site Settings → General). If you are deploying to Vercel instead, create a single credential with ID vercel-token and update the deploy stage in your Jenkinsfile accordingly. For AWS S3, you will store AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as separate credentials and bind them using the withCredentials block. Now create the pipeline job: from the Jenkins dashboard click New Item, give the job a name (e.g., bolt-app-deploy), select Pipeline, and click OK. In the job configuration, scroll to the Pipeline section and set Definition to Pipeline script from SCM. Set SCM to Git, enter your repository URL, and under Credentials add your GitHub credentials if the repository is private. Set the Script Path to Jenkinsfile and save. Run the job once manually by clicking Build Now to confirm the pipeline works before setting up automatic triggers.

1// For Vercel deployment, replace the Deploy stage with:
2stage('Deploy to Vercel') {
3  environment {
4    VERCEL_TOKEN = credentials('vercel-token')
5  }
6  steps {
7    sh 'npm install -g vercel'
8    sh 'vercel --prod --token=$VERCEL_TOKEN --yes'
9  }
10}
11
12// For AWS S3 deployment:
13stage('Deploy to S3') {
14  environment {
15    AWS_ACCESS_KEY_ID     = credentials('aws-access-key-id')
16    AWS_SECRET_ACCESS_KEY = credentials('aws-secret-access-key')
17  }
18  steps {
19    sh 'aws s3 sync dist/ s3://your-bucket-name --delete'
20    sh 'aws cloudfront create-invalidation --distribution-id YOUR_DIST_ID --paths "/*"'
21  }
22}

Right now Jenkins only builds when you click Build Now manually. To trigger builds automatically every time you push to GitHub (including when Bolt pushes changes to your connected repo), you need to configure a GitHub webhook. In your Jenkins job configuration, scroll to Build Triggers and check GitHub hook trigger for GITScm polling. Save the job. Next, go to your GitHub repository → Settings → Webhooks → Add webhook. Set the Payload URL to http://YOUR_JENKINS_URL/github-webhook/ (note the trailing slash — Jenkins requires it). Set the Content type to application/json. Under Which events would you like to trigger this webhook, choose Just the push event. Save the webhook. GitHub will send a ping event immediately; if the webhook shows a green checkmark the connection is confirmed. From now on every push to the repository — whether from your local machine, from Bolt's GitHub integration, or from a pull request merge — will automatically trigger a Jenkins build. To restrict builds to only the main branch, add a when clause to your pipeline stages: when { branch 'main' }. If your Jenkins server is behind a firewall and not accessible from the public internet, GitHub webhooks cannot reach it. In that case, use the GitHub Checks API with Jenkins's SCM Polling as a fallback: check Poll SCM in Build Triggers and set a schedule like H/5 * * * * to poll every five minutes.

1// Add branch filtering to Jenkinsfile to only deploy from main:
2pipeline {
3  agent any
4  tools {
5    nodejs 'Node 20'
6  }
7  stages {
8    stage('Checkout') {
9      steps { checkout scm }
10    }
11    stage('Install') {
12      when { branch 'main' }
13      steps { sh 'npm ci' }
14    }
15    stage('Build') {
16      when { branch 'main' }
17      steps { sh 'npm run build' }
18    }
19    stage('Deploy') {
20      when { branch 'main' }
21      environment {
22        NETLIFY_AUTH_TOKEN = credentials('netlify-auth-token')
23        NETLIFY_SITE_ID    = credentials('netlify-site-id')
24      }
25      steps {
26        sh 'npm install -g netlify-cli'
27        sh 'netlify deploy --prod --dir=dist --auth=$NETLIFY_AUTH_TOKEN --site=$NETLIFY_SITE_ID'
28      }
29    }
30  }
31}