Self hosting (Akkoma) from home

I’ve been self hosting from home for over 5 years now. I wanted to write an article explaining steps to get you started and pitfalls you can encounter. I kinda aimed it at hosting Akkoma, but it should be usable more broadly as well.

Why

Self hosting from home may be cheaper than getting a VPS, but it’s also more work and more time consuming. Home connections are typically quite slow compared to the speed you can get on VPS’es, so your instance may be considerably slower than using even a cheap VPS. Uploading and posting big files can also saturate the network while others are all fetching your media at the same time. And your ISP may make it hard on you if they aren’t a big fan of people self-hosting from home.

Still, even with all these downsides, if you like tinkering with servers a bit, then self-hosting from home can be a fun experience and a great way to learn about system administration and hosting in general. Besides, it’s fun to brag to your friends about how you have your own social network platform hosted on an old laptop from your living room ^^’

Hardware

Akkoma is not the heaviest micro-blogging server software out there, but it’s not super-lightweight either and needs more than a proverbial toaster to run. An old laptop or PC can do just fine, or maybe you still have an SBC lying around, ready to be used in a fun project like this. From my personal experience, I would advise the following:

• Make sure you have 2G RAM minimum and enable swap. Preferably more, but this should be enough to start.
• For storage size, it depends. The database can quickly grow, but there’s ways to minimise this. You can prune old remote objects and activities, you can expire your own posts, you can automatically remove old media when posts are deleted… Assuming it’s a single user instance and you don’t pull in too many posts, 20G should be enough to start. But if you’re using an old laptop, you probably have closer to 100G, so this shouldn’t be an issue regardless.
• It’s important to understand that many writes happen to the database, so using a HD is better than a cheap SD card for example, because SD cards are notorious for breaking down after too many writes.
• For CPU, I run on an Intel i5, which is good enough. Lower will possibly also work.
• You can expect a home network to be slower than a VPS, so the faster, the better. I have 20Mbs down and 2Mbs up, which is quite slow. My instance is not very snappy, but it’s generally fast enough for my needs.

Connecting to your server from the local network

First you need to set up your server with an OS. Use any of the OS’es that are supported by Akkoma. For specific steps on how to install the OS, check the website of the OS or hardware.

Next we need to know the IP address we have on the local network. If you can get inside your router, then maybe you can see the server there and what IP address it got. This is specific to the router and ISP, so you’ll need to figure that part out yourself. Another option is to check it from the server itself using one of these commands.

hostname -I

ip address

When you type the IP address in the address bar of a browser on a different machine on the local network (maybe your phone or laptop if it’s connected over wifi), it will probably give an error that it can’t connect. This is normal, because you probably don’t have anything running yet.

First we’ll make sure we have a simple webpage on the server so we can easily connect to that. The easiest way is to install an http server and check it’s default landing page. Examples are Caddy, Nginx, or Apache. You need this when installing Akkoma, so you may as well install it now. Once the http server is up, you should see the HTML of the http server’s default page when doing curl localhost on the server.

Now check if you can indeed access that page from the web browser on the other machine on the local network. You should see the default page.

If this works, awesome \o/ You now have a server running with a website, and can connect to it! You are now officially a sysadmin <3

Connecting to the server from the internet

Now comes the big step, making it available from the internet! Just like how your server is connected to the local network over a local IP, so is your home connection connected to the internet over a public IP. If you’re lucky, you have an IP dedicated for your home connection and you can forward traffic to your server. This needs to be done from your router. Each ISP and router is different and not all of them allow you to do this, or don’t allow it for all ports. You’ll need to find some documentation and try things out yourself. See if you have a booklet that came with the router, or look for information online. The Yunohost project has a list of ISP’s per country. You can check if they have something about your ISP on this. If not, you can always try yourself, and add your findings to the Yunohost documentation so it can help others as well.

We need to set up port forwarding for at least port 80 and port 443. If you want to connect to the server over other ports, e.g. port 22 as the default port for ssh connections, then you need to set up port forwarding for that too. Again, how to do this exactly, depends on your ISP and router box, so this is a part that you’ll need to figure out yourself and may not even be possible.

Once the port forwarding is set up, you can try connecting to the server by using the external, internet facing, IP address. To find this IP address, you can use a service who responds with the IP address they see from you. Here are two examples who should answer with your internet-facing IP address.

curl "https://ip.yunohost.org"

curl "http://t.karchnu.fr/ip.php"

Then you can type this IP in the address bar of a browser on any machine connected to the internet, and it should show the landing site you saw earlier. If it doesn’t work from a machine inside your local network, try from a machine outside the local network (see the Hairpinning section below).

Point your domain to the correct IP

Now that we can connect to the server from the internet, we need to point our domain to it. Generally speaking, you will buy a domain at a registrar, and then set up DNS records there.

In this example, the public IP address is 192.0.2.0, change this to your own public IP. The first example is directly on the domain, the second example is on a subdomain like social.example.org.

@ 3600 IN A 192.0.2.0

social 3600 IN A 192.0.2.0

Another option is to have a DDNS domain (see below), in which case you have to set that up. How to do it, depends on where you got it and should be explained there.

Once it’s set up, you can test if the domain points to the IP address properly with any of these commands. We use example.org as an example, change this to your own domain. Note that the DNS system uses caching, so if you see a different IP address, it’s possible you will need to wait until the cache expires. The dig command will show how long it still takes for the cache to expire.

ping example.org

dig example.org

Once this works, you should be able to browse to the page using your own domain. Hooray \o/

Some potential problems with home IP’s

Allowing people to self host from home is generally not a concern most ISP’s have. In some cases they even actively make it difficult for you to self host. If you live in France, then maybe you can join one of the FFDN members. They are, among other things, ISP’s who promote self hosting. (If you ever wondered why the French can have nice things, it’s because they are not afraid to protest, you should protest more -_^ )

