this post was submitted on 26 Nov 2023
4 points (100.0% liked)

Self-Hosted Main

515 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
 

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!

you are viewing a single comment's thread
view the rest of the comments
[–] wraith@lemm.ee 1 points 11 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.