Run country-specific checks in GitHub Actions

The smallest useful GitHub Actions integration is a normal run: step that installs Shellroute and executes one command through a country proxy. No custom action or Marketplace package is required.

Example workflow

name: Geo check

on:
  workflow_dispatch:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Install shellroute
        run: npm install -g shellroute

      - name: Check US redirect
        env:
          SHELLROUTE_API_KEY: ${{ secrets.SHELLROUTE_API_KEY }}
        run: shellroute run US -- curl -sSI https://store.google.com/ | grep -i '^location:'

      - name: Check DE redirect
        env:
          SHELLROUTE_API_KEY: ${{ secrets.SHELLROUTE_API_KEY }}
        run: shellroute run DE -- curl -sSI https://store.google.com/ | grep -i '^location:'

Get the key with shellroute reveal-key from any machine where you have logged in, then store it in GitHub Actions secrets. Do not commit it to the repository.

What this pattern gives you

• — npm install -g shellroute installs the CLI on ubuntu-latest, where Node.js is already available.
• — SHELLROUTE_API_KEY enables non-interactive authentication.
• — Each shellroute run step starts its own session and country route.
• — The child command's exit code is propagated, so a failed check fails the workflow step.

The example uses redirect headers only to keep the check small. Replace the command with the test or request that matches your own geo-sensitive behavior.

Operational considerations

• — Each routed step starts a fresh session and adds startup overhead.
• — Each routed run consumes proxy traffic or credit, so avoid running broad country matrices on every push unless that usage is intentional.
• — Sessions are not cached between steps. Each invocation starts a fresh route.
• — This example uses npm; do not assume Homebrew is present on ubuntu-latest.

For low-frequency checks, workflow_dispatch or a scheduled workflow is usually easier to control than running the job on every push.

Do you need a custom GitHub Action?

Not for this pattern. A normal run: block already exposes the full shellroute run <country> -- <command> interface.

A reusable workflow or composite action may be useful later if several repositories need the same setup, but there is no need to add that abstraction before the repetition exists.