Tag: debian trixie

Install Node.js 24 & PM2 on Debian 13, Including Log Rotation

If you’re running Debian 13 for a production server, Node.js 24 + PM2 is a practical setup, simple deployment, easy process management, and predictable restarts.

Below is a production-friendly installation guide, including PM2 log rotation.

1. Install Node.js 24 (via NodeSource)

Update packages and install prerequisites:

sudo apt update
sudo apt install -y ca-certificates curl gnupg

Add the NodeSource GPG key:

curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key \
  | sudo gpg --dearmor -o /usr/share/keyrings/nodesource.gpg
Code language: JavaScript (javascript)

Add the Node.js 24 repository:

echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_24.x nodistro main" \
  | sudo tee /etc/apt/sources.list.d/nodesource.list
Code language: PHP (php)

Install Node.js:

sudo apt update
sudo apt install -y nodejs

Verify:

node -v
npm -v

2. (Optional) Install Build Tools

Some npm packages (native modules) require compilation

sudo apt install -y build-essential python3 make g++

3) Install PM2

Install PM2 globally

sudo npm install -g pm2

Verify:

pm2 -v

4. Run Your App with PM2

If your app uses npm start

cd /var/www/myapp
pm2 start npm --name "myapp" -- start
Code language: JavaScript (javascript)

Check status

pm2 status

View logs:

pm2 logs myapp

5) Install PM2 Log Rotation (pm2-logrotate)

This prevents logs from growing endlessly and filling up disk space.

Install the module, donot use ‘sudo’, because it will install and run under roor, not current user

pm2 install pm2-logrotate

Confirm it’s installed

pm2 status
pm2 show pm2-logrotate

pm2 conf pm2-logrotate

6. Recommended Log Rotation Settings (Production-Friendly)

Example: rotate when logs reach 50MB, keep 14 files, compress old logs.

pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 14
pm2 set pm2-logrotate:compress true
pm2 set pm2-logrotate:dateFormat YYYY-MM-DD
pm2 set pm2-logrotate:workerInterval 30
Code language: JavaScript (javascript)

Optional: rotate on a schedule (cron). Example: rotate daily at midnight

pm2 set pm2-logrotate:rotateInterval '0 0 * * *'
Code language: JavaScript (javascript)

Restart processes to keep everything clean:

pm2 save
pm2 restart all

7) Where PM2 Stores Logs

By default, PM2 logs live here:

~/.pm2/logs/
Code language: JavaScript (javascript)

Quick check

ls -lah ~/.pm2/logs/
Code language: JavaScript (javascript)

8) Uninstall Log Rotation (If Needed)

pm2 uninstall pm2-logrotate

How to Install MariaDB on Debian 13 (Trixie) , Root Uses Password (Debian 12-style)

To install MariaDB on Debian 13 (Trixie), follow these steps (same rhythm as my Debian 12 guide, but updated for Debian 13).

Debian 13’s repo package is currently mariadb-server (1:11.8.3-0+deb13u1). (Debian Packages)

1. Update Package Index

Start by updating the package index to ensure your system has the latest information on available packages.

sudo apt update

(Optional but recommended)

sudo apt -y upgrade
sudo reboot

2. Install MariaDB Server

Use the following command to install the MariaDB server and client:

sudo apt install mariadb-server mariadb-client -y

3. Start and Enable MariaDB Service

Once installed, start the MariaDB service and enable it to start on boot.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Check status:

sudo systemctl status mariadb --no-pager

4. Secure the Installation (force root password)

To improve the security of your MariaDB server, run the security script:

sudo mariadb-secure-installation
# legacy name (still common in tutorials)
sudo mysql_secure_installation
Code language: PHP (php)

MariaDB notes that from 10.4+, unix_socket auth is commonly applied by default, so many older tutorials are outdated. In our case, we want root password, so pay attention to the prompt. (MariaDB)

During this process, you’ll be asked to:

  1. Set a root password.
  2. Remove anonymous users.
  3. Disallow root login remotely.
  4. Remove test databases.
  5. Reload privilege tables.

Important (Debian 13 / modern MariaDB prompt):
If you see:

  • Switch to unix_socket authentication [Y/n]

Answer n (NO), because you want password-based root login. (MariaDB)

Then when asked to set root password, answer Y and set a strong password.

5. Test Root Login (Password)

Verify you can login using root + password:

mariadb -u root -p

If root is already using unix_socket (fix it)

If you accidentally selected unix_socket, you can switch root back to password auth.

Login locally (this still works if socket auth is enabled):

sudo mariadb

Then run:

ALTER USER 'root'@'localhost'
  IDENTIFIED BY 'YOUR_STRONG_PASSWORD';
FLUSH PRIVILEGES;
Code language: JavaScript (javascript)

Modern MariaDB root defaults can involve socket authentication, but ALTER USER is the supported way to change credentials/auth behavior. (MariaDB)

Exit:

exit;
Code language: PHP (php)

Test again:

