自托管GitHub Actions Runner能否部署应用至自身所在Ubuntu虚拟机？是否推荐？

一、方案完全可行 #

这种部署方式是完全可行的——自托管Runner本身就运行在目标Ubuntu虚拟机上，你可以直接在GitHub Actions工作流中添加部署步骤，无需额外的远程连接操作就能完成应用部署。

比如你可以在Workflow文件里编写类似这样的部署逻辑：

name: 部署应用到自托管Runner
on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: self-hosted # 指定使用自托管Runner
    steps:
      - name: 拉取最新代码
        uses: actions/checkout@v4
      
      - name: 停止现有服务
        run: sudo systemctl stop my-app.service
      
      - name: 安装项目依赖
        run: npm install # 根据你的应用技术栈调整，比如pip install、composer install等
      
      - name: 构建应用
        run: npm run build
      
      - name: 启动新服务
        run: sudo systemctl start my-app.service

只要你的自托管Runner拥有足够的系统权限（比如执行systemctl命令、读写应用目录的权限），就能顺利完成整个部署流程。

二、是否建议实施？分场景判断 #

适合的场景（建议采用） #

• 个人项目、小型测试环境：资源有限，不需要复杂架构，这种方案能快速搭建CI/CD流程，节省额外的服务器资源。
• 临时验证环境：快速搭建用于测试代码变更的环境，用完可随时销毁Runner，成本低且灵活。

不适合的场景（不建议采用） #

• 生产环境：
  • 资源冲突：Runner和应用共享虚拟机资源，当Runner执行构建、测试等耗资源任务时，会拖慢应用运行；反过来应用高负载时也会影响CI/CD流程的执行效率。
  • 安全风险：自托管Runner拥有仓库的读写权限，若应用被入侵，攻击者可能利用Runner权限篡改仓库代码；同时Runner的系统权限过高的话，也可能被恶意Workflow利用来控制整个虚拟机。
  • 缺乏隔离性：部署失败（比如配置错误、依赖冲突）可能导致虚拟机环境混乱，甚至影响Runner本身的正常运行，后续所有CI/CD任务都会受牵连。
  • 扩展性差：后续若要扩容应用，只能升级虚拟机配置，无法通过添加多个Runner或应用实例实现横向扩展。

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