An experiment to use GitHub Actions as a control plane for a PaaS(towlion.github.io)
19 pointsby baijum10 hours ago8 comments
  • SOLAR_FIELDS8 hours ago
    Putting the obvious facetiousness of this whole endeavor aside, doing something like this would mean that your reliability record is exactly as good as GHA
    • nikisweeting6 hours ago
      It's ok, I hear they recently hit 5 9s of reliablility again! (89.9999%)
    • vasco4 hours ago
      You misunderstand, this only deploys, has nothing to do with runtime.
      • bravetraveleran hour ago
        You misunderstand, (continued) runtime is dependent on the ability to deploy. For instance: a vulnerability is realized or a customer needs something (availability, feature, who knows), you'll appreciate handles under your control. Service can easily degrade, without.

        I've done this same thing, GHA as a control plane. It was for people who could wait; the actual operators regularly skipped the middleman. Preference or necessity, take your pick.

        • vasco7 minutes ago
          Runtime is separate from deployment. An incident in your deployment infra doesn't affect production. The fact that you may have to deploy to change what's live is what defines it as an incident, but it's still a different thing from a production incident.
  • klabetronan hour ago
    Minor feedback: struggled to read this with the too-clever but distracting horizontal line scrolling down the page. Also the headers look squashed.
  • xyzzy_plugh8 hours ago
    This doesn't seem particularly interesting. Spinning up environments via PRs is nothing new. This just has a fresh coat of paint. Is it neat to pack everything up into a single unit like this? I don't know, maybe.

    The most concerning thing here is that you absolutely should not use GitHub fucking Actions as your control plane. Have you ever debugged actions? It's terrible. Old runs magically disappear. The queue sometimes decides to go for a lunch break. Not to mention GitHub's uptime is atrocious.

    I'm sorry (not sorry) but I can't take this seriously at all.

  • baijum6 hours ago
    Based on the feedback, I have created a page: https://towlion.github.io/platform/scope/
  • looksjjhg5 hours ago
    Hmm interesting, I wonder how much fiddling to make this work on an actual machine at home running fedora server
  • stego-tech7 hours ago
    I dig the core concept, because it's what I'm replicating in my own homelab at present sans GHA and with a brief flirtation with Podman over Docker.

    Thing is, like others have pointed out, relying solely on GHA is just not a great idea. If you're doing your own self-hosted runners you can effectively debug, then sure, that's not a bad idea necessarily, but using the GitHub runners?

    Nope. Sorry, just not something I can trust on the free tier.

    That being said, I do like the core concept (deploying the essentials to a plain-jane Debian instance - bare metal or virtual - and just bootstrapping via compose files and some form of push), and I'd like to see it refined more for homelab users, especially if you can guarantee some degree of security best practices with it (e.g., SELinux compatibility and/or auto-deploy tools like Wazuh).

    I'll poke at it since I gotta blow away my Debian install anyway (went down a rabbit hole on GPU acceleration and Podman that has left it butchered far more than I would've liked to support), just give folks more options than GHA and focus more on essential services.

  • vasco4 hours ago
    I'm not sure what this is for, most people already use GHA without any control plane and deploy just fine.
    • antonkochubey4 hours ago
      Except for when GHA is down, which is (from my own experience) waaaaay more often than our self-hosted GitLab, with it's much better CI system, ever was :)
  • white_dragon884 hours ago
    [dead]