Skip to content

Releases

v1.1.15 — Fix per-site RAM showing 0

Choose a tag to compare

@ethandacat ethandacat released this 14 May 06:49

Fix: per-site RAM showing 0 KB for running sites

Affects multi-worker processes (gunicorn, node cluster, php-fpm) that survived a panel restart.

Root cause

On panel restart, recoverProcesses() added only the master PID to the site's cgroup. Workers that were already forked before the cgroup was created weren't moved in, so memory.current only counted the tiny master process (~a few MB) or returned 0.

Fixes

  1. recoverProcesses() now scans the master's entire process group and moves every worker into the cgroup immediately — so memory.current is accurate right after restart.

  2. sampleProcs() falls back to summing /proc/*/status RSS by process group when the cgroup is still empty — so RAM is shown correctly even on panels that haven't restarted yet.

Update and restart your panel to fix viewpol and any other multi-worker sites showing 0 KB.

v1.1.14 — Accurate per-site RAM tracking

Choose a tag to compare

@ethandacat ethandacat released this 14 May 05:11

Fix: per-site RAM now always reads from cgroup

Previously, RAM tracking for hosted sites only worked for processes that were started in the current panel session. Any site that was already running when the panel restarted (recovered processes) would show 0 MB in the dashboard.

What changed

  • sampleProcs() now queries the DB for all running sites instead of only the process Map
  • Reads cgroup/memory.current directly for each — the same kernel-level source used for memory limits
  • Counts all forked workers (gunicorn, node cluster, PHP-FPM, etc.), not just the parent PID
  • The pidRss() fallback and the requirement for a tracked PID are gone entirely

v1.1.13 — Environment Variables Editor

Choose a tag to compare

@ethandacat ethandacat released this 13 May 03:52

🔧 Environment Variables Editor

Each site's Settings tab now has a dedicated Environment Variables card — fully independent of Git.

  • Add, edit, and delete KEY=value pairs with a clean inline editor
  • Monospace inputs for easy readability
  • Save Variables patches only the env vars — nothing else changes
  • Variables are injected at process start; changes take effect on next restart
  • Works for all runtimes (Node.js, Custom, Worker, PHP)

v1.1.12 — Change runtime from Settings

Choose a tag to compare

@ethandacat ethandacat released this 11 May 04:41

Change site runtime from Settings

You can now change the runtime of any existing site directly from its Settings tab — no need to delete and recreate it.

What changes automatically

Change What happens
→ Worker Nginx config removed, FPM pool removed (if was PHP)
Worker → other Nginx config written, FPM pool created (if PHP)
Port auto-managed Assigned if new runtime needs one; cleared if not

How to use

  1. Open any site → Settings tab
  2. Change the Runtime dropdown
  3. Fields show/hide dynamically (domain, start command, PHP version)
  4. Hit Save Settings, then restart the site

v1.1.11 — Worker Runtime

Choose a tag to compare

@ethandacat ethandacat released this 11 May 04:23

🤖 Worker / Background Service Runtime

A new Worker runtime for processes that don't need an HTTP reverse proxy — perfect for:

  • Discord bots
  • Telegram bots
  • Background workers / job queues
  • Webhook receivers (internal)
  • Cron scripts / scheduled tasks

What's different from Node/Custom

Feature Node / Custom Worker
Nginx config ✅ Written ❌ Skipped
Domain / SSL ✅ Shown ❌ Hidden
{PORT} in command Required Optional
Process control ✅ ✅
Auto-restart schedule ✅ ✅
Log viewer ✅ ✅

How to use

  1. Create a new site → select 🤖 Worker / Background Service
  2. Enter your start command (e.g. python bot.py or node worker.js)
  3. If your command needs a port, include {PORT} and it will be auto-assigned
  4. Hit Create — no nginx, no domain setup required

v1.1.10

Choose a tag to compare

@ethandacat ethandacat released this 11 May 02:44

Fix: stop button now kills the entire process group (master + all workers)

Root cause diagnosed from VPS output:

  • gunicorn spawns 4+ worker processes; killing only the parent left workers running
  • All site processes run as litehost (isolation migration never ran), so pkill -u lh-* found nothing
  • No site cgroups existed, so cgroup.kill did nothing
  • fuser not in sudoers, so port-based kill was denied

The fix: spawn() uses detached:true which makes the child a process group leader (PGID = child PID). process.kill(-pid, SIGKILL) kills the entire group atomically — no sudo required since all processes run as the same user.

For processes recovered after a panel restart (not in the process Map), getPortPid() finds the master listening on the port and kills its group the same way.

v1.1.9

Choose a tag to compare

@ethandacat ethandacat released this 11 May 02:29

Fix: stop/restart/deploy now reliably kills site processes running as lh-* users.

Root cause: site processes run as lh- (different UID from the panel). The panel user cannot send SIGKILL to another user's process without root. All previous kill attempts silently failed with EPERM.

Changes:

  • stopSite: cgroup.kill first (kernel-enforced, no UID check), then sudo pkill -KILL -u lh-, then direct proc.kill for non-isolated sites, then sudo fuser -k as last resort
  • recoverProcesses: after panel restart, finds surviving PIDs via ss and re-adds them to their cgroups so cgroup.kill works immediately on stop
  • install.sh: adds NOPASSWD sudoers rules for pkill and fuser

VPS manual patch required before updating:

sudo tee -a /etc/sudoers.d/litehost << 'SUDOEOF'
litehost ALL=(root) NOPASSWD: /usr/bin/pkill -KILL -u lh-*
litehost ALL=(root) NOPASSWD: /bin/fuser -k *
SUDOEOF

Then run: sudo litehost update

v1.1.8

Choose a tag to compare

@ethandacat ethandacat released this 11 May 02:23
  • Fix: stop button, deploy, and restart now reliably kill all site processes
  • Root cause: proc.kill() was removed in a previous refactor, so sites without sys_user set (pkill fallback) silently survived stop
  • Four-layer kill: direct proc.kill → pkill by user → cgroup.kill → port-based kill (fuser with ss fallback)

v1.1.7

Choose a tag to compare

@ethandacat ethandacat released this 11 May 02:03
  • Feat: per-site auto-restart schedule (Off / Every 10 min / Every 30 min / Every hour)
  • Only restarts sites that are currently running — manual stops are respected
  • Schedule persists across panel restarts (restored from DB on boot)
  • Configure in site Settings → Auto-restart (node/custom runtimes only)
  • Fix: upgrade no longer requires sudo to restart panel (uses process.exit + systemd Restart=always)
  • Fix: upgrade card works from any page, navigates to dashboard automatically

v1.1.6

Choose a tag to compare

@ethandacat ethandacat released this 11 May 00:28
  • Fix: upgrade no longer requires sudo to restart the panel service
  • Fix: panel now exits cleanly after upgrade and systemd restarts it automatically
  • Change: Restart=always in service file (was on-failure) so clean exit triggers restart
  • Fix: upgrade card works from any page — navigates to dashboard automatically
  • Fix: stale cache no longer silently suppresses the upgrade card