Why run request files in CI at all
The same files your team runs by hand while debugging make useful automated smoke checks: does the service start, does auth work, do the critical endpoints answer? Because the file is the single source of truth, the check that runs at 3 a.m. is byte-for-byte the request a developer will re-run in their editor at 9 a.m. to investigate. No drift between "the test" and "how we actually call it."
Option 1: ijhttp — the JetBrains CLI
JetBrains ships its HTTP Client as a free standalone CLI, ijhttp — no IDE license required. The ZIP distribution needs a JDK; there's also a Docker image if you'd rather not manage Java in the pipeline. It uses the same parser as the IDE, including http-client.env.json environment files and JavaScript response-handler tests:
ijhttp --env ci --env-file http-client.env.json api/smoke.http
If your requests carry JetBrains-style response tests, ijhttp fails the step when a test fails — which is exactly what CI wants.
Option 2: httpyac — the npm runner
httpyac is an open-source runner installable from npm — the lightest path on runners that already have Node. It executes .http files and supports both dotenv .env files and JetBrains-style environment files:
npx httpyac send api/smoke.http --all --env ci
For teams whose environments are already dotenv files (Karve's model), httpyac is usually the smoother fit.
Adjacent but different: Hurl is a popular CI request runner with its own .hurl format — a good tool, but not the .http ecosystem.
A GitHub Actions example
A minimal smoke-check job: values come from the repository's secret store, get written into an env file in the step, and the committed .http file never contains a real token.
jobs:
api-smoke:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22 }
- name: Write CI environment
run: |
echo "baseUrl=https://staging.example.com" > .env
echo "token=$API_TOKEN" >> .env
env:
API_TOKEN: ${{ secrets.STAGING_API_TOKEN }}
- name: Run smoke requests
run: npx httpyac send api/smoke.http --all
The referenced smoke.http is a perfectly ordinary file — the same one you run locally:
### Health check
GET {{baseUrl}}/health
### Auth works
GET {{baseUrl}}/api/me
Authorization: Bearer {{token}}
Where Karve fits (and doesn't)
Karve is the local half of this loop: a native Windows workspace where the same files get written, organized across repos, debugged against real responses, and kept honest before they ever guard a pipeline. It deliberately has no CLI — CI is served well by the free runners above, and the open format means there's nothing to convert in either direction. Write and debug in Karve, run in CI with ijhttp or httpyac, and the file stays the single source of truth.
Common questions
How do I run .http files in a CI pipeline?
With a CLI runner: JetBrains' free ijhttp (JDK or Docker) or the npm-installable httpyac. Both execute your existing files unchanged.
Can Karve run .http files in CI?
No — Karve is a desktop workspace with no CLI. The same files run in CI through the runners above, because the format is open.
How do secrets work in CI?
Committed files reference {{variables}}; the pipeline writes real values from its secret store into an env file at run time. Same habit as local work — see the environments guide.