The stack

I’ve personally deployed directly on VMs for years using docker-compose, that includes commercial products, some of them were pretty beefy. Not only this is painless after you have your sample configurations and a workflow, but you are never limited to one cloud provider/platform.

I used to run the following services by default:

1. Nginx - running in reverse proxy mode that is also responsible for https traffic;
2. Certbot - responsible for fetching and refreshing letsencrypt certificates;
3. Postgres - in 95% of cases, having a self-managed postgres instance located on the same VM is better than alternatives, both in terms of reliability/resource usage/latency.

I’ve updated my setup recently and now I’m using nginx proxy manager instead of nginx+certbot, you lose the declarative approach, however it’s that much easier to get https up and running, for me this is always painful when deploying a brand new project.

The only caveat with this approach is that your project needs to be dockerized, I use mainly gitlab + custom runners to achieve this, however it’s clear that this setup is more involved out of the box because of docker, maybe it could be improved by injecting the release in the container instead of building immutable containers.

Deploying new versions

The setup I use to deploy new versions is pretty primitive, I basically have a git repo called my_project_infra, that contains the docker-compose.yml and all the additional configuration required to deploy that product + some shell scripts to make this work easier. I leverage on git to be able to revert to old configurations if something goes wrong, worked with this setup in production with great success.

I can do zero downtime deploys. The only big thing that this is missing is continuous delivery, which I want to do for all projects these days. I will definitely invest some time in the future to make this work independently of any cloud providers on the market.

Self-hosted vs VPS

Until recently, I was using hetzner (usually for dev envs + runners) and aws (for prod) VMs for deploy, until I recently finally configured my own server at home.

I want to say that having your own infrastructure makes things 100x times easier, especially if there is networking involved. I literally have now practically unlimited resources at the cost of 20$ I pay for the electricity (I have a beefy hp proliant server, so you might easily get away with 5$ for electricity if you have a more power-efficient system).

The home server is also times more reliable as I have it currently running in raid 1 + I plan on setting up a NAS for periodic backups/snapshots, this kind of reliability comes at a premium if you offload it to a cloud provider.

As for networking, as other mentioned above, if your provider blocks inbound connections, using cloudflare tunnels is the way to go, their free plan is very generous and it’s a turnkey solution that I’ve used reliably in the past. The only caveat is that you take some time to understand the security implications of passing unencrypted traffic through their systems.

If those small projects are all written by you, and you can ensure there is not library version conflict, you can run them all in the same Erlang release. There is main proxy, but something as simple as this will work, with liveview and all that.

defmodule MySuperProject.Plug do
  def init(options) do
    options
  end

  def call(%Plug.Conn{host: "app1.host.domain"} = conn, opts) do
    App1Web.Endpoint.call(conn, opts)
  end

  def call(%Plug.Conn{host: "app2.host.domain"} = conn, opts) do
    App2Web.Endpoint.call(conn, opts)
  end

  def call(conn, opts) do
    DefaultAppWeb.Endpoint.call(conn, opts)
  end
end

If you own a domain (e.g. artem.xyz) you can put a Phoenix site on each subdomain (e.g. project-1.artem.xyz, project-2.artem.xyz), or you can use a reverse proxy like nginx to put each project in a different path for a given origin (e.g. artem.xyz/project-a, artem.xyz/project-b).

I put my toy projects on a cheap VPS (Hetzner). It’s good practice to run something like that because it also teaches you the basics of DevOps. Sure, you can pay someone like Netlify or Render or fly.io to hide the difficult stuff away, but learning how to do it yourself is a great skill to have. And it’s really not that difficult once you understand what is going on.

So my setup for these toys is to create the server, then use Ansible to set up the server (create users, disable root access, install and configure services, etc.). Then I have a playbook that pulls my Git repo, builds a Docker image, then restarts the server with the new container.

First, you set things up manually, then automate them. There’s tons of great tutorials online that will show you how to set this stuff up.