Now that the social media dust has settled, it’s time to give a fresh look at the way we’re hosting our web applications. Let’s ease-in and start with some basic facts and questions.

There are too many SAAS startups that fail before they get any traction. Did you ever wonder what are the reasons for that? Could it be avoided? As it turns out one of the causes they run out of money is spending more on their infrastructure and third-party dependencies than they actually make, even before they start making any. This essay can serve as a loose guide how to start and get stuff done without spending a s**tload of money in the process.

Dealing with infrastructure is hard

But you know what hits harder? Spending all your money on an infrastructure that you don’t fully utilize. It is true, you’ll need to think about servers, and uptime, and backups, DDOSes, file storage, OS updates… and whatnot, but at a time when your startup has more employees than paying customers you need to ask yourself, “is it really that hard?”.

The truth is that you don’t need to be an seasoned expert to run your application on a server, by which we mean a good ol’ Linux VPS box. There are, of course, several topics that you need to cover to get the ball rolling.

The server

There are some alternatives here. You can go with a regular VPS (virtual private server), a dedicated server, or a bare metal server, the last two pretty much are fully operated by you. I won’t go into much details, but the key takeaway is that a VPS is a virtual machine that runs (usually) on top of a bare metal host. When using a VPS you are sharing the hardware with other VPSs running on that same machine. Long story short, if you are doing this for the first time, you are probably going to end up using a VPS.

So, where do you find this VPS? There are couple of server providers that usually pop-up in this scenario. I’ll just list them in no particular order, so you can decide on your own which one to go with.

• Hetzner (link )
• OVHcloud (now Contabo) (link )
• Linode (link )
• Digital Ocean (link )
• Vultr (link )
• …

There you go. Do your research, see which one fits best, choose, and be happy with it.

About the configuration… don’t be stingy. After all, you are moving from BigCloud where the cost of a service is close to the price of a black market kidney. When choosing don’t go for the cheapest (the $5 instance), take a look around, make some estimates based on your needs. DB’s need more RAM, applications depending on the language (and quality) might need different amounts of RAM, different workloads mean different CPU utilization. Take a look at the “factory” prerequisites for each third party app/service that you’d like to self host and choose the right size. Don’t worry if you don’t get it right the on first try, you can always scale your instance vertically and add more processing power and memmory. Be aware of the disk space, although it’s possible to add more, it’s not as straight-forward as with the former two.

Setting the OS

There are many nerds out there will start shouting “that’s not the best Linux, you know” for a server, but listen, it’s your first server and you need to go with something that’s widely supported, so yes, we go with Ubuntu Linux. If you have experience with something else, great! Go with whatever it is. In any other case, stick to Ubuntu and you’ll be just fine. Which version you ask? The latest LTS will do great, whatever the number.

First things first. You have your server running, you logged in as root using SSH… Couple of things to do here:

• Update the OS (link )
• Create a non-root user that you’ll use for your day to day activities (link )
• Add the user to the sudoers group (look at the one above)
• Configure the ssh server to deny password logins and logins by the root user (link )
• Install some CLI apps (tmux, nvim, tree, nmap, btop… docker?) (link )
• Setup basic firewall rules using ufw (link )

Install the software needed to run your web application

This one usually depends on how you built your app and what it’s dependencies are. The appliaction stack itself should tell you what to install.

• LAMP - Linux, Apache, MySQL, PHP (although Apache is less used these days and is usually substituted by Nginx)
• MEAN - MongoDB, Express, Angular, Node.js (Angular has fallen in popularity, and MERN with React has taken over)

The above two are stacks that were popular some years ago, and are mentioned only for nostalgic reasons. What we refer to as a “stack” is a combo of the language/runtime, database, frontend and backend frameworks. Sometimes it might include an operating system, or a web server. Either way, you get the point. Knowing your stack tells you what to install on your server.

The instalation of any of these should be a breeze since there are numerous tutorials that explain it step-by-step. Usually you’ll use apt as the package manager. Newer (Ubuntu based) distrubutions might use snap, or flatpack. Sometimes you might need to build something from source, and if that’s the case there is usually a well written README file at the root of the project explaining the instalation steps in great detail.

Databases, MQs, Web servers all need to be configured before use. By default they come with a configuration that is generally acceptable, but for a production app you’ll probably have to make some changes. Configuration files are mainly kept in the /etc directory, all in their respective sub-directories, Nginx in /etc/nginx, MySQL in /etc/mysql, etc.

Each one of these services has a detailed documentation on how it should be configured to get the most of it. What you need to do is spend a short while with the docs, or if you are lazy just follow a validated recipe/tutorial and get the desired outcome.

Running your app

This is probably the main reason you are reading this essay.

Applications come in two flavours. Either it runs on top of a runtime engine (python, ruby, node, php, etc), or it’s an self-contained binry executable that runs on it’s own (c, go, rust, c++, zig, etc), Java is somewhere in the middle, with compiled binary code AND a runtime. Whatever your language of choice is it will need some kind of process/service manager or application server for starting, stopping, reloading, managing crashes, and very often capturing output logs.

Here is a list of the most used “process/service managers”:

• PM2 (mostly used with nodejs applications) (link )
• Supervisor (written in python, used for running python or go applications) (link )
• Systemd (comes with almost all Linux distros, used for node, go, ruby, python…) (link )
• Tomcat (used as an application server for applications written in java) (link )
• Nginx Unit (applications server for running go, java, node, perl, php, python, ruby, webasm) (link )

Ask Google which one is most often used with your language/stack, read the docs and run your app. Should not be very complicated.

What’s next?

There are many things. You could set-up some CI scripts, maybe run your app via Docker container, you could set some logging and monitoring or a DDOS protection.

Whatever it is, you can do it. It will make you a bit more valuable at your job, you’ll learn some new things, and you’ll have a bit more knowledge about the infrastructure stack your app is running on. Maybe you’ll discover that DevOps is something you’re deeply interested in. Either way, refraining from spending huge amounts of money (that you don’t have) on a complex cloud architecture (that you probably don’t need) is a smart thing. I’m not saying it’s a perfect solution, but when problems with your infra start showing up it’ll probably be (heard The Primeagen saying this, and I liked it) “a yacht problem”.