Hello r/selfhosted community!

I’m currently delving into the world of self-hosting and would love to get your insights on a couple of concepts I’m exploring. Your experiences and opinions would be incredibly valuable to me.

  1. App Management Philosophy: I’m torn between two approaches to app management in a self-hosted setup. On one hand, there’s the Unix philosophy of “doing one thing well” which would involve using multiple apps, each dedicated to a specific function (like Homebox, Ghostfolio, Mealie, Firefly, Plane, etc.). This approach, however, seems to increase the attack surface and complexity. On the other hand, there’s the idea of hacking a single tool (like NocoDB combined with Metabase/Superset) to cover multiple needs, which could simplify monitoring and management. What are your thoughts on these approaches in terms of security, maintenance, and overall efficiency?
  2. Database Strategy: Another area I’m seeking advice on is database management. I’m considering two options:
  • Having a separate PostgreSQL database for each service within its Docker-compose declaration.
  • Allocating a separate VM solely for databases (like PostgreSQL, MariaDB, etc.) and creating different users for each service.
  • What are the pros and cons of these strategies from your experience, especially in terms of performance, security, and ease of management?

I’m really looking forward to hearing your thoughts and learning from your experiences. Thank you in advance for sharing your ideas!

  • wraith@lemm.ee
    link
    fedilink
    English
    arrow-up
    1
    ·
    7 months ago

    With regards to app management the Unix way is the way. You’ll have individual tools that you can spin up or take down at will. When something needs maintenance, or it crashes, all your other services will stay running.

    As to an attack surface, that can be mitigated by using a VPN if you need access from outside your network. Then you’re back to an individual tool doing one job really well (and probably being audited for that by outside parties).

    Databases are a slightly different challenge but you can still think of them in a similar way regarding service availability. If all your services use a single instance then when that instance goes down for maintenance or backups all of your services will be offline.

    Similarly there can be issues with compatibility between the service and the specific database (and/or version) which could necessitate a dedicated database for a certain service. But if each service (or possibly similar related services) use dedicated database instances then maintenance of that stack is simplified.

    I’m of the mind that with the flexibility of containerized software stacks there’s no real reason to have a single monolithic database anymore, certainly not for small, self-hosted, applications that are not under heavy use.