Don’t Depend on the Cloud for Everything! Host at Home!

Dude, why y u no host???

At the heart of Yunohost is the awesome idea of really bringing things under your own control – on your own hardware in your own home! That’s why Install at home comes before Install on a remote server on Yunohost’s Installation guide.

However, for $5 bucks a month, it’s hard to justify fighting with your ISP and router to make sure your critical services (like email and website) are working and secure from your dusty spare computer at home (not to mention backed up remotely). It’s much easier to justify hosting a few specific services at home – such as the ones that boost your monthly VPS bill from $5 to $25 or $50 or more. Two services in particular that are useful for basic productivity, but require some beefier computing resources, are document collaboration and video conferencing.

Set Up Your Home Computer

If you’re going the whole nine yards and want to host everything from home, I salute you. Simply follow Yunohost’s Install at home guide and the rest of the guides on this website to setup what you want. However, if all you want to do is set up a few CPU heavy services like the ones described below, then you don’t need a full-blown Yunohost operating system. And, thanks to the wonderful magic of Docker, you probably don’t even need to change anything! Just follow the Docker installation guide for your platform.

Set Up Video Conferencing From Home

To set up video conferencing, you can follow the same instructions for setting up video conferencing on a VPS, with the following additional/modified steps:

Set Your Docker Host Address

Modify PUBLIC_URL in your .env file to point to your computer’s local network address.

Configure A Proxy Server and HTTPS (SSL/TLS)

Jitsi requires a connection over HTTPS. Since Yunohost wont be managing our domains, we need to do this ourselves. An easy (and cost free!) way to set up HTTPS is with nginx-proxy and letsencrypt-nginx-proxy-companion. Just add the following to the `docker-compose.yml` file in docker-jitsi-meet:

    image: jwilder/nginx-proxy
    restart: always
      - "80:80"
      - "443:443"
      - ./current/public:/usr/share/nginx/html
      - ./certs:/etc/nginx/certs:ro
      - vhost:/etc/nginx/vhost.d
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
                - ${XMPP_DOMAIN}
    image: jrcs/letsencrypt-nginx-proxy-companion
    restart: always
      - ./certs:/etc/nginx/certs:rw
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - vhost:/etc/nginx/vhost.d
      - ./current/public:/usr/share/nginx/html
                - ${XMPP_DOMAIN}

Add this to the environment section of the Jitsi web service:

- VIRTUAL_HOST=<yoursubdomain.yourdomain.tld>
- LETSENCRYPT_HOST=<yoursubdomain.yourdomain.tld>

And add this to the end:


Configure Your Home Domain

