GitHub - TCB13/uSentry: Identity and Access Management (IAM) and Single Sign-On (SSO) for your homelab in a single file!
github.com
Identity and Access Management (IAM) and Single Sign-On (SSO) for your homelab in a single file! - TCB13/uSentry

uSentry is a lightweight, self-hosted Identity and Access Management (IAM) and Single Sign-On (SSO) solution designed for homelab and small-scale environments.

⚡ A single PHP file. < 400 lines of code. No database. No background processes. No cloud. Just works. ⚡

Most IAM and SSO solutions require databases, certificates and background services baked into a dozen containers. This is all fine but also also overkill for homelabs and impossible for low-power ARM devices. uSentry is different, it isn’t pretty but it sucks less for a lot of use cases.

Enjoy!

  • Vendetta9076@sh.itjust.worksEnglish
    42·
    18 hours ago

    I feel like committing secrets to a config file instead of .env is a terrible idea. Thats being said this is really useful I’m sure.

    • Xanza@lemm.eeEnglish
      1·
      12 hours ago

      The entire point of .env files are to separate secrets from code. Its specifically the usage for which they were created.

        • Xanza@lemm.eeEnglish
          1·
          5 minutes ago

          We are. I read I feel like committing secrets to a config file instead of .env is a terrible idea. as I feel like committing secrets to a .env is a terrible idea..

          Muh bad.

    • TCB13@lemmy.worldOPEnglish
      2·
      18 hours ago

      I get the point, but don’t forget those “secrets” are bcrypt hashes. Not really reversible.

      • Vendetta9076@sh.itjust.worksEnglish
        51·
        16 hours ago

        The issue isn’t that. The issue is its a config folder and a lot of people back their configs up to things like github.

        • TCB13@lemmy.worldOPEnglish
          1·
          8 hours ago

          You can backup the entire file then. I get your point, but it also seems like you’re referring to some container-based approach where you would place this inside a container and then mount the config file to some path. While some people might like that approach, that kind of goes against the original idea here, I didn’t want to run yet another instance of nginx for auth, nor another php-fpm - the ideia was simply to use this on a low power device , no containers, no overhead of duplicate webservers and PHP, just a single nginx running a couple of apps on the same php-fpm alongside this.