部署间隔超14天，如何保留GitHub自托管运行器？

针对你开发频次低、内网部署的场景，有几个实用方案可以避免每次部署都重新配置自托管运行器：

1. 配置定时心跳任务 #

用内网服务器的定时任务工具，定期触发运行器与GitHub Actions的连接，无需执行完整工作流，只要维持在线状态即可：

• Linux环境：用cron每天执行一次简单脚本，比如进入运行器目录执行轻量连接检查命令（例如cd /opt/github-runner && ./run.sh --check，具体参数可参考运行器本地帮助文档），确保每14天内至少有一次有效连接。
• Windows环境：用「任务计划程序」创建每日任务，运行PowerShell脚本调用运行器的连接检测逻辑。

2. 保持运行器长期在线 #

不要在部署完成后关闭运行器进程，让它长期处于空闲运行状态。如果担心资源占用，可以给运行器配置空闲时的低资源模式（比如暂停非必要后台进程），只保留与GitHub的心跳通信。这种方式最直接，只要运行器进程不终止，就会定期向GitHub发送状态，不会触发14天移除机制。

3. 制作预配置的运行器镜像/模板 #

如果必须关闭运行器以节省资源，提前将配置完成的运行器环境打包成镜像或模板：

• 比如制作Docker镜像，将运行器的注册信息、依赖工具、环境变量都预配置好；或者创建VMware/OpenStack虚拟机模板。下次需要部署时，直接启动镜像/模板实例，几分钟内就能完成运行器的启动与接入，无需重新走注册配置流程。

4. 用GitHub App注册运行器（优化方案） #

相比个人访问令牌注册，使用GitHub App注册自托管运行器能提升连接稳定性与权限管理能力，一定程度上减少因令牌失效、连接中断导致的运行器被移除问题。核心还是要配合上述心跳或长期在线方案，确保定期通信。

注意事项 #

• 确保内网防火墙已放行GitHub Actions相关的域名与端口（如api.github.com、actions.githubusercontent.com），避免运行器无法正常通信。
• 定期检查运行器状态，可在GitHub仓库的「Settings → Actions → Runners」页面查看，避免因脚本故障、网络波动导致连接中断超过14天。

内容的提问来源于stack exchange，提问作者gabriel