If you’ve got Yunohost set up on a VPS, then you’ll need a different domain for your home since, IIUC, HTTPS requires a single host for managing SSL/TLS certificates. Otherwise, you can just point an “A” record for a subdomain at your home network’s public IP address (you can find this easily on Google by typing “what is my IP address?”, or other services like

Configure Your Router

Now that your home network is exposed to the internet, you need to tell the internet which computer in your network to talk to. You can do this by setting up port forwarding on your router. To do that, you’ll need to log in to your router and access its NAT configuration. Look at the bottom of your router or a manual to figure out its local IP address and login information.

Note: In order to access your “remote” network from computers within your home domain, you may need to add explicit internal name resolution for your domains to each computer’s /etc/hosts, file e.g.

192.168.XX.XXX chat.youhomedomain.tld collabora.yourhomedomain.tld yourhomedomain.tld

There’s certainly a more elegant way to do this, but I haven’t tried it out yet.

Set Up Document Collaboration From Home

Multi-user document collaboration is another memory and CPU intensive feature which you can offload to your home server.

Update docker-compose

If you have already set up video conferencing with Docker, as described above, simply add the following to your Jitsi docker-compose file:

  image: collabora/code
  restart: always
    - MKNOD
      - VIRTUAL_HOST=collabora.yourhomedomain.tld
      - VIRTUAL_PORT=9980
      - VIRTUAL_PROTO=https
      - LETSENCRYPT_HOST=collabora.yourhomedomain.tld
      - server_name=collabora.yourhomedomain.tld
      - domain=nextcloud\\.yournextclouddomain\\.tld
      - username=admin
      - password=somesecretpassword
      - '9980:9980'
             - ${XMPP_DOMAIN}

This is clearly a bit of a hack as it simply adds Collabora to your Jitsi docker-compose file and network. If you’re not running Jitsi you can take out the meet.jitsi network, but you’ll still need a common network for nginx-proxy and letsencrypt-nginx-proxy-companion.

Add Port-Forwarding

nginx-proxy will proxy your Collabora service to port 80, so you’ll need to open that port on your router’s firewall (as described for the Jitsi configuration, above).

Configure Nextcloud

In your Nextcloud instance under “Settings > Administration > Collabora Online”, select “use your own server”, and enter your url: https://collabora.yourhomedomain.tld and click “Save”.

Set Up “Remote” Storage From Home

One of the biggest expenses of a VPS is remote block storage (see File Sync and Remote Storage/Backup). Having a central file repository is useful for keeping data on multiple computers synchronized, but it doesn’t necessarily need to be “remote”, in the sense of “not in your home” or on a hosted VPS. Your file storage should be remotely accessible, however, so that when you’re taking pictures around town or on vacation your files are synchronized from wherever you are. You can do that by simply setting up your remote storage from home.

NOTE: This guide assumes you have already set up Nextcloud to manage remote file synchronization.

Set Up SSH

Your server at home needs to have an SSH service running. Typically this is done on Linux or OSX systems by simply installing OpenSSH. Once you have SSH running, you’ll also need to set up port forwarding for port 22 (or whatever your SSH service is running on) – similar to the instructions above for setting up video conferencing. Make sure you disable password authentication in your SSH config! This important, especially if you haven’t isolated your home server from the rest of your network.

In order to provide remote access to your home file server from your remote file synchronization system, you’ll need to generate a public key on the remote system and copy that to your authorized_keys file on your home system.

Set Up an SSH File System

Once your SSH service is accessible from outside your network, you can mount the folder on your home server that you want to use for file storage for your remote Nextcloud instance. For that, you’ll need to install SSHFS.

After installing SSHFS, you’ll need to “mount” and SSH file system with a command similar to the following:

sudo sshfs -o allow_other,uid=999,gid=999,IdentityFile=/home/admin/.ssh/id_rsa youruser@yourhomedomain.tld:/home/yourfilefolder /mnt/yourremotefiles

Replace the uid and gid parameters above with the ID of your nextcloud user (id nextcloud). To make it permanent across reboots, add the following to /etc/fstab:

sshfs#youruser@yourhomedomain.tld:/home/yourfilefolder /mnt/yourremotefiles fuse allow_other,_netdev,reconnect,delay_connect,ServerAliveInterval=15,
999,gid=999,IdentityFile=/home/admin/.ssh/id_rsa 0 0

Configure Nextcloud

Finally, make sure the “External Storages” section of your Nextcloud instance (under “Settings > Administration > External Storages”) has an entry pointing to the file mount described above (e.g. /mnt/yourremotefiles). Nextcloud file sync also has an unfortunate “feature” which will cause it to delete all of your local files if there is a disruption in a connection to your file store, such as from a power outage or something that causes your home comptuer/storage to shut down. Some people have said that they are able to prevent this by setting moveToTrash=true in ~/.var/app/com.nextcloud.desktopclient.nextcloud/config/Nextcloud/nextcloud.cfg on your local machine, then they just move the files back. This didn’t work for me, and since you would need to do it for every device, I prefer to set up a simple cron job to detect if there’s a disconnect and shut down the database so your sync client isn’t prompted to delete your local files. Then you can manually re-enable the database once your files are back . To do this,

1. Create a shell script with the following contents:


if [[ $(ls /mnt/yourremotefiles | wc -l) -lt 1 ]]; then
    yunohost service stop mysql
    exit 1

2. Make the file executable:

sudo chmod 775

3. Add a crontab to the root user like the following (sudo crontab -e):

*/1 * * * * /bin/bash /home/admin/

A Word On Disaster Recovery

One disadvantage of hosting your own file storage at home vs. on a remote VPS is you don’t get de facto disaster recovery. However, depending on your life-style, this may not be much of an issue.

Two main types of “disaster” that could threaten your data that come easily to mind are:

  • robbery, and
  • fire

However, if you’re like me, I usually take my laptop with me whenever I leave the home, so robbery is unlikely to be an issue. Similarly, in the case of a fire, my computer is probably one of the first things I’d grab if I had to flee the house.

So, while this isn’t perfect disaster recovery, it might be enough to suit your needs and save you $15+/mo. on hosted block storage. Alternatively, you could set up a remote backup system at a friend’s house. In order to make this convenient for your friend, however, you would probably want to set up a reverse SSH tunnel to your server (to avoid punching holes in their firewall), secure incoming traffic from your server (so backups aren’t compromised if your server is), and make sure your system auto-configures the tunnel in case of a power outage, etc. Not to mention setting up a monitoring system and troubleshooting network issues remotely. In summary, possible, but a bit more complicated.

Leave a Reply

Your email address will not be published. Required fields are marked *