Own your infrastructure

Like many in the software development industry, I find Heroku to be an amazing product. It was so ahead of everything else at the time, it was unbelievable. It certainly made things a lot easier for me when I was starting out as a developer by letting me avoid all the pains of handling servers. Clients appreciated it and I had no worries that something would go down. Managing deployments manually was tough, and still is. That is if you don’t containerize your code with Docker or the likes of it.

Now, I’m not a professional DevOps guy. That is I don’t do it as a full-time job. However, I had to set up things too many times at this point, and I know that different team sizes, and tech stacks require different tools.

Worth noting that by developers in this piece I primarily mean solo developers. Bigger teams require a different approach. Most early startups would fall into solo developer category though.

Dokku

When people grow out of Heroku, the first thing they usually find is Dokku. It’s a simple way to manage Docker containers without messing with more complex configurations, and it’s more than enough for most solo developers as the majority of apps and websites don’t get enough traffic for it not to enough.

A few steps:

  1. getting a server from Digital Ocean, Linode or AWS;
  2. initial set up of said server;
  3. one simple script from the Dokku website;
  4. in your repo: git remote add dokku $server;
  5. when deploying: git push.

And that’s it, a replacement for Heroku.

In years of service, Dokku has never failed me. Sure, there were edge cases but those were resolved quickly using the project’s Github issues.

A case against external services

Even though there are popular platform-as-a-service solutions like Vercel (Zeit) and Netlify, I believe that developers should self-host their apps more often than not.

  • It would help you understand a lot more about Unix systems, server infrastructure, and network.
  • You would gain a product advantage, given you have an edge case that you most likely will, eventually.
  • An external service puts you in a place of total dependency. Historically, these services have had a lot of changes. Sometimes, breaking changes. You don’t want to be in that situation.

I’ve used all of the services above. To state the obvious, it’s a good deal for most developers even though the pricing is higher. Why? Because managing servers ourselves is time-consuming and error-prone if that is not your main activity. You don’t want to wake up in the middle of the night by the message saying “your server is down”.

However, things are now much easier in the self-hosted world than they have ever been before. Reproducible environments with containers and mature tooling allow one to leave Heroku but not yet start messing with clusters.

That happened to me. Once Docker became a must in my toolbox, there was no reason for me to continue relying on an external party. Headache was simply no longer there.

Enter Caprover

I have the following containerized, self-hosted and served through Cloudflare as well as checked with uptimerobot:

  • Matomo (web-analytics, an alternative to Google Analytics)
  • Ackee (web-analytics, a simpler alternative to Google Analytics)
  • Sendy (newsletters with AWS SES)
  • Minio (AWS S3-compatible storage)
  • Monica (personal CRM)

Caprover is how I deploy and manage all of it with good ol’ SSH when needed. Deploying a new app is a matter of a few clicks. The support of Docker Swarm is a cherry on top.

Business case

As mentioned above, chances are – external services will limit your ability to add features to your product. It could be a fancy Nginx/Apache configuration, custom domains for your users, or tweaking low-level performance.

Outages are bad, but it’s even worse when outages are out of your control. If you have the knowledge to set it up and have all the tools to know when something goes wrong, it’s an advantage on your side.

Business-wise, you know that the companies behind these services target the biggest market. It means that if your product falls out of that range, you’re left behind as you are an edge case to that service provider.

Community

I stumbled upon some solid advice and enormous lists of ready-to-use solutions on subreddit /r/selfhosted and awesome-selfhosted.

The big open-source community lets you be sure that possible problems with setting up and configurations are more likely already solved and they can be easily found.

Privacy

It’s important. As a technologist, I understand that the whole industry operates on duct tape, and trusting corporations to respect your users’ privacy is not at all realistic or rational.

A simple example in favor of self-hosted solutions: millions of people use ad blockers. There is no need for you to use Google Analytics as it gets blocked, worsens your reputation, and feeds big G’s network. Self-hosted alternatives like Matomo or even something simple like Ackee might be enough.

Or you could replace Slack at your company with Mattermost and be sure that your internal communication is in safe hands – yours.

Summary

As you can see there is a decent amount of upside for you to start self-hosting. Of course, it doesn’t mean we have to give up nice-to-have services but I gained a lot of value by doing so. No doubt it is an investment but the gained knowledge and edge-case advantages proved to be a good return on it.