Manage node app inside a jail

Hi everybody,
I'm trying to build a setup on a vps to run my node api app.
Since now i used vercel to run it and they manages start/restart of the app and the environment secret variables (api key, neon secrets, jwt secrets etc) automatically.
I followed the handbook and installed freebsd 15, created the jail type Vnet with ZFS, configured a bridge from host to jail, setup node 22 and npm run as jail user succeed, setup pf and nginx with https management on the host to route request to my api node be on the jail: Everything is prefect!

I miss just two things:
- What is usually used to start/autorestart (ex if the node app crash) inside the jail? i think an rc.d script could do the job but i'm not sure if it's the correct way to do it (may depends on the second question?)
and more important:
- Where i have to safely store/manage the .env file where i have all my secrets?


random info: Currently in the node app i'm doing "process.env.name" to access the env from the code.

Edit: I create a rc.d script inside the jail that successfully started the application with the env written inside the script. The rc.d script permission is set to 700. The service is started as root and the app as user of the jail. I read that i can link a file inside the script to keep the env separated, but is this the correct way to do?

Thanks in advance
 
Another tool for monitoring services can be sysutils/s6 and/or the related complete service manager sysutils/s6-rc. They are used a lot in containers, and also from the FreeBSD daemonless project.

Full disclosure: I never used them, but the design of s6 seems sound. Instead of starting directly the service, it starts a supervisor that intercepts (all/many) problems with the service, and manage them. When/if I have time, I want to test these tools.

(edit: a link to the s6 project and philosophy)
 
NOTE: I often use plex/emby as a goto example jail because they're simple and easy.

To add another option to the mix:
The following is along the lines of "super low-tech". I offer it up for those that may be able to use something as simple as this. The reason being because I found sometimes daemon(8) doesn't restart the service (I think I remember tracking down some issue with plex and I started to dig into the rc.d script for plex and there was something that tripped me up when I decided to do the following in the meantime and get back to it--which I now realize I haven't actually).

Code:
[daserver:~]cat /etc/jail.conf.d/emby.conf 
emby {
  ...
  # Self healing; restart the jail if the `dotnet` process stops.
  exec.poststart += "if [ -f /opt/scheduler/cron/emby.crontab ]; then cp /opt/scheduler/cron/emby.crontab /etc/cron.d/emby.crontab; fi";
  exec.prestop += "if [ -f /etc/cron.d/emby.crontab ]; then rm /etc/cron.d/emby.crontab; fi";
  ...
}
[daserver:~]cat /opt/scheduler/cron/emby.crontab 
# /etc/cron.d/emby.crontab - embymediaserver crontab
#
# This is supposed to run a script every five minutes from 6am to
# 12pm to check and make sure the `emby-server` (dotnet) process is
# running and restart the emby jail.
# 
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
#
#minute    hour    mday    month    wday    who    command
*/15       6-23/1  *    *       *    root    /opt/conf/sys/processcheck.sh 'dotnet' emby

[daserver:~]cat /opt/conf/sys/processcheck.sh 
#!/bin/sh
# Checks to see if a process has stopped and if it has it stops and
# starts a jail.
_process=$1
_jailname=$2
if [ ! $(/usr/bin/pgrep "${_process}") ]; then
        service jail stop $_jailname
        service jail start $_jailname
fi


Aside from that, I noticed that "monitord-0.4.1_8" `pkg search -Q full monitord-0.4.1_8` is BSD lic if anyone is looking for a non GNU version.
 
Thank you all for the replies:
Currently i'm using daemon with -r option inside the rc.d script to restart the node app; i've added the supervisor pid to gently kill the child (my app) when i run service stop. Since now i'm not facing any issue. But i will look into monit for sure.
I'm currently just a little bit worried about the env, because is the first time i have to think about thei security...now they are placed inside the rc.d script that has only root rw permission
 
Back
Top