For a long while, especially when I first started with a home lab and self-hosting services, my answer to everything was to self-host it. This mindset I think can serve ones well, even if it doesn’t necessarily make sense for all services since it can teach you a lot about networking, storage, virtualization, firewalls, backups, containers, and the list goes on. However, for me, somewhere along the way, I realized something important. That is that not everything should be self-hosted at home. This is not a rejection of self-hosting, but rather, I realized that some services don’t really add value to your stack by self-hosting them. Let’s look at what services I stopped self-hosting and why cloud hosted services made more sense for these.
1. Email
A decade or more ago, self-hosting email was one of those core services that felt like it was a rite of passage to self-host and gave you total control over messaging. However, fast forward to 2025, and email has become absolutely asinine with the requirements that must be met to make sure your email is delivered.
Now, due to how bad SPAM emails have gotten, you have to worry about DKIM, SPF records, reverse DNS, and IP reputation. Many ISPs will not allow you to pass port 25 traffic unless you have a “business” grade circuit. So consumer or residential Internet connections are filtered. Also, some domains that you try to deliver to may even have more requirements than the ones we have already listed.
With all these requirements, restrictions, and limitations, the cost-benefit for me broke down. Email is not just another service. It is a constantly moving target that can quietly break delivery without obvious errors.
This may not be the case for everyone, but for me moving email to a managed provider that email is all they do was worth it. No more troubleshooting sessions on deliverability or why certain emails get tarpitted vs ones that don’t. For me, it was one of the best decisions on a service to no longer self-host.
This is an oldie but still a goodie post I did a few years ago on how to install SMTP on your Windows IIS server and run an internal SMTP relay: Add SMTP Windows Server 2016.
2. Public DNS
I thinking running your own DNS services is an awesome learning experience. DNS is and has always been facinating to me. I definitely think self-hosters should always self-host their own internal DNS as it allows you to do so many neat things you can’t do otherwise. But public DNS is a different story.
You can run your own public DNS servers for externally facing services. However, this comes with its own set of challenges. DNS for externally facing services is what things like certificates rely on, APIs, monitoring, etc. Even if your services are healthy, if DNS is down, they might as well be down as external services won’t be able to find those resources.
I eventually moved my public DNS to a managed provider like Cloudflare. This was not because I couldn’t run it myself, but because I didn’t want a power outage at home or ISP issue which does usually happen a couple of times a year to take down my public services.
My internal DNS for my home lab continues to be self-hosted. For internal clients, I use a split horizon zone to resolve even public records for certain services locally instead of sending those queries to the public DNS zone. This allows me to have even more control over name resolution.
Check out my recent DNS related posts here on internal DNS solutions that are awesome:
- Stop Using Pi-Hole Sync Tools and Use Technitium DNS Clustering Instead
- I Now Manage My DNS Server from Git (and It Changed Everything)
3. Remote Access Gateways
I think most of us when we first established a home lab got excited about running our own remote access gateway solutions. These include things like WireGuard gateways, OpenVPN, multiple entry points, etc. Running your own firewall rules and failover logic between them.
However, after not a lot of time had passed and I had a couple of machines in the DMZ that I was running that got popped, I realized that it didn’t really make a lot of sense for these types of services to be self-hosted as the security risks and other vulnerabilities were just not worth it. Also, today, I think the zero-trust landscape has evolved to a point where we have so many great solutions out there for zero-trust access, this is absolutely the way to do it with modern home labs.
The benefits to this type of approach are endless. When you use a zero-trust solution these typically require no firewall ports to be opened. So, you are not having to open up a hole in your armor so to speak. Also, honestly, the experience with these types of solutions is better as well. I love services like Twingate and also self-hosted solutions that work very similarly like Pangolin.
Read my posts here:
- Why Pangolin is the one reverse proxy I’d pick if I was starting my home lab today
- Stop Exposing Your Home Lab – Do This Instead
4. Push Notifications
Push notifications is another service that I no longer try to self-host. I love notifications when they work and are useful. I hate them when they are fragile and down most of the time.
Self-hosting your own push notification stacks can be extremely complicated. These require certificates, mobile platforms change their requirements. Gateways can silently break. Apps can then stop receiving messages without any errors that are obvious.
At a certain point, I realized that I was maintaining the notification system itself more than the services it was meant to notify me about. That I thought was backwards to what I wanted. I needed notification services that were reliable and that simply work. Alerts need to arrive when they should. If they fail, I don’t want to have to be debugging this at midnight, etc.
I now use something called Mailrise along with pushing notifications to my Pushover client. Check out my full blog post on that here:
5. Password Managers
This is one that I may get some flak for listing and that is self-hosted password managers. Don’t get me wrong. I think self-hosting your own password manager is extremely cool and there are some great projects out there that can do this very effectively. However, for me, the risk in doing this was just too great.
I have TONs of accounts that are part of my current password manager that span all types of services, apps, and other resources. Having the possibility of losing all of these entries by something catastrophic happening in the home lab was just a risk that was too great for me to take on for self-hosting. It is just next to impossible as a self-hoster to have the resiliency and high availability of cloud password managers.
I also like the thought of splitting out lab specific and home specific resources and having these only hosted in your home lab and having a cloud password manager for your other resources. You just have to make sure that you don’t paint yourself in the corner with a “chicken and egg” scenario of having passwords you need to get your home lab back up and and running after a failure, but you can’t get them back up and running because your password manager is down as a result.
Stress and time are the metrics to pay attention to
This may seem a little abstract as a statement to make, but if a service takes away more time (troubleshooting, things break, etc) than it really gives back in terms of value add to the home lab, this is a signal to me that it might not be the best fit for self-hosting as a solution that I want to take care of and management.
Also, if a service makes you uneasy every time you leave town, that matters. If you dread to update it because it might break and you know you will have hours of time invested to get things back up and running, that is also a signal.
I stopped self-hosting anything that caused more stress than the value add in learning or enjoyment or value add that it can bring to the table. The line here is different for everyone. For me though, it is the most telling metric I have when it comes to deciding whether or not a particular service is worth self-hosting.
The services that I happily self-host
Even though I have let go of the services mentioned in the post, it doesn’t mean I am no longer serious about self-hosting. I am running more solutions now than ever before in my home lab. I love to self-host core infrastructure, storage, internal DNS, identity services, reverse proxies, logging, AI tooling, and DevOps platforms. You guys see a lot of the services, apps, solutions, and other things I write about.
These are areas where for me, the learning, control, and flexibility still far outweigh the operational and time cost of self-hosting them.
Wrapping up
The great thing about self-hosting is that it is kind of like how we describe home labs in general. These are not a “one size fits all” solution. Self-hosting can be tailored to your individual needs and what works for you. Knowing when not to use a tool in a self-hosted environment is just as important as knowing when to self-host a solution or app.
Giving up control to the cloud or a SaaS solution in my home lab in a few strategic places made my home lab more reliable, more enjoyable, and less stressful over time. It also has freed up time for me to focus on the parts of the home lab that excite me, such as trying new projects and solutions. Long story short, your home lab should work for you, not the other way around. Hopefully this list of things i stopped self hosting might get you to thinking as well about some services that might be worth giving up in the home lab. What about you? Have you recently stopped self-hosting a service? Which one? Please share your thoughts in the comments.
Google is updating how articles are shown. Don’t miss our leading home lab and tech content, written by humans, by setting Virtualization Howto as a preferred source.
About The Author