If you do not live in France, you may still be able to get a fixed IP with open ports through a VPN from one of the FFDN members. IMO it’s by far the easiest solution because then you don’t even need port forwarding, you get a VPN connection from them, activate it on your server, and done.

While these ISP’s are friendly to self hosting, others may cause issues. The following are typical problems you may face when self hosting from home. If the above isn’t an option, there are still some possible work-around you can consider.

Hairpinning

It’s possible that a connection to your server using the public IP is possible from outside the local network, but not from inside the local network. The problem is that your router forwards a request to itself upstream, which causes an error. The solution to this is hairpinning. The router will detect the request is meant for itself, and will then handle that properly. This is something that needs to be set up on the router, and may or may not not be possible on yours.

If you have this problem, and you can’t configure hairpinning on the router, you’ll need to see in how far you want/need to work around this problem. The server is accessible from outside the local network, so for the rest of the world, nothing is wrong. Maybe that’s enough for you, maybe not.

If you want to access the server from the local network as well, another option is to add your domain and the local IP to the hosts file of the machine you want to access it from. One problem with this is that it’s per machine, and if you leave the local network with that machine, the machine will still point to the local IP you set up, so accessing your server won’t be possible unless you change the hosts file again.

On Unix and Unix-like OS’es, the hosts file is /etc/hosts.

Dynamic IP address

Even if you can forward the needed ports, it’s possible that the IP address changes over time. If you can’t get a fixed IP address, one solution is to use Dynamic DNS (aka DDNS). The way this typically works is that you have a script running somewhere who, at certain intervals, updates the DNS records when your IP address changes. Some registrars provide this option, and there are also services who provide a subdomain with DDNS capabilities.

One such service is netlib.re. You can create an account, and get a subdomain under the netlib.re domain. With a script you can automatically check and update the IP address when it changes. If you install Yunohost, you can set up a DDNS domain provided by the Yunohost project.

You can either use this domain directly, or, if you want your own domain, you can set a CNAME or ALIAS DNS record.

Let’s say you have a DDNS domain my_account.netlib.re pointing to your server, and you want to point your own domain to the same IP address.

When you want to use a subdomain, e.g. social.example.org, you use a CNAME record. In this example social is the subdomain and my_account.netlib.re is the DDNS domain. Replace both with what you want to use.

social 900 IN CNAME my_account.netlib.re.

When you want to use your domain directly, an ALIAS record is needed. Again, my_account.netlib.re is the DDNS domain. Replace with what you have.

@ 900 IN ALIAS my_account.netlib.re.

Once set up, and the cache expires, your domain should point to whatever the DDNS domain is pointing to.

No forwarding for certain ports

Maybe it’s possible to forward certain ports, but not 80 and/or 443. There’s not much you can do in this case.

You can listen to a different port, but this will cause issues. You may need to do extra work to get Lets Encrypt to work to set up https, and others need to connect to you over a different than default port. This isn’t generally done on fedi, so I don’t know how software will react to this. Honestly, I’m not even sure if Akkoma can properly handle this.

Another option is if maybe you can set up a proxy somewhere. Then your domain needs to point to the proxy, and the proxy forwards the request to you on the open port. The problem is that now you need such a proxy server, and you probably want traffic to be encrypted between the proxy and your server. Handling certificates in this way, may get messy.

No forwarding at all

Sometimes port forwarding isn’t possible at all. A typical example is when your ISP uses Carrier-grade_NAT. In that case, the IP address the internet sees, will be shared with other people as well.

Even a proxy wont work in this example, so a VPN or switching ISP’s is really about all you can do.

Geolocation

Different ISP’s have different ranges of IP’s. Since they operate in specific areas, it’s possible to guess where someone is connected from based on their IP. In most cases this isn’t very specific, but maybe it’s still too precise for your comfort. In that case you may not want your home IP to be publicly visible.

Note that your IP is also visible to those to whom you do requests. Using a proxy may allow you to set a different IP address for your domain, but when your instance does requests to another instance, they will see the IP the request came from. For this reason a proxy is not enough, unless you set it up for both incoming and outgoing requests.

IPv4 vs IPv6

Generally, traffic on the internet is routed using IPv4. But there are limitations to the amount of existing addresses, and we have basically reached these limits. When this whole IP thing was first thought about, computer resources were still very limited. Each extra bit you had to send over the network was significant and the idea of more than a couple of thousand computers being connected this way was not obvious to everyone.

In 2017 IPv6 became an official internet standard. It solves some problems that IPv4 has. The addresses are longer, and, as such, there’s a much larger amount of possible addresses.

In this article we used IPv4 because afaik this is still the most used, and most probably the type of address you have on your home router. It’s possible however that you have an IPv6, or that your ISP allows you to get one when asked. If you have both, it is generally considered good practice to use both IPv4 and IPv6.

To check the public IPv6 address, you can try

curl "http://ip6.yunohost.org"

If you can’t connect, then you probably don’t have an IPv6 address to begin with.

To set the DNS records, you need an AAAA record instead of A. When you have DDNS, it’s possibly already set up correctly. If not, you can maybe check with the DDNS provider if they allow IPv6.

Here’s an example to set an AAAA record, change the IP address to your own.

@ 3600 IN AAAA 2001:db8::8a2e:370:acab

To check if a domain points to an IPv6 correctly, you can use dig.

dig -t AAAA example.org

Installing Akkoma

Once you can properly access the server from the internet, all that’s left to do is install Akkoma, or whatever other service you want to run, and enjoy the misery you brought upon yourself by choosing to self host 🤗

Have fun!