From Azure Functions to Freebsd
Key topics
The debate around serverless architecture and process management heats up as one developer shares their journey from Azure Functions to hosting on FreeBSD. Commenters weigh in on the trade-offs, with some praising the direct control offered by alternatives to systemd, like rcctl and openrc, while others acknowledge systemd's strengths in process supervision. A surprising takeaway is the varied experiences with service management, with some swear by daemontools for rock-solid reliability, while others recall struggling with Monit. As cloud services like Azure come under scrutiny for their usability and developer experience, the discussion highlights the ongoing quest for simplicity and control in system administration.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
7h
Peak period
14
132-144h
Avg / period
5.8
Based on 29 loaded comments
Key moments
- 01Story posted
Dec 8, 2025 at 3:02 AM EST
26 days ago
Step 01 - 02First comment
Dec 8, 2025 at 9:51 AM EST
7h after posting
Step 02 - 03Peak activity
14 comments in 132-144h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 15, 2025 at 7:46 AM EST
18 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky. You seem to have figured out a good solution, but I wanted something simpler like PM2 for automatic process management/restarting/logs. Unfortunately PM2 has an issue [1] that makes it unworkable with FreeBSD. It would be so nice if FreeBSD had a smooth, more declarative way of managing processes.
1. https://github.com/Unitech/pm2/issues/5718
> I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky.
It indeed is tricky. To be honest, I wasn't "put off" by it because I've been using BSDs and old-style Linux startup systems for almost 30 years now... but the lack of abstraction shows, and I don't think it's great.
The daemon(8) wrapper is neat to integrate pre-existing servers into rc.d, but I do not fancy having to deal with that "by hand" nor to create a shell script to manage my own service (related from a few years ago: https://jmmv.dev/2020/08/rcd-libexec-etc.html) nor to have something entirely separate to manage log rotation.
As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model. BUT, as I mentioned in this article, I also like the "no churn" of the BSDs because what I learned and refined over ~30 years is still similar to this day and that I won't be bitten by surprises.
Now there are several daemontools derivatives that bring it more up-to-date, but even the ancient original version did most of one would need for reliable service management.
I've been playing with dinit for a bit now; it combines a lot of the nice advantages of systemd with a finite scope and being portable across OSs.
I do like the Unix way of having different components handling different tasks instead of having different things which are entangled with each other. It encourages transparency.
Systemd might add a bunch of unnecessary complexity in places, but for a sysadmin it's a fucking blessing. Just write one simple file, set binary, user, done, add some limitations and dependencies if you want to be fancy, set auto restart to true and It Just Works.
Can even set some memory limits if you want to be fancy so any memory leak won't get you into too much trouble but just gets the service restarted
The AWS Rust SDK also seemed very mature to me when I was using it ... compare to:
>the only option for a database instance with a free plan was [...] serverless Microsoft SQL Server (MSSQL)
>the MSSQL connection required TLS and this hadn’t been implemented in the sqlx connector I chose to use for my Rust-based functions. I wasted two weeks implementing TLS support in sqlx
That is insane. Not to mention the later bit with sudden, unexplained availability and the only hint that it might to be related to a _future_ deprecation? Like, imagine if this were a critical service for you. Professional malpractice on Microsoft's part.
This isn't really the main point of the article, and I did find the stuff on self-hosting interesting, but it does seem like this could have been avoided if Azure had lived up to its peers.
I don't see why one would want to run in-the-clear over the Azure network for SQL connections.
The author was doing hobby projects. Granted, hobby projects should run on any platform, but Azure seems to have less of that free tier you can get elsewhere.
It's the MS way. I remember writing some code for MS graph and wondering why the hell it isn't working, I'm doing near same thing that doc example did. Nonsense generic error message. Left for the day, ran code next morning, everything works fine.
No message saying "hey the thing behind it is down", just error that was generic enough that it could be my inputs being wrong.
Solution:
1. Delete Function App
2. Deploy again
3. Profit?
I'm now thinking something like Supabase or Convex may be the way to go for personal projects. Any experiences?
We're constantly striving to improve the user experience and the quality of StackGres. Would you mind sharing some feedback as to what made your experience not good with it?
Did you join the Slack Community (https://slack.stackgres.io/) to ask if you were facing some trouble? It always helps, even if it is just by sharing your troubles.
(If you'd like to share feedback and do so privately, please DM on the Slack Community)
Your feedback will be much appreciated.
[edit]: typo
https://azure.microsoft.com/en-us/pricing/member-offers/cred...
I've had mine for over a decade.
Needless to say that those details weren't rewarding at all. Knowing them just served the ego of specific vendors, who were more than happy to pull a rug under your feet with deprecations, migrations, and "required actions" I had to manually follow in order to keep the services just running.
Enough is enough. One sunny day of 2021, I started to migrate the infrastructure using the garage-inspired approach. Dockerfile became a breath of fresh air, a relieve after the years of convoluted dictatorship. No more dependencies on ever-changing whims of individual cloud vendors, no rug pulls.
I had no prerogative of keeping my servers near me, instead I found a good home at fly.io.