This looks good, and Dokku has been very solid for me, but removing the Docker dependency means that now I'm beholden to my OS's choices. For apps that might run for years without maintenance, that's not ideal, as you'll quickly find you need a specific version of the OS for them.
You can use docker with it - I have a couple of things with "docker run" statements in the procfile, but of course it’s not designed for that.
Most of the deployments I got wind of are on extremely stable distros - typically LTS versions where you will not need to upgrade your runtime every six months (and my website has been running in it for at least two Ubuntu LTS releases…)
But you can trivially use pyenv/nvenv/etc. by just setting environment variables. My home automation system now needs two different Node versions, and I have one set per app.
That depends on your tech stack. I have Perl CGI and Java apps that have been running unchanged for two decades. And the only thing I ever had to change on Debian over that time was adding HTTPS (Let's Encrypt) and SPF/DMARC for email.
My point is that OS upgrades don’t have to break tech stacks, and don’t tend to with runtimes that care a lot about backwards compatibility like Perl and Java. I did regularly upgrade Debian across those two decades.
IMO that quality should be the default, and I would choose my OS and tech stacks accordingly.
The runtimes are part of the Linux distribution and get upgraded along with it (and receive continuous security updates along with it), while maintaining backwards compatibility for the application code (Perl scripts or Java bytecode). Tools like needrestart will notify when a process needs to be restarted to take advantage of the update.
Well, I don't know about you, but my dependencies have often been built against a static library from a different version of the OS, so they wouldn't work on mine.
I agree. But 2008 is old enough that exploits may be lost in time.
I recently pentested a client, and had great problems connecting to an old service still using SSL (i think it was 2.0). Every modern tool straight up refused to connect, there was no method to override that, oldest static curl binaries i could find were still too new, I couldn't easily compile curl from source because dependencies also changed in the meantime. Finally I've found sn acient docker image that worked.
The service was ironically so old that no modern vulnerability scanner or programming language would be able to connect!
This made me seeiously ponder the fleeting nature of modern world - SSL support was everywhere 15 years ago, and now I, as an expert, had great problems using it. What chance do we have in 100 years?
Question - how can dependency hell be solved when using such a tool?
It seems so elegant and I love the "it just works" attitude, and I do understand that docker can't be used everywhere due to its technical (and mental) overhead, but I love it because it allows to isolate everything, freeze everything in time so running a container 5 years for now "just works".
In my humble workflow, I'm using lazydocker to manage the containers, gitlab workflow (action?) for deployment on push and a small VPS to build and push the containers to gitlab registry and to run it, on the same VPS. It's a little bit overkill - I could use a combination of a Dockerfile and a compose.yml with docker compose build. Also, I didn't figure out scaling yet. Good thing I don't need it! Otherwise I would swap docker for k8s and lazydocker for k9s.
(I'm open to suggestions. I just got into devops, and I love it!)
Personally I use the same approach to piku, but instead rebuild my Nixos config on push. My projects use nix flakes, so I get both something that I know will run on my server and on my local machine with the full development environment. No containers needed technically, but I use systemd nspawn to run the software in its own sandboxed namespace.
My entire server is then managed declaratively, so if I want to add a new project, it’s like 3-5 lines of Nginx config and push, that’s all. Something goes wrong? Just revert the commit.
As far as the nixos config is concerned, there is nothing crazy in it. It is just a regular nix config with nginx (https://nixos.wiki/wiki/Nginx). You can see there that adding nginx is just four lines of code, ~eight with ssl. Use it to proxy to your applications that are setup as systemd services (https://wiki.nixos.org/wiki/Systemd/User_Services).
Edit: btw I'm a big fan of asciinema! ty for making it. :)
Nix would actually be fantastic for this, but I've never been able to get it to work (including with Devbox and a few other such solutions). I might try again, thank you.
