I have historically been putting off “self-hosting” or running certain services on my own for a few reasons:
I did not see as much appeal in renting a VPS with more than modest specs to allow me to access services from anywhere (not to mention the elevated risks with hosting something publicly)
Getting a dedicated machine to run stuff with is pretty hard these days thanks to the RAM-pocalypse.
However, as I get closer and closer to getting in the market for new hardware, it seems to me that it might just be better to transition my current machine into a dedicated server piece by piece, by running certain workloads in the background.
That way, when I’m 100% ready to jump ship, I really only need to migrate my personal docs out of this computer, disable desktop apps etc, and then leave most of the other services running as-is (most of this is trivial with NixOS btw).
While new machines these days are pretty fast, my current Thinkpad with a mobile Zen 2 AMD processor is still no slouch, and I get through my days feeling the machine is still pretty snappy all around.
This is a small slice of what I’m currently running, some historical background for stuff I’ve run in the past, and what I’ll be looking into running once this current machine no longer is my primary.
While I don’t self-host Tailscale (yet?), it is the underpinning of my entire self-hosting journey. By allowing me to forget about managing Wireguard keys, as well as hole-punching through NATted home networks, I can (for free!) have an internal network I can securely access from virtually anywhere in the world from an Internet connection that (at minimum) just needs to have a decently unrestricted TCP port 443 (and on most networks I have seen, even mobile networks, I usually end up with a direct connection!).
I historically use a Raspberry Pi Model 3B+ to run small services. I started out using Raspbian, then Debian for a decent while to keep running. However, this Raspberry Pi setup was not exactly ideal:
I don’t have a microSD card anymore, so I boot the Pi using a very old 4GB USB flash drive. Flash drives aren’t great for this, and the older the flash is, the more the chance of failure. I suspect the flash drive is already halfway to death, which would explain why:
After having run Debian for a year or so on the Pi, I found that at some point, the install would just “corrupt”.
Because of these reasons, and the fact that I was mostly physically away from my Pi at home (due to attending college in a different state), I never bothered to run anything too stateful on the Pi. I tried putting NixOS on it, but a combination of my inexperience and the slow feedback loop put me off of it.
Then, one day I luckily found out about gokrazy from Xe Iaso’s blogpost. The set up is perfect for this usecase: I could pre-configure all the services I want, bundle them into an image, and boot from USB.
Once I was done, I would have an OS built out of the Linux kernel + Go-based services making direct Linux syscalls + a web interface to manage services/view logs. No SSH, even! It was arguably a more secure and clean setup than using Debian.
I am happy to report that after having made the jump, I have never run into a situation where the Gokrazy install was to blame. The few times the node has been offline, it was either that I forgot to mark the Tailscale auth key to not expire (and then it expired, leading me to re-authenticate), or the Pi was just disconnected from electricity.
There are basically two use cases for the Pi currently (long-term, I plan to still keep the Pi around for running more stuff through gokrazy, as a way to save resources, ie, lightweight non-sensitive services can go through the Pi, and stuff that needs more horsepower can run on my laptop):
Blocky is a simple Go-based DNS adblock, similar to Pi-hole. I decided on using Blocky since using non-Go based programs with Gokrazy is a bit more convoluted, and the stateless design was a big plus in this situation. I still don’t use this across my entire home network, but rather just confined it to a smart TV to block ads on it. I had to spend some time adding a custom block list for a certain OTT platform that has mid-roll ads in between content, until I was able to make those go away, and this was mostly done through inspecting the logs for suspicious domains and adding to the block list to see if it didn’t break anything except the ads.
I plan to expand the block list further and roll it out across more of my home network.
This was the original way I got into Tailscale, and what I used it for even back in the old Debian-on-Pi days.
See, when I lived out of state, I still wanted to be able to play on the PS4 at home. Sony’s official Remote Play app was Windows/macOS only, and was not very well-respected, but there was Chiaki, a reverse-engineered open source version that was even available on jailbroken Nintendo Switches (nowadays I use chiaki-ng which even has a nice UI for PC handheld users). While chiaki-ng even supports using Sony’s routing servers to connect to your PlayStation console from other networks, at the time, I was using the original chiaki, which did not have this. Also, it seemed to me that it might be more efficient to directly try connecting to the console rather than go through some intermediary, which led me to Tailscale.
My setup was thus:
The local network route advertisement allowed me to connect to the PS4 on the home network through the Pi, or really any device on my home network. So, the route was roughly:
Laptop ———– 50-60ms ————- RPi — 0.5-1ms — PS4
This allows you to interact with any machine, even if it doesn’t support Tailscale, by using the closest Tailscale supporting machine as a proxy.
As highlighted above, this got me a 50-60ms latency on my college network on a good day, although there were more bad days than good. It was enough for me to beat Star Wars: Jedi Fallen Order almost entirely over this setup, though, and beat a Berserker in God of War: Ragnarok.
I have already talked about Hister in a previous post, but I have shifted over to the normal flow as well for indexing web pages I visit as well.
Migrating my existing index took some noodling, but was ultimately
successful. I earlier ran the Hister daemon through a Docker image
manually and volume mounted the state directories it needed. In order to
shift to a sandboxed systemd service (which used a dynamic user), I
copied the state directory contents and chown’d it to root
(or nobody, it was either of the two). systemd would take care of the
rest. Once I verified the index was properly accessible to the new
service and I could add more links, the migration was complete.
Thanks to Tailscale, I can connect to Hister using my phone (which is also on my tailnet). This way even if I am away from my laptop, I am able to save articles and web pages I find interesting into my own personal search engine, and can refer back to the links at my own desire.
The only drawback with this initial setup was that because this was an HTTP connection, the Hister extension on my phone would initially fail to connect and threw a NetworkError.
In order to work around this, you have to make a normal request to the Hister service (ie, make a search using the search engine), at which point there will be a big warning about connecting to an “insecure” website. If you continue on, Firefox will remember that decision for the extension as well and allow it to make requests over HTTP. However, I solved this problem (see below for details).
This is an experimental small CalDAV server written in Go (see the sourcehut repo). I wanted a way to keep important dates etc to myself rather than save them to Migadu (an email service that I otherwise 100% recommend to take charge of your email identity) but also have a way to see them on other devices.
I chose it mostly because it seemed simple enough to set up, didn’t have too many moving parts, and was Go-based.
Tokidoki did not have a Nix package/service definition, so I used the prevalent LLM at the time I first started using Tokidoki (June 2025), perhaps Sonnet/Opus.
However, I am beginning to think the software is abandoned, as development has been stale for over a year. It might be time for it to be forked and kept maintained at the very least with latest dependencies. I am fairly happy with the feature set offered.
Tailscale offers an HTTPS certificate (backed by a subdomain of ts.net, although this exposes your tailnet name) that you can use to get around higher OSI layer applications from complaining about the unencrypted connection. This is all managed by Tailscale themselves, and you don’t need to do any manual/set up any automated steps to renew the cert either!
In fact, tailscale can also set up a reverse proxy for you and run it
automatically when you do a tailscale up. See tailscale serve
for more details.
Using this, both my Hister and Tokidoki instances are HTTPS-protected, so apps don’t complain about the “insecure connection”.
For my usage, I merely did
sudo tailscale serve -bg --https=<port-to-expose> localhost:<port-which-service-runs-on>
and the rest is history.
Right now, this whole set up is entirely designed around one single user: me. That means I have very little authentication set up here, and the main security boundary is Tailscale itself. I don’t worry too much about this, since there’s very little (if any) way to reach from somewhere on the Internet to my machines, thanks to NAT. If I want to open this up for more people to use, I might look into adding some authentication layering, but that is a topic for another day.
Exposing services only over Tailscale has one huge benefit: I can trust my tailnet (ie, the Tailscale network). All of those devices are managed by me, and nothing else can really talk to those machines. Tailscale even has a tailnet lock feature which prevents a device from being trusted until a pre-existing device vouches for it, so trusting Tailscale-the-company is also not required. On top of that, there is Headscale which allows you to run your own Tailscale control plane, so I don’t really even need to rely on any of their infra if I choose to put in the effort.
At this point, there’s almost zero interest in me to look into hosting something other than this blog on the public Internet, because I can just run Tailscale on my phone etc. and virtually not notice the difference between a website hosted publicly and something served over Tailscale.
Tailscale the service is also something I have sandboxed, and it also doesn’t have access to my data, although it does still run as root (which is something I want to try changing again; the last time I tried the service broke).
Note: while this might sound a lot like I don’t really subscribe to the “zero trust” mentality, that isn’t true. Zero trust networking is a sound idea, but for my threat model, it is overkill. For billion dollar businesses, not so much. I could choose to tune some stuff up more and get a far more secure system, but until then, I am fairly satisfied with the security on hand.
The only service storing anything private is Tokidoki, and I have
that configured to only listen for connections on two interfaces:
localhost and Tailscale. That way, any connection coming to my machine
from, say 192.168.1.1 (maybe a compromised router?) is
rejected, by the powerful machinery of my computer’s firewall. This is
also the case with SSH, ie, I can only SSH into my machine over a
Tailscale connection.
Most of these services are also sandboxed using systemd and run as their own different user. That way if there is some exploit that lets someone take over one of these services, there’s practically no user data (besides the data the service owns) for them to exploit.
If you want to learn more about how to secure and run such services yourself, feel free to take a look at my NixOS config, which has configs for all of these services.
Again, I can’t stress this enough, this is designed around the fact that Tailscale is a pretty well-designed service, I can restrict what devices are on the network well enough to make sure nothing leaves any machine without my consent, and I am running all of this just for my own private usage.
Like I mentioned earlier, I’d like to self-host more stuff and lessen my dependency on externally managed services. I don’t want to self-host everything just yet, as every service adds a burden on me to keep up with any changes (although Nix lessens these, it is still not free to run stuff on my own and keep it updated), but if I can move some critical stuff off of the public Internet into something I can use privately, that’d be a big win.
Immich: I have heard in my circle how Immich can replace a lot of need for Google Photos etc, even if it might be less “smart”/AI-enabled. Not paying for cloud storage ever sounds pretty great, and so does keeping my and mine’s photos out of anyone else’s hands. Thanks to the AI-pocalypose, however, I think I’ll need to keep this one on hold until I can get enough storage.
Some small LLMs I can use to analyze private documents etc. One use case I am running into that commercial LLMs are a bit dicey on is to help me interpret certain documents/wordings. From my current testing, it seems like a 4B-ish class model would run fine enough on the CPU (and some layers offloaded to the integrated GPU). This won’t really be beating any big models on benchmarks, but if I think it justifies the resource usage, it might be something to keep around. Ideally, this type of workload could be managed by a Mac Mini or a Strix Halo-based device, but I don’t really have access to those, so whatever I can run on current hardware should be good.
Hister crawler: I plan to create a service that can take newly seen domains in hister and try crawling them periodically. This would make Hister less of a bookmark service on steroids and closer to a Small Web index, seeing as most of the links I save are to niche software/tech blogs than most big websites. Perhaps Hister could be responsible for fulfilling more and more of my search requests, and allow me to rely on external search engines less?
If we combine this idea with the fact that Hister has an MCP server, and that a 4B-class LLM is getting better and better as competition increases in the open weight LLM category, it is not inconceivable to think that I could self-host an LLM assistant that is almost entirely reliant on self-hosted infrastructure, and may be of a similar quality to quick, summarized search results from popular search engines, complete with a nice web UI and saved chats to boot.
Self-hosting is a fun hobby to try out. It might also just consume me.
This website was made using Markdown, Pandoc, and a custom program to automatically add headers and footers (including this one) to any document that’s published here.
Copyright © 2026 Saksham Mittal. All rights reserved. Unless otherwise stated, all content on this website is licensed under the CC BY-SA 4.0 International License