Redeploy from GitHub Actions

How it works

Enabling deploy webhooks installs a small agent on your server: a container named mihraops-agent, with its files in /opt/mihraops/agent. Its webhook routes only run actions you configured. Monitoring and email are separate capabilities and stay off until you enable them from Notifications. You can remove the Agent at any time.

Each application gets its own trigger at /hooks/<name>. A request to that address pulls the newest image and redeploys the container.

Create the trigger

1. 01Open the application and create a deploy webhook.
2. 02Choose the authentication mode: a shared token, or an HMAC signature.
3. 03Copy the URL and the secret.
4. 04Store the secret in your repository as an encrypted secret — never in the workflow file.

Token mode

The simplest option. Send the token in the Authorization header:

- name: Trigger MihraOps deploy
  run: |
    curl --fail --silent --show-error \
      -X POST "${{ secrets.MIHRAOPS_WEBHOOK_URL }}" \
      -H "Authorization: Bearer ${{ secrets.MIHRAOPS_WEBHOOK_TOKEN }}"

The token is also accepted in an X-MihraOps-Token header or an X-Gitlab-Token header, which lets GitLab webhooks work without any extra configuration.

Signature mode

The agent verifies an HMAC-SHA256 signature of the request body, in the same format GitHub uses for repository webhooks. If you point a GitHub webhook straight at the trigger URL and paste the secret into GitHub, the X-Hub-Signature-256 header it already sends is verified as-is.

Both modes compare secrets in constant time, and a request that fails verification is answered with 401 and changes nothing.

Skipping the build cache

Add ?withoutcache=true to the trigger URL when a deployment builds from source and you need a clean build.