Can Replit be used with CI/CD

Open the Git pane from the Tools dock in your Replit workspace. If this is a new project, initialize a Git repository by clicking Initialize Repository. Then connect to GitHub by clicking Connect to GitHub and authorizing Replit's GitHub app. Select your GitHub organization and choose to create a new repository or connect to an existing one. Once connected, Replit syncs code bidirectionally on the main branch. Every commit you make in Replit pushes to GitHub, and pulls from GitHub update your Repl.

In your Replit workspace, create a .github/workflows directory structure. Inside it, create a file called ci.yml. This workflow runs automatically on every push to the main branch and on pull requests. It sets up the Node.js environment, installs dependencies, runs your linter, and executes your test suite. If any step fails, the workflow marks the commit as failing, preventing untested code from being deployed. You can create this file directly in the Replit file tree or through the GitHub web interface.

1name: CI Pipeline
2
3on:
4  push:
5    branches: [main]
6  pull_request:
7    branches: [main]
8
9jobs:
10  test:
11    runs-on: ubuntu-latest
12    steps:
13      - uses: actions/checkout@v4
14      - uses: actions/setup-node@v4
15        with:
16          node-version: '20'
17          cache: 'npm'
18      - run: npm ci
19      - run: npm run lint
20      - run: npm test

For the CI pipeline to work, your package.json needs test and lint scripts. Open package.json in the Replit editor and add the scripts section. Install a testing framework like vitest (lightweight and fast) and a linter like eslint. Run these locally in the Shell first to verify they work before relying on them in CI. A failing test in CI blocks the pipeline, which is the desired behavior for catching bugs before deployment.

1{
2  "scripts": {
3    "start": "node index.js",
4    "build": "echo 'No build step required'",
5    "test": "vitest run",
6    "lint": "eslint src/"
7  },
8  "devDependencies": {
9    "vitest": "^1.0.0",
10    "eslint": "^8.0.0"
11  }
12}

To enforce CI checks before code reaches your Replit deployment, set up branch protection rules in your GitHub repository. Go to the repository Settings on GitHub, then Branches, and add a rule for the main branch. Enable Require status checks to pass before merging and select your CI workflow as a required check. This ensures that all code must pass tests and linting before it can be merged to main. Since Replit syncs from the main branch, this creates a gate between code changes and your deployed app.

Replit does not expose a deployment API that GitHub Actions can call directly. The most reliable pattern is to use the Replit workspace as the deployment target: when code merges to main on GitHub, Replit automatically pulls the changes. You then redeploy manually from the Replit workspace, or use the auto-deploy behavior if your deployment type supports it. For teams that need fully automated deployment pipelines, this is a known limitation. For enterprise-grade CI/CD needs beyond what Replit natively supports, RapidDev can help architect solutions that bridge Replit with external deployment automation tools.

1name: Notify Deploy Ready
2
3on:
4  push:
5    branches: [main]
6
7jobs:
8  notify:
9    runs-on: ubuntu-latest
10    needs: test
11    if: github.event_name == 'push'
12    steps:
13      - name: Send deployment notification
14        uses: slackapi/slack-github-action@v1.25.0
15        with:
16          channel-id: 'deployments'
17          slack-message: 'CI passed on main. Ready to deploy in Replit.'
18        env:
19          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

Your GitHub Actions workflow runs in a separate environment from Replit, so secrets must be configured in both places. In GitHub, go to repository Settings, then Secrets and variables, then Actions, and add the secrets your tests need (like test API keys or database URLs). In Replit, the same values live in the Secrets panel. For deployment-specific secrets, add them separately in the Replit Deployments pane. Keep a checklist of which secrets exist in which environment to avoid the common problem of tests passing in CI but the app failing in deployment due to missing secrets.