Deployments
2025-07-27
Imagine a user wants to use your app, so they look it up on the internet and find your domain. They go to your domain and you want to serve them your webapp. For any of that to work, you need a few things prepared first on the deployment side: (1) registered domain, (2) DNS records set, (3) have a network-accessible server or a proxy/load-balancer/firewall, (4) host or container for you app. Only if all that works smoothly can you resolve the request with your app and reply with a response. In this post we're gonna look at some solutions for steps 3 and 4.
Your app has to run somewhere, it has to be executed on some machine that is also in some way accessible to your users. The process of putting it there, especially for production use, is exactly what we call deployment. There are a few approaches to getting that done.
The traditional approach is to spin up a server, either on real hardware by yourself or as a rented VPS, install all the software you need on that server, and then expose it to the internet. This is a very good and easy approach. You get to understand what happens at every step of the way. The pricing is clear and limitations of this setup are rather obvious. It's difficult to scale, Continuous Deployment can be tricky, and sharing the same server for multiple projects is not necessarily clean.
To build on top of that, you could use containers, for example with docker compose, to run multiple projects on one host. The advantage of this is that your system configuration is now confined to a container, so there can be no issues with shared libraries or conflicting dependencies between different projects. This is a sweet spot for ease of use with small projects. The setup is usually smooth and once it's done - deployments become very easy. All you have to do is rebuild and push your container, then bump the image tag on your host to re-deploy. Scaling would be limited to the power of your host, unless you apply another solution...
You could use docker swarm mode, which lets you utilize multiple hosts clustered together to serve docker images cooperatively. This is all fine and you will find many different solutions built on top of that. Some neat self-hosted solutions for deployment management with Docker Swarm I would like to mention: Co-op Cloud, CapRover, Coolify, Dokploy, Swarmpit. The original idea for this post was to go through these, compare them, and perhaps conclude on what I want to use more. Unfortunately, they are all too cool and I still cannot decide myself, so instead I suggest you check them all out by yourself.
There is another common approach to deployments: using Kubernetes, or k8s for short. It's probably the best solution for modern distributed computing, scaling at a different magnitude. It was designed and released by Google and is now widely supported in the world of enterprise open-source; notably with RedHat's OpenShift products being built on top of it. Kubernetes is a beast that deserves a dedicated blog post or even a few. This solution is complicated enough to create a dedicated role in the industry. DevOps, which was originally meant to be Development+Operations, became more of a modern infrastructure administration role centered around a software development model spawned from the adoption of Kubernetes for deployments. Cloud, microservices, IaaC, CI/CD pipelines, containers, and more. These topics were heavily hyped up not too long ago - it was a big one just before LLMs and cryptocurrencies took over the news. All of it is easy enough for a motivated developer to understand and operate, but time-consuming and annoying enough to warrant getting another person employed just to take care of it. Many places build out their own pipelines and custom UIs just to make these things easier to operate.
For certain workloads there is a better way. With each approach discussed we've been abstracting away from the bare metal machine running our code. The next step is to go serverless, or in other words, to completely forget about the underlying servers running our deployments. Kubernetes, Docker Swarm, VPS administration - with this approach none of these are our concern anymore. Unlike previous options, this one is pretty much always bound to some managed solution. Our app code will run on ephemeral virtual machines spinned up on demand by our cloud provider. That way the infrastructure we rent out can scale anywhere, even down to zero (free beer!). Some interestng providers, besides the big three of cloud, that can offer this are: Cloudflare, Fly.io, Netlify, Vercel. You will likely need a managed database to match. Lately I really like to use Turso for this, so even though it can be kinda a controversial choice, I'd still recommend that. I'm skipping over the details of "serverless functions" and instead I leave that part of research as an exercise for the reader. Serverless is really great if you don't want to get deep into the infrastructure rabbit hole and still want to deliver good and scalable experience for your users. This is what truly makes developer's life easier. We get great UIs, great management options, logs, easy and fast rollback features, easy setup, scaling, all the good stuff. If you need a better explanation of what serverless is and how it's different from a k8s deployment, here's a really good video by Theo (t3.gg) that I highly recommend watching: https://www.youtube.com/watch?v=_VQl_HTk9PM
To summarize, the common options are:
1. deploying software directly on a server
2. deploying through docker on a server
3. using docker swarm, perhaps through some other UI
4. using kubernetes, again perhaps through a dedicated UI
5. using serverless deployment solutions
And finally here's my recommendations on what to pick:
1. If you are working on a modern webapp - go with serverless deployment using Cloudflare or Vercel.
2. If you're working on a research project, especially in early stages, consider the simplest of options: 1 and 2.
3. For almost anything else Docker Swarm directly on your VPS is probably the right choice, especially with additional open-source tooling. Personally, that would be my preferred choice.
4. If you need to scale over multiple machines or run a big enterprise - Kubernetes is for you.
Happy DevOpsing!