 Hello, everyone. Welcome to root cons. It's early morning, and I'm Nemo. I'm going to be talking about running my own home server. I do tech and security things at RazerPay, primarily around infrastructure security. But while we'll be spending the next two days talking all about running enterprise-grade infrastructure, if you want to start this conference on a more personal note about how and why I run my own home server. So to start with, this is the broad agenda for the talk. I want to go around what counts as a home server. I want you to tell I want to tell you why you should be running one, how do you get started with it, and a few gotchas around if you decide to actually run this. And finally, we'll have a call to action so you can actually go ahead and do it today. So to start with, what counts as a home server? When I started this journey two years ago, I had different reasons to visually own my data. I believe that the concept of digital ownership today is very, very important. And giving corporations all your data doesn't sound very nice to me. So that was one of the reasons I started it. And I believe if you personally want to run your home service, any computer that runs a service for personal use counts as a home server. It doesn't necessarily have to be an actual Dell server. It could be something as simple or dumb as a Raspberry Pi. But any computer that runs a personal service that is run by you and managed by you counts as a home server. So why would you want to do it? This is the starting question. And I believe these are the different answers that you may have for yourself. For me, there are different motivations. The primary motivation being owning my data. As I earlier said, I believe digital ownership is very, very important. If you currently, how many people run Gmail? Primary email on Gmail, personal. That's almost everyone in the audience. The second thing I wanted to do was be Google my life. I realized I had a lot of content on Google and I don't think that's the right thing to have at this point. Especially, I'm being paid to run my own infrastructure, my company's infrastructure. I wouldn't be a very good infrastructure engineer if I can't manage my own personal infrastructure. So I believe I should be running my own infrastructure. The third was I had this requirement of backing up some of my data locally. I had lots of photos, lots of videos, lots of movies that I wanted to keep locally on my server instead of storing them on the cloud. And I wanted to keep a local backup for all my content and follow the three to one rule of three local copies, two remote copies and one off-site copy. I also wanted to learn and experiment with tech. I want, this was primarily Terraform and Kubernetes for me when I started two years ago. We were migrating across Kubernetes. We were starting out using Terraform across our organization and I thought, hey, can I use these things at my home as well and maybe they'll help me get better at work as well. So it was a nice mix of, in fact, the tools and things that I use at work correlate nicely to the decisions I took at home as well. And finally, this was a very important criteria for me. I wanted to play Mario at my home. You'll realize if you own a PS3 today or an Xbox, it's become really hard to play Mario. And I wanted to get back that feeling. So this is actually where I started out by playing Mario on a simple Raspberry Pi. As with all personal projects, you'll realize things go out of scope and you realize, hey, this is a new shiny personal project and you keep moving on to other things and you'll have other new personal projects that you want to devote more and more time on. And it happens with everyone. So to set a healthy boundary for myself, I said, hey, I'll put a cap on the amount of time I'm going to be spending on this infrastructure. This is not work. I don't want to deal at an outage at work and get back home and deal with another outage at home as well. So I'll limit the amount of time I'll be spending on this to somewhere around five hours a month. It may go up or down if I'm setting up new services or migrating across things. But roughly I try to keep myself to the goal of one hour or so per week. What this lets me, gives me is a healthy boundary in terms of, hey, I'm not investing too much time and this doesn't feel like work. It should be fun. This is how my home server looks. It's a fairly simple dump PC. It runs a mini ITX motherboard, which means it's a much smaller form factor than all the tower desktops you may have seen. This is how it looks currently. Sorry for the potato photo. The two UPSes next to it, but still best com doesn't, it lets me belong quite often. So the next few slides, I want to walk through the software, what I run, what you can run, the hardware, what kind of choices you should be making, and finally the glue that will hold it all together. So this is a list of services that I run, starting from monitoring. I run Prometheus, I run Grafana, which are also the same services I currently run at work. It's fairly easy when you have the same configuration or pretty much a similar configuration style to use at both at work and home. And you don't have to worry about learning brand new tech. Alongside this, I run this thing called a speed test exporter, which gives me immediate speed test results for how ACD-5.9 is performing at my home. I run, I wrote something called ACD exporter, which also gives me details about how much bandwidth usage I have used throughout my month. This is how it looks. So for example, this is screenshot from a while back. My current usage today is somewhere around that. If you go to grafana.vba.fun, you can actually look at the dashboard and play around my data visualization over time. Finally, run CAdvisor as well, which gives me metrics around the containers I'm running, the memory usage, and the CPU metrics. So what are the services? I run a few media services, which include things like ASONIC, Jellison, all of these are basically self-hosted versions of media services that you can find on the internet. I end up stripping DRM from the Audible books and the Kindle books are by to host them locally. On the content side of things, I run a lot of services from NextCloud, which is the one primary thing that I would recommend to everyone. If you want to get started, NextCloud is a great starting point because it acts as an alternative for your Google Drive, your Google Docs, Dropbox Sync, Google Calendar, and it lets you run your own contact server and all of these things together. And it gives you, for example, even things like automatic photo sync. All of these things together make NextCloud a very good starting point. You just run it and you have an immediate switcher point from taking your digital ownership back. I run Miniflux for RSS feeds. How many people here remember Google Reader? Next, since Google decided to kill RSS, there are still a few of us who are trying to keep it alive. Miniflux lets me subscribe to websites across the internet that I follow. And read them at my own leisure. I run Time Machine for backups, which lets me do encrypted backups of my MacBooks, which I have multiple at home. Apparently for my calendar and contacts, I'm running this tiny small app called Radical. It runs a CardDAV and a CalDAV server, which basically lets me sync all my contacts to my personal server instead of sending them across to the cloud. And a few other services, for example, I run Giddy. So the talks for the slide and the code for this all of my home server is hosted on the server itself. So what hardware? Say you've decided, hey, I want to host next cloud. Maybe you want to play a few games. Maybe you've decided, hey, I'm going to run this specific media server. How do you go about picking specific hardware to run it? This is what I run, the DumpSymbl Intel CPU-based system. I also run a DigitalOcean server on the cloud, currently running in Bangalore region, which basically means it's across the city at Electronic City. I primarily use it for services that I want to always be up. I also have a 90B rate five hard disk configuration at home so I can keep backups across multiple disks. So let's see, you want to start this. A great starting point for hard disk. A great starting point for hardware would be getting a simple dumb VM on the cloud. It doesn't cost too much. There are options available from aslo as 350 INR across Scaleway, across GCP, RZR, or DigitalOcean, which is what I use. It works great. However, one thing you must be aware of is the persistence storage cost. Storage costs don't scale across cloud providers and it's much, much more cheaper to own your storage than to host it and rent it from the cloud. Another thing I want to mention is the security footgun, like how AWS says you have a shared responsibility model for managing your own security. They will give you the tools then, but you'll have to ensure that services that you run and the networking that you set up, security groups, for example, are correct and valid to ensure that your services are secure. It also comes with batteries included. So for example, if you do end up wanting to run a separate Postgres server, you can do it much more easily on the cloud. And finally, the optics costs are much more lower. You don't have to go and buy, I think my build costs somewhere around 30 to 40K when I started and you don't have to invest all that money upfront. You can just rent something for 250 INR a month to start with. So as I said, on the cloud storage side, if you actually have a lot of content in terms of media or photos that you want to store or backup, storing it on the cloud may not be cheap. These are prices for EBS volumes. You wouldn't necessarily use EBS volumes, but depending on your use case, it may or may not be possible to use something like S3. So for example, when you have storage, you'll keep getting diminishing returns in terms of what you get on the cloud. However, if you do decide to actually buy a hard disk and put it locally within yours, at your home, it's much, much more cheaper. The cost for retail, for example, at 3DB are $224, while it's almost the same price of $300, you just rent it for a month from AWS. You can get much cheaper price elsewhere, but negatively, it's still going to be diminishing returns. Another great starting point is just a Raspberry Pi. If you haven't tried it, it's great. The current model comes with one gig of RAM. Works great. It does do HDMI as well. You can watch movies. It does X264 1080p videos today. And finally, it also comes with GPIO pins. So if you are the electronic stinking kind, you can go ahead and use it. A few other alternatives are things like System 7. This is Xmefcat, which is like a small, tiny home server that you can run locally. It's an Intel i7 machine, fairly powerful, but similarly, there's Intel NUC, which is also the quite similar form factor device. The problem with these small form factor devices is the upgradability is always a concern. You can't push, put in PCI Express cards, or there'll be certain limitations in terms of how much storage, how many storage space can you have in such devices. You can also look at Hetzner server auctions. If you're okay running your home server in Germany, Hetzner does these device auctions where they'll auction off US generation hardware. And while they're not great for commercial usage, they're perfectly fine for non-commercial and personal usage. So you can just get them off at $30 to $50 a month or so. And it comes in with enough storage, enough compute for most purposes. You can also look at trying out a NAS or a networking device. So you can get, for example, a Synology or a Seagate NAS. While it won't have enough compute, it'll have enough storage. So if your primary use case happens to be, hey, I take a lot of photos, I shoot a lot of videos, and I want to back them up. And I may also want to host a few other services, like maybe a calendar or a contact sync. Looking at a free NAS device may be a viable option. You can run a network storage. You can back up your own things. And while it won't let you play games, it'll have enough leeway to do a lot of things. And finally, if you plan to play games, which was one of the primary use cases for me, I wanted to play powerful games. So go to the PC Master Race Wiki, which lists out really, really great builds that you can do. One thing that you may want to look out for if you're running Home Server is the power wattage cost on these builds. So while getting the highest and the greatest graphic card can build my great idea, it may not be a good idea if you're going to be running your computer 24-7, which is how your Home Server will function. So, and you can actually go wild. If you have some old laptop flying around, you can just use them as your Home Server. If you have old networking device that your company is no longer using, maybe buy them off cheaply, use them at your home, set it up, and play around with it. If you want to try out setting up your own Kubernetes cluster locally, starting with a couple of Raspberry Pis is a great way to do that. It's not natively supported in Kubernetes right now, I believe, but there are unofficial builds that do work. With all this said, there's this specific model that I want to go on a little bit more, which is the hybrid way of doing your Home Server, which is currently what I do. You want to have, because as I said, storage is going to be costly to run on the cloud. So you want to have something with the local storage site on your home. So a simple Raspberry Pi connected to a disk, set up a VPN across the cloud to your EC2 instance. So you can run all your costly cloud computations or any service that requires a high compute that can't run feasibly on a Raspberry Pi, or for example, needs to run 24-7 with higher uptime. You can run them all on the cloud, but anything that does require disk, you can mount the disk across the VPN. It'll be slower, but it will work. So as a summary, it depends on which model that you would decide to go with. You can go with a cloud model. You can go with just setting up a Pi or NAS device or picking up a hybrid model like at it. The pluses are great. More pluses are better if you see money. Emojis, it's possible, doable, but it will cost you a lot of money. For example, with the cloud, you get decent security built in. You have great utility. The ease of setup is much lower. It's still decent, especially if you're used to cloud infra at your work. You can just pretty much use Ansible or a data form or whatever things you are using at work. Storage costs are higher. You pretty much won't be able to gain. Setting up an HTPC is possible, but HTPC here is a home theater PC, but it will likely cost you money because of media storage costs. If you decide to go ahead with a simple Raspberry Pi, it will work for most use cases. It won't have a lot of compute in it, so you can't run a lot of services, or if you decide to watch a movie, your services may suffer. The Opsies is also limited because of the ARM platform support. A lot of services that I run, not all of them are available as ARM containers currently. You may only get AMD64 builds and have to cross compile it yourself. It works with the gaming side as long as you're limited to retro gaming and playing games from the 80s and the 90s, but it won't play any modern games. If you go with a hybrid model, it could all around, but the setup ease and the Opsies are slightly harder, but these are mostly one-time costs that you need to pay upfront in terms of setting up the infrastructure and the VPN once, but those will work out down the line. That's the base solution. The only things you need to look out for are utility and gaming, because while NASA will work great for low compute use cases, if you have something that requires intensive computation, or if you want to play games, that won't be possible. We have a general idea of what you want to run, what you can run, what hardware you need to get, or what computer model you should go with, or on the server. What comes on the glue side of things? How do you actually tie it all together? What I currently do is simply set up Docker and Terraform together, which lets me control all my services as simple containers, but the most important point that I want to make for the glue part is ensure you pick something that's dumb, simple, and you understand well. Don't go crazy and use this, use your home server as your first free BST build, if you don't haven't used it before. Don't switch operating systems, don't switch your orchestration platform completely. Make sure it's something that you understand, be it Ansible, be it Chef, be it puppet, don't hand roll your own server either, don't make sure you're using some sane configuration management tool to roll out your changes. Two other things that I want to mention are Android and Home Lab OS, which are basically simple operating systems that do Android does virtualization and disk storage really well. So if you're the media storage kind, Android works really well. It comes with inbuilt support for a lot of different services. I believe Home Lab OS is currently at 60 plus different services supported natively. You install the operating system and it gives you one click option to enable calendars, media storage backups and all a whole bunch of different services of all sorts. But yeah, if you want to set this up, pick something dumb, pick something you understand, pick something you've already used before or pick something that you think will be helpful to you in the next two years because you don't want to pick something that's too arcane, it'll cause you a lot of pain down the line and you'll definitely go beyond your five hours per month budget. Another thing that I would recommend is picking containers by default. Make sure if you're not able to run a service as a container, it won't run it. It's not worth the pain. I currently am at 35-ish services and 35 includes all the databases as well. So maybe 25 services and 10x auxiliary containers. But running all of them with containers has been so much easier than it would have been otherwise. I don't have to worry about dependency management, I don't have to worry about packages and it generally makes life much more easier. I can just write my configuration as code and read much more easily. Having declared configuration for containers be it in terms of Docker Compose file, I currently use Terraform for writing my Docker Compose file and it generally makes orchestration much, much more easier. If you're not already using containers at work, this is what I would still recommend. It's starting point as well. A little note on the networking site. The first primary problem you'll face if you decide to buy a Raspberry Pi today and you say, hey, I've set up my Pi, I have my d-school services and I want to expose them and use on my 3G network on my phone. You want to do calendar sync from your home to your phone. The primary problem you'll face is most ISPs in India do not give a public IP address. They will net you behind the firewall which pretty much means your servers are not accessible on the internet. The way I get around it is the hybrid working model where I set up my IP address on the VM that I'm running on digital ocean. It's not the only way of doing things. If you go and talk nicely to your ISP or if you pay them enough money, they will actually give you a public IP along with possibly a static IP as well. But talk to your ISP if you think that you will be running a little bit more compute than just a Raspberry Pi or if you think you may be switching ISPs down the line, then it may be worth it getting a simple $5 VPS anyway. Another suggestion is to actually set up a VPN on your home server. A lot of the management info that you run for example, I don't promise you, which doesn't come with auth by default. And I don't want to expose it over the internet at all. How do I manage it? I currently only expose it on my personal VPN network. So I'm able to access it over my laptop and if I'm still traveling I have a way to access it for the VPN but it's not accessible directly over the internet. Finally, set up a wildcard DNS offer services. I currently run star.bba.fun which is the smallest little domain that I could find. But you can pick a simple wildcard domain. What this does is makes it easier for you to set up new services and setting up wildcard tls also the same thing. At the start I believe when I started out I added 10 services across the first week or so and I ran a file of Lex encrypts rate limits because every service that I added or removed was resulting in a new certificate issuance. It's much more easy to do wildcard tls especially this is your personal infrastructure you're allowed to do. Yeah on the diagram side this is a simple hybrid model that I already discussed but running a VPN makes it much, much more easier way to run your management infrastructure on just the VPN my current infra involves running traffic and Docker alongside traffic if you haven't used it is a simple dump HTTP router that can auto discover services depending on whatever you are running. So if you're running Kubernetes or auto discover Kubernetes services, if you're running Docker it'll auto discover Docker services as long as you provide certain annotations or labels or tags to it. So traffic for example will route any traffic that goes to media.bba.fun to the appropriate container internally. None of these services are exposed directly to the internet. The connection happens only to the disk lotion template I have which pipes it across for the VPN. I also have a more confusing diagram which points out how I do the SSH part of it ensuring that SSH is you have a way to SSH into your containers to your host alongside that you want to ensure I run GitE which is a Git server which also supports SSH so I have another port mapping for that as well. Finally on the security part if you're running this these are publicly exposed services I currently run 20 plus and these are services pretty much which you have no control over. If you find a security issue you can point it out to the person but you have no control over the developers who are writing these things. So rule one is run everything in isolation which is why I recommend containers highly. You can set up CH routes or Jail as well but I would prefer containers. Don't expose services by default. Make sure the default should be not to expose anything on the internet. If you're going ahead and exposing it any which way if it's a management service like Prometheus or your Docker, I run the Docker daemon as well make sure those are exposed only over if you're exposing other services make sure they have an authentication system behind them. Don't expose your photo servers across to the internet blindly without setting up first on it. So this is a general workflow I follow every time. Make sure I first set up the service don't publicize it on the internet test it out, make sure it stays secure set up an auth on it. If your service natively doesn't support auth which is the case for many things like for example Prometheus you can set a basic auth on it by on the engine X layer traffic by default supports it with just a simple annotation which is what I currently do. And finally go hybrid it gives you a level of isolation in terms of their services are hosted and where they are proxied through and you can use it if you want to in certain cases. So yeah, this is the final CD for the talk. If you're interested in that I've managed to convince you today to actually own your data and run your own server so go ahead and buy a Raspberry Pi today. It's a great starting point. It comes and runs Linux by default. It runs a variant of Debian called Raspin has enough packages in it you can set up what things like next cloud with just sudo app get installed next cloud it's a great great great starting point I would highly recommend go ahead buy a Raspberry Pi it costs less than 3000 and a few slides hosting references if you decide to go down the path. The first is the awesome self hosted repository on GitHub. There's a huge huge huge collection of all the personal services that you can run starting from how easy and simple can it be to run your own mail server from various different configurations to running your own VPN to running your own calendar server etc. They have a huge list of applications of possibly with containers you can run. The second is linuxserver.io it's a community effort to build and publish regularly updated container images for various self-hosted software. So for example next cloud has a linuxserver IO image as well which you can use instead of the official image. They're pretty well maintained much lighter than the official images in many cases and in many cases if you don't find an official image for something it's very likely that linuxserver has an image for it. There's also a Reddit community called r slash self hosted where people discuss how to set things up from setting up simple configuration around Terraform or Docker or how to manage containers or how to set up unread for example. Yeah, that's it. Thank you. There's slides on capnimo.n slash talks. I've also written about my home server journey on my blogs if you're interested in reading the whole thing and how the actual tech behind it works. The code all the blog posts are at capnimo.n slash archive. That's it. Thank you. Questions. Please raise your hand if you have any questions for the speaker. Okay, so this is obviously a lot of trouble you've been through to set up your boxes and the first thing that strikes me about running a server at home is you got an ISP that's netting you so you can't talk to the outside world it's a lot of pain. You got power cuts. You got two UPSS to keep the beast alive. Is it worth it? Why don't you just pay for posting in a data center somewhere in the city itself? That's a totally feasible choice and which is what I recommend as well. If you run with a hybrid model you want to keep most of the compute and most of the services that you want decent uptime on towards the cloud side but at the same time if you want to have a local available version of your media backups for example I want to have artists that I can carry around if I want to. Running it locally is a much better idea. Any questions? That's it. Thank you.