Most vendors will probably have documentation with a basic setup guide for what you should be doing in order to be able to connect to it. I’m going to assume that it comes with a new user, either a password or preferably an authorized ssh key.

Basic Setup

I’m not going to be diving deep into this as I’m not a linux sys admin nor do I want to pretend like I am. So I’ve followed the docs from my vendor here.

This setup means I now have a:

1. Linux box with a new user with admin privileges
2. SSH configured using a public key on port 2222 and hardened disallowing some features we will not be using
3. A basic firewall allowing, for now, just port 2222. If your vendor includes a firewall upstream from your box you should use that too to not rely on a single layer of defense.
4. Updated all the packages and made sure they’re all current
5. Put in some basic countermeasures for intrusion prevention

That’s all we need for now on the server end. With this set we can get started on the actual application.

Bitwarden

While this has nothing to do with the server, I do want to call out that I’m using bitwarden, hosted in Europe, for my passwords/keys. The reason I mention this is because I think it ties in really nicely with server authentication.

I store my SSH keys in bitwarden and I’ve set it up to integrate with the ssh-agent as described here. This means that, whenever I use ssh or scp or any other CLI tool, I will get a neat popup from bitwarden before it grants usage to the key like this:

The one caveat with this is that, as of writing, it doesn’t deal well with having a lot of ssh keys. I’ve solved this by creating individual files with the public key in each and then set that as the IdentityFile. The script for creating one of these is (replacing test for the name of your key)

ssh-add -L | grep "test" > ~/.ssh/server.pub

Then you can use that pub file as the IdentityFile when connecting. In my case I do this through an entry in ~/.ssh/config like:

Host test-server
    HostName {your-ip}
    User {your-username}
    Port 2222
    IdentityFile ~/.ssh/server.pub

And with that set I can now connect using ssh test-server or use that name instead of the ip and username in scp etcetera.

Comparison With Cloud

When deploying to the cloud, none of this needs to be setup, you would have different setup to do though. Creating a user within your account, assigning that user privileges and then keeping it’s credentials/tokens securely somewhere. We’ll get to a more interesting comparison later as we start looking at actually hosting the application and other ‘services’ it needs.

Having this does mean that you’re now on the hook for making sure it stays up to date. This can be as simple as a weekly login and running updates on your package manager though.

Recently I’ve been looking to see what exists outside of the cloud/hyperscalers. Getting back to the basics is great as it gives you some new perspectives on what options you have when there’s no push towards putting everything in the cloud.

So in this series I’m going to walk you through all the things I had to do to deploy a relatively simple application outside of the cloud. There are a lot of lessons to be learnt here and it does make you appreciate all of the bells and whistles that you get out of the box. However, learning and knowing these skills I think is essential as it gives you options. Sometimes the cloud is the right place, sometimes it isn’t.

What this series covers

Every post tackles one part of what had to happen in order to make this application run. I’ve written out all the parts that I think I will have but I might end up removing/adding things later as things change.

At the time of writing we’re talking about a straightforward API written in .net core, using some persistent storage as well as a relational database. Along with every topic I’ll try to make a cost comparison as well.

Part 0 — The Box

Getting a VPS, basic firewall configuration. The boring foundation everything else sits on.

Part 1 — The Front Door

Nginx as a reverse proxy. Static site hosting and setting up TLS certificates with Let’s Encrypt. Routing traffic through to things that aren’t static sites.

Part 2 — Containers For The Application

Running the application in a container with podman. This removes the need for installing a lot of things on the server itself and should limit the attack surface significantly. Running it this way should also help with scaling out later if need be as well as with portability of systems between machines.

Part 3 — The Database

Running an RDBMS yourself, as a container, with persistence and backups taken care of. As a developer (and not a DBA) this might be the most daunting task to get right.

Part 4 — Persistent Storage

Not all data is relational, so we’ll talk about how we can use object storage within our API.

Part 5 — Deployment

Going from source control to an actual running process. Building a container or publishing static files, how do we perform updates without or with minimal downtime.

Part 6 — Observability/Monitoring

When things inevitably go down, I want to find out myself as opposed to getting an email from a customer. So let’s dive into logging, monitoring and alerting.

Part 7 — Disaster Recovery

A backup strategy and actually testing those backups. How do we survive the loss of the entire server?

Caveats

This series assumes you have a machine that you have root access to via SSH. This might even be in one of the hyperscalers if you really want to.

Currently, I’m going to assume that the API runs on a single box. I’m very aware of the limits that puts on being able to quickly scale up. Almost all machines will be virtual though, so upgrading to a bigger box should be a few clicks.

This does mean upgrades/server reboots involve some down time, if this is truly unacceptable, this series is not for you. Keep in mind though that to get 99.99% uptime, you are allowed to be down just over a minute a week. If you keep your setup lean, a reboot should easily be less than a minute and much less often than weekly.

I’ve made good progress, but we’re not there yet as you’ll see. But this just means that I might follow this up as I tackle other services.

Email — Soverin 🇳🇱

First things first, I need people to be able to reach me through email. Email is not something I’m willing to host myself, while it might be trivial to get working, it is hard to get right. And in the worst case scenario, all your mails will go to peoples’ spam folders…

So, for email I went with Soverin, a Dutch provider based in Amsterdam. They offer custom domain email hosting for a few euros per month with no ads, no data mining, and a clean privacy policy.

Setup was painless: point your MX records at their servers, verify your domain, and you’re done. They support standard protocols (IMAP/SMTP), which means any proper email client works.

On the client side I use Mozilla Thunderbird. It’s open source, runs on all platforms, and handles multiple accounts well. No Electron bloat, no telemetry — just a solid mail client that does exactly what it should.

The combination of Soverin + Thunderbird gives you full control: email stays in the EU, you own your domain, and you’re not locked into any proprietary ecosystem.

Cost: ~€3/month for Soverin.

Website — Hetzner VPS 🇩🇪

This one might seem a bit controversial. Why on earth would I run a site like this on a VPS. Yes, this is a completely static site, no server side processing whatsoever. There are plenty of options for hosting static sites like Github pages for example. However those aren’t European and a website is just a start, I have many other things to run as well. If your company just needs a website and nothing else, this might not be the setup for you.

The site runs on a VPS with Hetzner. Their data centres are in Germany and Finland, and they’re well known for having some of the best price-to-performance in the European VPS market.

This site is a static Jekyll build, so the server requirements are minimal — a small Hetzner instance is more than enough. Nginx serves the static files, and Certbot handles the SSL certificate via Let’s Encrypt. Yes, technically Certbot is run by a US non profit but this is good enough for me.

Coming from the cloud, this means some actual server management but running a static site isn’t the hardest. More details on that later.

Cost: ~€3/month depending on the instance size.

Git hosting 💪

A version control system is unavoidable, and since for my own company I need exclusive access just for myself I have a lot of options. For this I decided to self host forgejo on that same VPS. It runs in a docker container and is only accessible through my pre-existing SSH tunnel.

This forgejo instance serves all my coding and documentation needs. Anything that I want to keep can go in there, it’s versioned and backed up.

What I haven’t solved for

There are a few things that I still depend on cloud/big tech:

1. domain registration, currently in AWS. This should be easy to change though
2. calendar, business versus personal calendar as my personal calendar is with Google
3. github, I still have a github account and some of my own code lives there, some of this code needs to be public facing though

This is the absolute minimum. As the company grows I will be adding other services, I’ll add follow up posts as I add those.