GitHub integration
Connect your GitHub repositories to the infrastructure behind them
InfraNest already watches your domains, DNS, servers, certificates and uptime. Install the GitHub app and the two start talking: an incident opens an issue for the team that fixes it, a deployment is checked the moment it lands, and an expiring certificate becomes work with an owner instead of a surprise.
On Pro and up · 14-day Pro trial, no credit card · You pick the repositories
- Incidents become GitHub issues, and close themselves
- Every deployment checked, the commit marked green or red
- Expiring certificates and domains filed as issues
- Releases announced on your status page
When this happens
Certificate expiring
A certificate is approaching expiry.
Runs at 09:00 · Europe/Amsterdam · it’s 15:49 there now
Next runs:Sat 19 Sept, 09:00Sun 20 Sept, 09:00Mon 21 Sept, 09:00
This automation only runs when you click “Run now”.
Only if — optional filters
MatchAllAnyNoneof these conditions
Tip: a value can reference another field or the time using a placeholder.
Do this — actions run in order, stop at the first failure
In plain English
When Certificate expiring if Days left less or equal 14, then Create GitHub issue.
An incident opens a GitHub issue, and closes it when it is over
When a monitor goes down, the people who will fix it should not have to hear about it in a chat thread and then copy it into their tracker. InfraNest opens the issue in the repository of the team that owns the service, with the title, labels and assignees you set. When the monitor recovers and the incident resolves, a second rule finds that same issue and closes it, so the tracker never fills up with outages that ended hours ago.
- Issue opened in the repository you choose, the moment the incident opens
- Closed again automatically when the incident resolves
- Labels and assignees set by the rule, so it lands with the right people straight away
- Built on uptime monitoring across every provider you use
Two ready-made rules, used together.
Know a deployment works, not just that it finished
A green pipeline says the deploy ran. It does not say the site came back up. When GitHub reports a successful deployment, InfraNest checks the environment straight away with the monitor that watches it, and sets the commit status to success or failure from what it actually saw. The check is a one-off: it does not count towards the monitor's uptime and never opens an incident. The same signal can purge the Cloudflare cache or post the release on your status page.
- The environment checked the moment GitHub reports the deployment
- Commit marked green or red from the real result, under its own status name
- Optional: purge the Cloudflare cache after every deploy
- Optional: announce the deployment on your status page
If the check fails, the commit is marked as failed instead.
See every deploy next to the monitors it affects
When something slows down or goes down right after a release, you should not have to compare timestamps between two tabs to notice. Link a repository to the monitors, servers or tags it affects, and every deploy GitHub reports appears as a marker on their response-time and server charts, with the commit, the environment and who deployed it. When an incident opens within the hour after a deploy, the incident says so at the top of its timeline, with a link to the deploy. A deploy only adds this information: it never changes a status, the uptime or an incident.
- A marker on the chart for every deploy, failed ones in a different colour
- "Deployed 7c1e4a9 to production 12 minutes before this incident", on the incident itself
- Link a repository to a monitor, a server or a whole tag
- Works with any deploy job that uses a GitHub environment
Deployed 7c1e4a9 to production
northwind-cloud/api · github-actions[bot]
Sep 18, 2026, 5:15 AM
Click the marker to open the deploy.
Deploys shown from northwind-cloud/api (production).Manage
Expiring certificates and domains become work with an owner
An email that a certificate expires in fourteen days is easy to read and easier to forget. Filed as an issue, it is tracked like the rest of the team's work, shows up in the same board and has someone assigned. InfraNest opens one two weeks before a certificate expires and a month before a domain does, at most once a day, across every registrar and certificate source you have connected. A rule can also start a GitHub Actions workflow instead, if your renewal is already scripted.
- An issue two weeks before a certificate expires, a month before a domain does
- At most once a day, so the tracker does not fill with duplicates
- Or run a GitHub Actions workflow that does the renewal for you
- Expiry dates from every registrar and certificate source you connect
Start from a ready-made rule, or build your own
Every rule on this page is a ready-made automation: pick it, choose the repository, and it runs. When you want something else, the builder offers GitHub events as triggers (pushes, pull requests and reviews, issues and comments, workflow runs, checks, deployments and releases) and GitHub actions as steps: open, comment on, label, assign or close issues, request reviews, merge pull requests, run, re-run or cancel workflows, create deployments and releases, and set commit statuses. Every rule reads back in plain English before you switch it on.
- Ten ready-made rules that connect GitHub to the rest of your setup
- GitHub events as triggers, GitHub actions as steps
- Combine them with monitors, certificates, domains, DNS and status pages
- Nothing runs until you switch the rule on — see how rules are built
Start from a ready-made recipe — filter by category or trigger, or search. One click pre-fills the builder; tailor it before saving.
Expiring domain → approve, then auto-renew
v2Domain expiring → Require approval → Set auto-renew → Send notification
Monitor down → wait, then escalate
v2Monitor alert → Send notification → Wait → Send notification
Ask another system, then act on the answer
v2Domain expiring → Call webhook → If / branch → Send notification → Send notification
Deployment succeeded → check it is up → set commit status
v2GitHub deployment status → Check a monitor now → If / branch → Set commit status → Set commit status
Certificate expiring → run a GitHub workflow
v2Certificate expiring → Run GitHub workflow
Monitor down → route by tag
v2Monitor alert → If / branch → Send notification → Send notification
New domain onboarding
Domain added → Create DNS zone → Apply DNS template → Start monitoring
Auto-renew expiring domains
Domain expiring → Set auto-renew → Send notification
GitHub workflow failed → open an issue & alert
GitHub workflow run → Create GitHub issue → Send notification
Incident opened → announce on status page
Incident opened → Post status-page announcement → Send notification
Monitor down → reboot the server
Monitor alert → Reboot server → Send notification
New server → enable backups & protection
Server added → Enable backups → Enable delete protection
Weak certificate → webhook
Weak certificate → Call webhook → Send notification
Certificate expiring → open a GitHub issue
Certificate expiring → Create GitHub issue
Certificate expiry heads-up
Certificate expiring → Send notification
Deployment succeeded → purge Cloudflare cache
GitHub deployment status → Purge Cloudflare cache
DNS record changed → alert
DNS record changed (in-app) → Send notification
Domain expiring → open a GitHub issue
Domain expiring → Create GitHub issue
Send domain events to my system
Domain added → Call webhook
Send everything to my system
Domain added → Call webhook
Deployment succeeded → announce on status page
GitHub deployment status → Post status-page announcement
Release published → announce on status page
GitHub release → Post status-page announcement
Incident opened → Cloudflare Under Attack
Incident opened → Set Cloudflare security level
Incident opened → open a GitHub issue
Incident opened → Create GitHub issue
Incident resolved → close its GitHub issue
Incident resolved → Close GitHub issue
Incident opened → log to a webhook / Sheet
Incident opened → Call webhook
Let another tool trigger an automation
Incoming webhook → Send notification
Maintenance started → status announcement
Maintenance started → Post status-page announcement
Tell my own system when a monitor fails
Monitor alert → Call webhook
Production monitor down → page on-call
Monitor alert → Send notification
Watched domain available → notify
Watched domain available → Send notification
Weekly expiry review reminder
Scheduled → Send notification
Showing 32 of 32 recipes
Connect GitHub to your own infrastructure
Install the app, create your account in the same step (it starts with 14 days of Pro), and switch on the first rule in a minute.
Connect GitHub in about two minutes
Install the InfraNest Automations app on your account or organisation and choose the repositories it may see. No personal tokens to create or rotate. Not an owner of the organisation? Install anyway: GitHub asks the owners, and the connection appears once they approve.
- 1
Open the GitHub integration
Go to Integrations and open GitHub.
- 2
Start automatic setup
Select Connect, then Set up automatically to install the InfraNest app on GitHub.
- 3
Pick your repositories
In the GitHub window, choose the account or organisation, then select All repositories or just the ones you want InfraNest to see.
- 4
Confirm the connection
You're returned to InfraNest and the connection appears under Accounts. Prefer a token instead? Choose Use a token and paste a personal access token with repo access.
That’s it — GitHub is connected.
Full setup guideSet up with AI
I want to connect GitHub to InfraNest (infranest.io), which manages domains, DNS, servers, certificates and uptime monitoring across providers, using its GitHub App "InfraNest Automations". Explain what installing a GitHub App on my account or organisation means: what it can see, how choosing "Only select repositories" limits it, and where I can change or remove that later. If I am a member but not an owner of the organisation, explain what happens when I install it and what the owner will see. Then tell me how to check afterwards which repositories the app can access.
Often connected together
Questions about the GitHub integration
#What can InfraNest see and do once it's connected?
InfraNest can watch activity in the repositories you selected — pushes, pull requests, issues, workflow runs, deployments, releases and checks — and take actions back on GitHub as part of an automation, such as merging a pull request, triggering a workflow or opening an issue. You choose which repositories are included when you connect, and can adjust that later on GitHub.
#Should I use the automatic setup or a token?
The automatic setup, which installs the InfraNest app, is recommended — it scopes access to only the repositories you pick and needs no token to rotate. Use a token instead if you can't install an app, for example on a self-hosted GitHub instance.
#What happens if I revoke the token or uninstall the app?
If you disconnect GitHub from the Integrations hub, InfraNest uninstalls the app and loses access; if the same installation is shared with another workspace, that one is left in place. If a personal access token is revoked or expires, automations that rely on the GitHub connection will stop working until it's reconnected.
#Can I change which repositories InfraNest has access to later?
Yes. Open the InfraNest app on GitHub under your account or organisation's Settings → GitHub Apps → InfraNest and adjust the selected repositories at any time.
#Can I connect both my personal account and my organisation?
Yes, each is set up separately and appears as its own connection. Note that team-based actions, like requesting a review from a team, only work through an organisation connection.
Let your repositories hear what your infrastructure is doing
Install the GitHub app and create your account in one go. It starts with 14 days of Pro, no credit card, and you pick the repositories.
Free plan · No credit card required · Set up in minutes