7 ms·

I'm a developer who's been taking a crack at the convenience problem of selfhosting. I've been hosting my own services with various success for the last few ye

I'm a developer who's been taking a crack at the convenience problem of selfhosting. I've been hosting my own services with various success for the last few years, and maintenance has never been an issue. Once the software is running, it's pretty trivial to update it. The biggest pain point is installation. Most selfhosted software has a ton of dependencies to install first. And after that there's usually some configuration that has to be done before it will work. A complicated installation is enough to drive even tech savy users away. I've had some luck with my own software by targeting Windows users as well. Most people don't want to setup a linux box just to selfhost a single piece of software.

h1d 8y ago
I suppose those "ton of dependencies" are usually handled via package managers in a single line usually mentioned in their doc. I've run servers for 15 years but if something asks me to install tons of stuff manually, I won't even look at it. Initial config surely varies from wall of text config to a simple web based config but popular apps usually have decent doc or googleability to keep you out of maze easily.
- GordonS 8y ago
  Alas, but in my long experience that's seldom the case. Invariably you end up having to add GPG keys for a bunch of weird and wonderful 3rd party package sites, then fight with your package manager to get it to use them, spend hours scouring the web for source code tarballs, spend an age fiddling with compiler flags to get things to build, and... ach! Eventually you're bound to wish you'd never started in the first place!
  - h1d 8y ago
    What kind of niche product are you using? I wouldn't add some 'weird' 3rd party package sites but only if those are official repositories from the upstream. You do not compile stuff unless you're on something like OpenBSD and the binary doesn't exist. That is a very weird experience if you're using popular apps.
    - ccmcarey 8y ago
      You compile stuff if the binary doesn't exist, regardless of OS. It's very normal on Arch Linux at least to pull build files from the Arch User Repository and build the software locally.
    - GordonS 8y ago
      I have this kind of problem regularly, especially if I want to run versions of software newer than 3 years old. Also, compiling software is quite normal on Linux. Often it's just `make && sudo make install`, and everything works - but sometimes you've got to go on a goose chase to fulfill dependencies, tinker with compiler flags etc.
aklemm 8y ago
Maintenance and updates as the software changes is arguably a bigger inconvenience than the initial setup.
orange222 8y ago
Why not just go with a docker image, no manual installation of individual dependencies necessary.
- weberc2 8y ago
  Most interesting apps run as multiple containers (e.g., a database) and then you need to provision volumes for application's data and configuration files. It doesn't seem clear to me that this is a strictly simpler state of affairs than local installation. The real wins from Docker (for this use case) are: 1. Docker is a better process supervisor than systemd and friends 2. Simple, fast deployment (no manage ansible scripts or rebuild/reboot a machine image) 3. Built-in, standard logging
  - orange222 8y ago
    I think helm (helm.sh) solves that problem. Helm is basically package manager of kubernetes. So to install any app, as long as there is a helm chart for that app, you simply do: helm install myapp and helm will install the app on your kubernetes cluster.
    - weberc2 8y ago
      Right, but now you're running Kubernetes for a single server, which is the very definition of overkill. Installing Kubernetes isn't easy, at least not when you consider DNS, ingres/load balancing, logging, etc.
      - orange222 8y ago
        Scenario #1: Installing kubernetes, helm and then installing your app 1. Spend maybe 2-3 full days install kubernetes, helm 2. Spend maybe 3-4 hours installing your app through helm because you're new to installing things in kubernetes. 3. The next app that you want to install on your server is only 20 minutes away, now that you understand how kube and helm work. Scenario #2: 1. Install app directly on server, hunt down dependencies and other weird things, probably takes 1 day at least, to do the whole installation. 2. The next app that you want to install will take the same amount of time again. I'd go with Scenario #1 as it is more scalable if I want to install more apps on my server.

h1d 8y ago

I suppose those "ton of dependencies" are usually handled via package managers in a single line usually mentioned in their doc. I've run servers for 15 years but if something asks me to install tons of stuff manually, I won't even look at it. Initial config surely varies from wall of text config to a simple web based config but popular apps usually have decent doc or googleability to keep you out of maze easily.

GordonS 8y ago
Alas, but in my long experience that's seldom the case. Invariably you end up having to add GPG keys for a bunch of weird and wonderful 3rd party package sites, then fight with your package manager to get it to use them, spend hours scouring the web for source code tarballs, spend an age fiddling with compiler flags to get things to build, and... ach! Eventually you're bound to wish you'd never started in the first place!
- h1d 8y ago
  What kind of niche product are you using? I wouldn't add some 'weird' 3rd party package sites but only if those are official repositories from the upstream. You do not compile stuff unless you're on something like OpenBSD and the binary doesn't exist. That is a very weird experience if you're using popular apps.
  - ccmcarey 8y ago
    You compile stuff if the binary doesn't exist, regardless of OS. It's very normal on Arch Linux at least to pull build files from the Arch User Repository and build the software locally.
  - GordonS 8y ago
    I have this kind of problem regularly, especially if I want to run versions of software newer than 3 years old. Also, compiling software is quite normal on Linux. Often it's just `make && sudo make install`, and everything works - but sometimes you've got to go on a goose chase to fulfill dependencies, tinker with compiler flags etc.

aklemm 8y ago

Maintenance and updates as the software changes is arguably a bigger inconvenience than the initial setup.

orange222 8y ago

Why not just go with a docker image, no manual installation of individual dependencies necessary.

weberc2 8y ago
Most interesting apps run as multiple containers (e.g., a database) and then you need to provision volumes for application's data and configuration files. It doesn't seem clear to me that this is a strictly simpler state of affairs than local installation. The real wins from Docker (for this use case) are: 1. Docker is a better process supervisor than systemd and friends 2. Simple, fast deployment (no manage ansible scripts or rebuild/reboot a machine image) 3. Built-in, standard logging
- orange222 8y ago
  I think helm (helm.sh) solves that problem. Helm is basically package manager of kubernetes. So to install any app, as long as there is a helm chart for that app, you simply do: helm install myapp and helm will install the app on your kubernetes cluster.
  - weberc2 8y ago
    Right, but now you're running Kubernetes for a single server, which is the very definition of overkill. Installing Kubernetes isn't easy, at least not when you consider DNS, ingres/load balancing, logging, etc.
    - orange222 8y ago
      Scenario #1: Installing kubernetes, helm and then installing your app 1. Spend maybe 2-3 full days install kubernetes, helm 2. Spend maybe 3-4 hours installing your app through helm because you're new to installing things in kubernetes. 3. The next app that you want to install on your server is only 20 minutes away, now that you understand how kube and helm work. Scenario #2: 1. Install app directly on server, hunt down dependencies and other weird things, probably takes 1 day at least, to do the whole installation. 2. The next app that you want to install will take the same amount of time again. I'd go with Scenario #1 as it is more scalable if I want to install more apps on my server.