mariadb -u root -p

6. (Optional) Configure MariaDB

You can edit the MariaDB configuration file for additional settings if needed. The main configuration file is located at:

sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf

After making changes, restart MariaDB to apply them:

sudo systemctl restart mariadb

Your MariaDB server should now be up and running on Debian 13.

Debian 13, Make Your Server Stop “Hanging” Under Load with vm.swappiness=10

If you’ve ever had a small Debian server that technically is still alive, ping works, uptime is fine, but SSH becomes painfully slow and your apps feel like they’re moving through syrup, there’s a good chance you’ve met the quiet villain, disk swap.

Linux is incredibly smart about memory management, but on machines with limited RAM (1–4GB is the usual battlefield), it can sometimes start swapping earlier than you’d expect. And the moment that swapping becomes heavy, the server can feel like it’s frozen even if the CPU isn’t maxed out.

The fix often isn’t “add more swap” or “buy more RAM” (although those help). The fix is to teach the kernel a simple preference

Use RAM first. Use swap only when it’s really needed.

That preference is controlled by a kernel parameter called

vm.swappiness

What “swappiness” really means (in human terms)

Swappiness is a number that influences how aggressively the kernel moves memory pages out of RAM and into swap space.

  • Higher value > kernel is more willing to swap
  • Lower value > kernel tries harder to keep things in RAM

Most distros default to something around 60, which is generally fine for modern machines with plenty of RAM. But for small servers, especially those running databases, Node.js apps, Strapi, queue workers, or anything with bursts of memory usage, that default can be too eager.

The classic symptom looks like this

  • your app suddenly slows down
  • SSH input lags
  • “top” shows nothing dramatic
  • disk activity spikes
  • everything feels “stuck” until it recovers

That’s why a very common, practical baseline tweak is:

Set swappiness to 10.

It doesn’t disable swap. It simply lowers the priority of swap so your server stays responsive longer.

Before changing anything, check your current state

Start by confirming your current memory and swap situation:

free -h
swapon --show
cat /proc/sys/vm/swappiness

If you see swappiness is 60, you’re looking at the common default.

Set vm.swappiness=10 (immediate effect)

To apply it right now (until the next reboot)

sudo sysctl -w vm.swappiness=10

Then confirm

cat /proc/sys/vm/swappiness

At this point, Debian 13 will behave noticeably better under memory pressure: it will try harder to keep active application memory in RAM instead of pushing it out to disk.

Make it permanent on Debian 13

A reboot will reset the value unless you persist it. The clean Debian way is to add a sysctl drop-in

echo "vm.swappiness=10" | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system
Code language: PHP (php)

Re-check

cat /proc/sys/vm/swappiness

Done. Debian will apply this automatically on future boots.

How to tell if it’s working

The best confirmation isn’t a number, it’s behavior. Your server should remain usable longer when traffic spikes.

If you want to watch swap activity live, install sysstat and use vmstat

sudo apt install -y sysstat
vmstat 1

Look at:

  • si = swap in
  • so = swap out

Ideally, those numbers stay at 0 most of the time, occasional swap usage is normal, constant swap in/out is where performance dies.

The important nuance for small memory: don’t remove swap blindly

When people feel swap pain, the first instinct is, “Okay, no swap at all.”

On small RAM machines, that can backfire.

Swap is still useful as a safety net. Without it, when memory runs out, Linux may trigger the OOM killer and terminate processes (sometimes the wrong one). So the best balance for most small servers is

  • Keep swap enabled
  • Lower swappiness so swap becomes “last resort”

That’s exactly what vm.swappiness=10 does.

If you truly want “no disk swap” but still want safety, the modern solution is zram (compressed swap stored in RAM). That’s a separate topic, but it’s worth it for tiny VPS nodes.

Suggested values (what I actually use in practice)

  • General small server (1–4GB RAM): 10
  • Database-heavy or latency-sensitive services: 1–10 (start with 10, then test)
  • If you still see heavy swap churn: consider zram, or add RAM

No one number is perfect, but 10 is a great baseline because it reduces swap pain without turning off the safety net.

Rollback (if you need to revert)

Temporary revert to a common default:

sudo sysctl -w vm.swappiness=60

Permanent revert:

sudo rm -f /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Cheat sheet

# Check
free -h
swapon --show
cat /proc/sys/vm/swappiness

# Set now
sudo sysctl -w vm.swappiness=10

# Persist
echo "vm.swappiness=10" | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

# Observe swap activity
sudo apt install -y sysstat
vmstat 1
Code language: PHP (php)

Closing thoughts

On small-memory servers, performance issues often don’t come from CPU, they come from the kernel quietly shuffling memory pages onto disk. The machine is “up”, but the experience is awful.

vm.swappiness=10 is one of those small changes that turns a fragile VPS into a predictable one: fewer freezes, better responsiveness, less panic during spikes. It’s not magic, but it’s a solid baseline, especially if you run web apps and databases on limited RAM.