I build n8n workflows that turn GitHub events into actual work. This is the setup I keep using: a few reliable nodes, sensible checks, and no needless API calls.
Run n8n in Docker or use the hosted version. I run it with Docker Compose, expose the webhook port, and keep a persistent database. If you expose webhooks publicly, give n8n HTTPS. For GitHub, create a personal access token with repo and workflow scopes, then store it in n8n credentials rather than pasting it into HTTP nodes. Use the built-in GitHub node where it fits; it saves faff with headers and rate limits. For incoming events, use an n8n webhook node and accept GitHub’s JSON payload. If GitHub needs to call n8n directly, add the webhook URL in repository settings or use repository_dispatch from a GitHub Action to send events to n8n.
Keep workflows narrow and easy to inspect. One workflow should do one job, such as comment on PR with test results or start deploy when PR is labelled deploy. Use small nodes: webhook trigger, JSON parse, GitHub node, error handling. Put explicit checks in IF nodes rather than hiding logic in Function nodes. Log key events to a dedicated channel, a file, or a monitoring webhook. GitHub write-heavy workflows hit rate limits quickly, so batch when you can and skip pointless API calls. Keep credentials out of workflow JSON. Use environment variables for base URLs and tokens in Docker Compose so you can change endpoints without editing the workflow. Export stable workflows to JSON and commit them to a repo as part of your change process.
Example A is PR comments with a CI summary. CI runs in GitHub Actions. After tests finish, the job posts a small JSON payload to an n8n webhook with curl in the final action step. n8n receives the payload, validates the signature, formats a short summary, and uses the GitHub node to post a comment on the PR. The CI logic stays in Actions. The formatting and posting live in n8n, which is easier to change.
Example B is a label-triggered deploy. A GitHub webhook for label events sends the payload to n8n. The workflow checks the label name, verifies the PR mergeability, then posts a deploy request to the deployment API. If the deployment fails, n8n creates an issue and notifies the on-call channel. Both examples use the same pattern: validate input, make the minimum number of API calls, and record the outcome.
Testing and maintenance are straightforward, which is usually where people still manage to make a mess of it. Test a webhook locally with ngrok or by using repository_dispatch and a temporary token. Use n8n’s Execution list to replay failed runs. Add a final node that pushes a compact execution summary to a log sink so you can query past runs without opening n8n. Rotate GitHub tokens on a schedule and keep them narrowly scoped. When a workflow settles, export the JSON and push it to a repo with a clear commit message. That makes rollbacks easier and keeps the workflow definition in one place.
Keep triggers narrow, credentials locked down, logs visible, and workflow JSON under version control. If a workflow starts getting awkward, split it into smaller workflows that call each other by webhook.
