If you’d like to plan a migration to a newer server, take a look at this support doc, ensure the pre-migration steps have been actioned, then open a support ticket with us when you’d like it to happen.

If the domain is not expired then please email the Opalstack support team to let us know the domain name and we'll look into it further.

I recommend you close the new account and then log in with your account username.

If you need assistance with any of this then email the support team. Thanks!

I was asking because I keep seeing OSErrors (device or resource busy due to too many open files) appearing for a certain Celery process that is using a gevent pool with a concurrency of 100. It seems to have a resource leak and I'm trying to figure out what's going on. Gemini is already teaching me the commands to figure this out on a per-process basis plus methods to try to fix it.

Thanks Sean!

My original suggestion was just that it's a convenient way to get a custom Nginx configuration in place if you ever needed to add your own redirects or other rules for your app. Since that turned out not to be necessary, you can ignore it.

All Opalstack content, whether PHP, static files, or Node.js apps, is already served through our system Nginx as a frontend reverse proxy. A Nginx Proxy Port app simply reserves an available port on the system and generates the necessary Nginx proxy configuration automatically, which you then attach to a site record.

As for federation specifically, it turns out no custom Nginx configuration is needed on your end. Our system Nginx already includes the necessary proxy rules for Ghost's ActivityPub endpoints out of the box, so any Ghost site on our AlmaLinux 9 servers has federation wiring in place automatically. I confirmed this in my testing on a fresh Ghost install on a subdomain. If you decided to switch back to that and have issues, please let us know.

Opalstack supports systemd --user services for shell users on Almalinux 9 servers. You can use this instead of @reboot cron for better process management and automatic restarts.

With the Bitwarden container already running:

# Generate the service file
mkdir -p ~/.config/systemd/user
podman generate systemd --name bitwarden --new > ~/.config/systemd/user/bitwarden.service

# Reload and enable
systemctl --user daemon-reload
systemctl --user enable bitwarden
systemctl --user start bitwarden

The --new flag tells systemd to recreate the container on each start using the original podman run arguments.

If you previously set up the @reboot cron method, remove it:

crontab -e
# delete the @reboot podman start bitwarden line

Useful Commands

# Check status
systemctl --user status bitwarden

# Restart after config changes
systemctl --user restart bitwarden

# Stop
systemctl --user stop bitwarden

Obviously we cannot change the fact the Google is sending the auto-replies to the wrong address - however, we've fixed it so that the messages sent to the SRS-rewritten address will be delivered to their intended destination.

If you need to have one your assigned ports exposed to the outside world then please contact support to arrange that.

Note that if you just need simple git access for the CLI, you don't need to install anything at all. You can instead access your repos directly via SSH, eg you can create a repo while logged into SSH on the server like this:

git init --bare ~/myrepo

... and then clone the repo from your own computer like this (replacing shelluser and opalNN with your own shell user name and server):

git clone [email protected]:myrepo

You'll then be able to push changes etc from your local working copy.