That was my perception years ago, that made me timid with starting my journey because everyone starts big! A minimum newest on-the-line quadcore processor along with 8GB memory, and to top it off, 1TB SSD. I simply can't afford it, and that's where my interest stopped.

Exactly a year ago, I decided to buy a meagre VPS with 1 CPU, 1GB memory, and 20GB storage, intending to learn more about Linux, Docker, Kubernetes, and clouds in general. My thought was always in doubt, is this enough to do the job i wanted it to do?

Boy, I could never be so wrong.

That meagre VPS was more capable than I could give credit for, hosting this site, my Akkoma instance, and tons of other services I used for myself.

Now, what could I learn to do better?

Failure

It has been a year since I dabbled in self-hosting, but the truth is, this site and others services of mine has only started running on March, or at least three months since the journey started.

You guess it correctly. It failed the first few times. From losing the SSH passkey (I'm dumb), messed up my server with botched installation of several services at once, struggling with the concept of reverse proxy, load balancer, and web server (what are the difference), premature use of Docker, and from just sheer frustation of the immense things you need to set up before you can enjoy it.

The early set up after frustrations took me almost a month, from setting up Docker properly (and the fact that Docker opened up the port immediately if you don't specify in the Docker-compose file), installing Caddy and its configurations, Wireguard to access over internal services, setting up Traefik to use TLS for internal services (this by far is the hardest hurdle along with Wireguard).

In all of that, it was a fun hurdle. Figuring out why Wireguard doesn't need you to open ports, why Docker images are usually not auto-updated, why Traefik won't work when Wireguard is not on container but on the host (haven't found the answer to this one).

In short, be prepared for the difficulty and frustration ahead, if you never had the experience. It is part of the learning. And use Google a lot. Like a lot. Also, there are things that you can understand just yet and b

Cost

In my case, it costs me around IDR120,000 ($8) a month for my hosting (2-core, 2GB memory, and 40GB storage), and another $16 a year for this domain. So roughly $10 a month.

At the start, the hosting only costs me $3.5, with 1-core, 1GB memory, and 20GB storage.

It depends on your hosting provider, and the domain extension you use. My point is, you don't need fancy hardwares worth thousands of dollars or a beefy VPS that costs more than fifty dollars a month. You can always start small and scale your resources based on usage. Though this might not apply for those that wants self-hosted media server, since it needs more powers and storage that a web service does. Again, adjust to your needs, not wants.

Why? Because usually your host will let you upgrade for free, but not the reverse.

Horsepower

As pointed out in the cost, and in the intros, you don't need massive homelab or a dedicated server to run your Nextcloud instances, this is a common misconception among first-timers.

“I mean, my laptop has 8GB RAM and it can barely runs Chrome! That means my media server needs to run on 16 or even 32GB RAM! And who knows, it might need the latest GPU as well.”

Well, if you are hosting a media server for your entire neighbourhood, you are in the right track. But if you need it just for your family, or just for yourself, try less.

I did doubt that I could run as many services as I did now when I bought the 1-core and 1GB memory VPS. But it didn't last long as I installed services after services until I reach 100% memory usage (CPU isn't as much used in my case, probably only Akkoma did use CPU). That's when I upgraded. Looking back, for my needs, the current 2-core and 2GB memory is well enough for my need. Though as others may note, the feelings of needing more is never gone.

Maintenance and Stability

Seeing i'm using this services by myself, my failure tolerance is much higher, since i'm doing all for myself. But all in all, most of my services never failed me in the whole year I've been hosting them, even during major upgrade.

Docker made upgrading as easy as docker pull, though it has its own caveats.

Looking back, my server is actually pretty stable, at least for my standard. Measuring uptime from Fediverse.Observer of my Akkoma instance, it has yet to fell down to below 95%.

Now, I've been doing a hands-down approach to my server, upgrading services and OS when updates come out, without much thinking. Yeah, I did upgrade my services without doing some tests. But my YOLO has yet to fail me so far (maybe I'm going to run out of luck soon, finger crossed), and from maintenance point, it's pretty lax, especially when you have set up alerting services.

That said, maintainability really depends on how you set up your services and tools you can use to help make your life better.

That's it for now, I guess. I will write more when I have time.

On September 20th 2022, Caddy 2.6 was released and HTTP/3 became default settings. Well, now you don't need an obscure option to enable it! However, when I checked my (this) website on http3check, it seems HTTP/3 wasn't supported. I read that HTTP/3 is enabled automatically and no new settings is needed on Caddy. And that HTTP/3 is using UDP too.

Enabling UDP on port 443 with ufw, I checked again. Still doesn't support HTTP/3. What's wrong?

Turns out you need to explicitly forward UDP to the Docker container, and the bare port option 443:443 only opens the TCP port.

Here's the port config:

    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"

The 443:443/udp is the one config you need to explicitly write. Afterwards, checking again this site supports HTTP/3!

A note, you need to have at least Caddy version 2.6.0 for default HTTP/3 support.

P.S. http3check still mentioned that QUIC is not supported. But somehow when I scanned caddyserver.com, http3check mentioned it doesn't support QUIC as well. I guess I need to dive again to see what's wrong.

But then, last month, i read something in my timeline, there is a new fork of Pleroma named Akkoma. Interesting!

It's never that easy in migrating your instance, so i asked @sn0w@cofe.rocks again for help! Thankfully they are willing to help me quite a bit! I have outlined the steps here for my future reference, and might be of some help for others.

The Steps

First of all, backup your configuration and database. You'll never know what mistakes you are going to make (i have certainly made some embarassing mistakes).

Current Akkoma doesn't include any frontends by default, including the Admin-FE. So i'm going to edit my docker-compose.yml file to mount the frontends folder to host.

Add this under volumes:

$DOCKER_DATADIR/frontends:/home/pleroma/pleroma/instance/static/frontends

And edit the config.exs mount from :ro to :rw for both occassions.

After this, you need to edit the .env file on two lines:

PLEROMA_VERSION=stable-2022.07
.
.
.
.
PLEROMA_GIT_REPO=https://akkoma.dev/AkkomaGang/akkoma.git

stable-2022.07 is as-of-now the most recent release of Akkoma, which should be changed should newer versions got released, or you can use stable if you prefer. The repo referred to the new Akkoma official repo.

Then you can run ./pleroma.sh build and wait a bit.

When you are done, you should run ./pleroma.sh down and ./pleroma.sh up to use the newly built image.

Congratulation, you have migrated to Akkoma! But wait, there is no frontends?

Installing Frontends

Thankfully, we can install a frontend by our own. This official guide comprehensively explains the technical details.

But for those lazy one, and assuming you want your default Pleroma frontend along with your admin frontend back, you should run this command

./pleroma.sh mix pleroma.frontend install pleroma-fe
./pleroma.sh mix pleroma.frontend install admin-fe

You should check your frontends folder, there would be your frontends folder inside it, named respectively.

Done? Not quite.

You should edit your config.exs file, and add this line anywhere:

# Configure Akkoma Frontends
config :pleroma, :frontends,
  primary: %{
    "name" => "pleroma-fe",
    "ref" => "stable"
  },
  admin: %{
    "name" => "admin-fe",
    "ref" => "stable"
  }

This ensures that Akkoma knows your frontends preference. Run ./pleroma.sh restart to apply changes, and you are dandy!

You can check your current running version of Akkoma by visiting this address on your instance:

https://$YOURINSTANCEADDRESS/nodeinfo/2.0.json

The Impression

The migration went smoother than expected, so much that i feared i have messed everything up. Turns out that's not the case.

On the surface, Akkoma differs little from Pleroma, but there are definitely some QoL improvements. One thing that stucks is the fact that you can install another frontend from your Admin-FE. Haven't tried that, but it's a nice addition.

The fact that development seems to be active is good indication that it is not abandoned. There are even a feature to-do list!

Overall, i'm thankful for sn0w's responsive help in guiding me and the docker templates, and for the whole Akkoma dev teams for this superb software!

One of the joy of hosting your own blog is that you can customise it to your own liking. It should be noted, however, that you need some expertise to do what you want.

Customising WriteFreely isn't a well documented feature, so you would need to scour the web a bit for a way to do it. I have done it before, albeit by awkwardly editing the files, with the Fediring footer down below.

However, I wondered if there are simpler way to do it?

Turns out WriteAs Discourse has the answer.

I tried the method explained here, inserting it in the easy-to-access Custom CSS in the Dashboard.

This method works by dissecting the custom CSS, that is conveniently placed in <HEAD> by inserting a </style>, thus closing the CSS. Then you insert your custom script there, and opened a new <style> again so it doesn't break your site.

A crude method, but it does work. There is a more elegant way explained here, but i haven't made it work. It threw no such template "umami" everytime i tried it, so I must've made some mistake. If have made it work, please do contact me!

Until WriteFreely provides a documentation for customising the site, it should serve as a shortcut, since i believe for all WriteFreely simplicity, it doesn't intend to cater to everyone's need.

Technical Aspect

Since i have been setting up everything as a Docker container, i was looking for guides to install Pleroma on Docker. Surprisingly, Pleroma doesn't officially support Docker installation, or at least doesn't recommended it on their docs.

I turn to look for a guide elsewhere, it seems improbable that no-one has tried it.

First i stumbled upon angristan's repo and immediately shot up a docker-compose file.

And the fact that i need to build it first those scared me a bit. I've been enjoying ready-to-use image from Docker Hub for my container, and compling or building sounds too technicaly for my grasp.

But actually the provided Dockerfile does most of the job, i just need to add

      context: .

on my docker-compose file, and it builds itself.

That parts done, and now i stumbled upon error. (To be honest, if i didn't encounter any error during my first try, i'd have been suspicious. At this point, error and failure are the norms, and troubleshooting is the learning path.)

If i remembered correctly, there was two configuration files, and i was confused between the two. And thus it failed to build. (I have take a look at the repo again and it seems clearer now, but in retrospect i just don't understand much about Pleroma.) Took me another three days to pour over reading Pleroma docs. It is quite simple, but arcane for me then. Well, am i not qualified enough to host my own Fediverse instance?

My second try was when i stumbled upon @sn0w@cofe.rocks repo.

Upon first look, it's noob friendly. They have prepared a script to manage your installation. First, i need to edit provided .env.dist and config.dist.exs and rename them to remove the 'dist'.

The .env file doesn't need tweaking, maybe just the UID and GID to match your current user.

The config.exs file though, is a different matter. For reference here is the entire config cheat sheet.

The provided file is enough, you just need to tweak the database part, web endpoint (along with the secret key that you can generate), instance part.

I added a few of my tweaks based on reading the Cheat Sheet:

config :pleroma, Pleroma.Web.Endpoint,
  url: [host: "sun.minuscule.space", scheme: "https", port: 443],
  secret_key_base: "v3ry/seCre7-keY-8as3",
## Configure cookie flag and CSP policy
  secure_cookie_flag: true,
  extra_cookie_attrs: [
    "SameSite=Lax"
  ]

## Enabling settings from web admin
config :pleroma, configurable_from_database: true

## Disabling shoutbox feature
config :pleroma, :shout,
  enabled: false

Afterwards, the build process is quite seamless once you figured out the quirk on the config file.

Once then, you are good to go to dwelve into your own corner of Fediverse!

Not-so-technical Aspect and Post-Install

This is a must read article for Pleroma or maybe any Fediverse instance out there:

https://blog.soykaf.com/post/how-federation-works/

In short, it explains your new and barren instance. The blogpost explains the concept of federation in Fediverse quite simple. To make your instance more lively, you can follow more people, or you can use relay instead.

Note that there are some caveats in using public relay, that i learnt only thanks to others.

1. What it does is repeating posts all over following instances.

So if there are some offensive or malicious instances on the relay, it would be relayed to your instance and your federated timeline. You will need to spend extra time curating the right instances and the right relay. It might be worth your case, but for mine it doesn't.

2. Federation works like email.

Your instance store a local copy of the others' posts, this might need to be taken into consideration for those who have limited storage, like i do in my VPS. This is the dealbreaker for my timid 30GB storage.

In my opinion, the best way to populate your instance is still to follow quality people all over the Fediverse. @FediFollows@mastodon.online is a very good reference to start.

The Downside

After one month of self-hosting, i would like to state that it is not a smooth journey. There are, in my observation, some downsides.

1. Lower Exposure

For people who cared a lot about exposure, self-hosting a single-user instance might not suit them well. The fact that your post propagates to a lesser extent than in bigger instances, due to technical factor, is enough for me to rethink again about my position.

The solution seems to use relay and have people following you. So, if you already have a big following, it might not bother you much. If there's an existing solution for better exposure on small instance, please leave a reply!

2. Not So Easy Finding New Accounts to Follow

In the same vein as point one, looking for new accounts to follow is harder. At first, you need to enter the handle of the account to your searchbar to follow them, since most likely you haven't federated with their instances. This forces you to rely on external service (or visiting other instances) to discover accounts to follow.

Also, the fact that you can only see their posts from the moment you follow them (and some pinned posts along with assortment of few posts if you are lucky).

A highly accurate image depicting newly discovered account. Credit goes to @ella@transmom.love

Solutions might be to follow @FediFollows@mastodon.online to discover new accounts, or creating an account on bigger instance just for account discovery.

3. Higher Maintenance Cost

Cost doesn't only mean money, but also time. There is bound to be some quirks along the way, and you need to be ready to troubleshoot them. Of course, some might relish in their journey to troubleshoot problems, but for some this is a no-go.

Alternatives might be using hosted solution, such as masto.host or spacebear.ee (spacebear have revamped their landing page, it's nice). Thus you only need to spend money and no maintenance hassle.

Closing Remarks

Self-hosting is not everyone of course. Maintaining an instance is not an easy work. For those in bigger instance, you should thank and support your instance admin for their hard work. The less you see them working, the better they are at their job.

But for those who dared to venture into the land of unknowns, Pleroma is simple enough to install, even without Docker. Why not Mastodon? It's a different entity, designed to scale to hundreds of thousands of users and thus, more complex than Pleroma.

For my usage, a VPS with 2-core, 2 GB of memory, and 30 GB of storage is enough. Most of the time Pleroma is only using around 10-20% of the CPU and at around 200-400 MB of memory. I'm hosting my Pleroma instance along with all other services (including this federated WriteFreely blog!), so it should be light on resource. Though it should be better if you have more cores, since it would make the building process faster.

Storage is one you should watch if you have limited space.

Anyway, this is how my journey has been so far. Not the smoothest experience ever, but it is manageable enough. Thanks for all the people who made self-hosting Pleroma possible, i would never reach this far without you!

P.S. If you spot some mistake, please @ me and i'll rectify it. I'm no way expert in Pleroma, Docker, or Fediverse, i'm still learning along the way!

Note: I've migrated my Pleroma instance to Akkoma due to faster development pace. See here.

Books always have a special place in my heart. And following my self-hosting excitement, naturally i'm interested in managing my (e-)books. Folks over on Linuxserver Awesome List have recommendation to manage your e-book collection, that is, Calibre and Calibre-web.

When comparing the two, i see that Calibre-web has a much modern interface, compared to Calibre website which honestly looks like a antique website. Naturally i choose Calibre-web.

Install went okay, since the fact that to start the container it took almost full two minutes that made me frantically looking at my compose file looking for mistakes. It works at the end, so no worries. After logging in, it prompts path to Calibre database. Looking at documentation, it recommends /book path as the location of the database.

But it founds nothing. Turns out you need to generate one on the Calibre container. Which is weird, since Calibre-web is just a pretty looking Calibre right?

Well, not really. Calibre-web is actually just a nicer front-end that you can expose to web browser, while Calibre is a desktop app to manage your e-book collection. Yes, a desktop app, not a web app.

Compounding the fact, Readarr, an automatic e-book downloader, specified the needs for Calibre Content Server, which is only availabe in Calibre, the desktop app.

Linuxserver.io does provide images for both Calibre and Calibre-web, which i haven't tried. Maybe i should in near future.

Closing

In short, Calibre-web is just a nice frontend for Calibre. Calibre is a e-book management app for desktop use.

First Steps

I often visit r/selfhosted, and it's a good point to start if you are lost. First, i tried self-hosting on bare metal, i.e. no virtualisation or docker. And it starts to get confusing, as a first timer. OnTrack was the first app i tried to install, and truth be told, it wasn't a wise decision. The documentation assumes you have prior knowledge of Ruby and installing Postgresql, which i don't. Managed to get it installed after a few grueling days, and exposed it on localhost:3000, but another problem came. I can't access it from outside! Turned out OnTrack only listened on 127.0.01, and after searching a bit, i found that i need a reverse proxy to forward it to internet.

Immediately i turned to Caddy, which i heard often due to its automatic TLS provision out-of-the-box. So i installed one. But again, my lack of experience with anything Linux hits me. I don't know where to put the Caddyfile, beside, what should i put on the Caddyfile so i can access localhost:3000 from outside? Reverse proxying example doesn't work, and i threw my hands in exasperated sigh. You know what? Self-hosting is not as easy as it looked like. (In hindsight, it was just my lack of knowledge rather than anything, or perhaps i should've tried something easier like Wordpress)

Took almost two-weeks off to cool my mind before deciding to give another shot.

Docker, the saviour.

Then Docker took away my attention. I have been avoiding it since the beginning since i don't know much about Docker, and it looked complicated. Containers? Docker-compose? Swarm? Docker network? It was just a buzzword in my ears. But i figure that it shouldn't be that complicated as my previous attempt. And so i jumped.

I'm a pretty paranoid person, so i searched for 'best security practice for Docker', in case i did the worst. The major things i learned was that Docker 'bypassed' UFW, and it's best to never expose your Docker socket (/var/run/docker.sock).

Fortunately, i stumbled upon this wonderful Docker-selfhosted-apps guide by BaptisteBdn on Github. (You are a lifesafer, truly.) I learned that you can fix 'Docker bypassing UFW' with this nice guide by Chaifeng. The fundamental of Docker is explained succinctly there by BaptisteBdn, and it was at this point i was wondering, 'Maybe i can do it.'

Interestingly, i didn't tried one of his apps first, but i was trying installing Caddy Docker Proxy by lucaslorentz. Honestly, i just fell in love with Caddy for its out-of-the-box simplicity, compared to Traefik labels at first sight. (After installing both at later point in time, i can say at my scale both are pretty much easy to use and install.) I failed a few times here, took me almost a week to get a Grav site, this site, running. I realised that most of my mistake is basically just typos here and there, which is actually quite significant when it comes to configuration. For example, i was trying “{{upstream}}” when trying to reverse proxy a container, and i missed the 's' in “{{upstreams}}” there. Another example was that i kept forgetting the 's' in docker-compose networks and environments configuration. As English is not my native language, i think i can get a pass here (hopefully).

Down the Rabbithole

Afterwards, i tried installing a more 'complex' apps, with database and such. Typing passwords and sensitive information on a plain docker-compose file always made me nervous, and fortunately i learned that you can pass it as a secret file! This MySQL installation guide helped me a lot, after i learned that you don't actually need Docker swarm for secrets to be passed. Bonus point i learned you can use openssl rand command to generate a random password and pipe it to a file. No more copy paste!

That taken care of, at this point i'm starting to consider VPN to access my service. Exposing a private apps to the internet seems like a major risk, and beside, i get to set up a VPN. Really cool. Both Wirehole guide and BaptisdeBdn's wireguard-unbound-pihole guide made it a breeze, and i'm really thankful for that. The headache came when i tried to install a Wireguard client on Ubuntu, and found out that Wireguard has no client apps? Just wg-quick, and guides out there pointed out you need to generate a private and public key for you to exchange with your server. Turned out, the Wireguard images have provided a ready-to-use conf file (and QR code) for you to use directly on your devices. Put it on /etc/wireguard/wg0.conf, run sudo wg-quick up wg0, sudo systemctl enable wg-quick@wg0.service, sudo systemctl start wg-quick@wg0.service, and you are good to go! People said it's easier than setting an OpenVPN client, but i couldn't attest that since Wireguard is my first experience in dealing with VPN.

And i went crazy after that. Installed note-taking apps, automation tools, Gotify, and so on. I must say it's really a breeze in self-hosting with Docker once you got past the initial confusion. I might need to run a nmap scan on my server again to find rogue open port, and pen testing it i guess so it's safe. Or am i overdoing this stuffs? Eh, i guess no one know at this point.