Forem: khimananda Oli

Ditch Static IAM Keys: Run Terraform with AWS SSO

khimananda Oli — Thu, 09 Apr 2026 05:08:30 +0000

If your team is still using shared IAM user credentials to run Terraform, it's time to switch to AWS SSO (IAM Identity Center). In this article, I'll walk you through how I migrated our multi-account Terraform setup from a shared deployment IAM user to individual SSO-based authentication for both local development and CI/CD pipelines.

Our Previous Setup

We had a classic multi-account Terraform setup with three AWS accounts:

Shared/management account - Hosted the S3 state bucket, DynamoDB lock table, and custom Terraform modules in S3
Dev account - Development environment
Live/prod account - Production environment (with additional live-eu and live-dr workspaces)

A single IAM user called deployment lived in the shared account. It had an access key that was shared across the team and stored as GitHub secrets for CI/CD. The Terraform provider used assume_role to switch into the target account:

provider "aws" {
  region = "us-east-1"
  assume_role {
    role_arn     = "arn:aws:iam::<account_id>:role/deployment"
    session_name = "deployment"
  }
}

The S3 backend stored state and locks in the shared account:

backend "s3" {
  bucket         = "my-tf-states"
  region         = "us-east-1"
  key            = "core.tfstate"
  dynamodb_table = "terraform-locks"
}

And our GitHub Actions workflow used static IAM keys:

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: us-east-1

Custom modules were stored in an S3 bucket and referenced like:

module "my_module" {
  source = "s3::/my-tf-modules/1.0.41/my-module.zip"
}

This setup worked, but it had serious problems:

No individual accountability - CloudTrail logs showed deployment user for every change, making it impossible to trace who did what
Security risk - Static keys can leak, get committed to git, or be shared insecurely
Key rotation pain - Rotating one shared key means updating it everywhere
No MFA enforcement - Long-lived access keys bypass MFA requirements

The Solution: AWS SSO + OIDC

With AWS IAM Identity Center (SSO), each DevOps engineer authenticates with their own identity. For CI/CD, GitHub Actions uses OIDC federation - no static keys stored as secrets.

Local Development:
  Engineer -> AWS SSO Login -> Temporary Credentials -> Terraform

CI/CD (GitHub Actions):
  GitHub Actions -> OIDC Token -> AWS STS -> Temporary Credentials -> Terraform

Step 1: Remove the assume_role Block

Since each engineer will authenticate directly via SSO into the target account, there's no need for assume_role. Terraform will use whatever credentials are in the environment.

Before:

provider "aws" {
  region = "us-east-1"
  assume_role {
    role_arn     = "arn:aws:iam::<account_id>:role/deployment"
    session_name = "deployment"
  }
}

After:

provider "aws" {
  region = "us-east-1"
}

Step 2: Fix the S3 Backend for Cross-Account State Access

This was the trickiest part. Our state bucket and DynamoDB lock table lived in the shared account, but now we're authenticating directly into dev/live accounts via SSO.

The problem: Terraform's S3 backend always looks for the DynamoDB lock table in the caller's account. So when authenticated as dev account, it looks for the lock table in dev - not in the shared account where it actually exists.

The fix: Add a profile to the backend config pointing to the shared account:

backend "s3" {
  bucket         = "my-tf-states"
  region         = "us-east-1"
  key            = "core.tfstate"
  dynamodb_table = "terraform-locks"
  profile        = "shared-account"
}

This ensures both S3 and DynamoDB calls go to the shared account, while the provider uses your SSO profile for the target account.

You'll also need an S3 bucket policy on the state bucket to allow cross-account access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TerraformStateAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::<dev_account_id>:root",
          "arn:aws:iam::<live_account_id>:root"
        ]
      },
      "Action": [
        "s3:ListBucket",
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::my-tf-states",
        "arn:aws:s3:::my-tf-states/*"
      ]
    }
  ]
}

After changing the backend config, reinitialize:

terraform init -reconfigure

Step 3: Set Up AWS SSO Profiles

Each engineer adds profiles to their ~/.aws/config - one per account:

# Dev account
[profile dev]
sso_start_url = https://your-org.awsapps.com/start/#/
sso_region = us-east-1
sso_account_id = <dev_account_id>
sso_role_name = SuperAdmin
region = us-east-1

# Production account
[profile prod]
sso_start_url = https://your-org.awsapps.com/start/#/
sso_region = us-east-1
sso_account_id = <live_account_id>
sso_role_name = SuperAdmin
region = us-east-1

# Shared account (for Terraform state backend)
[profile shared-account]
sso_start_url = https://your-org.awsapps.com/start/#/
sso_region = us-east-1
sso_account_id = <shared_account_id>
sso_role_name = SuperAdmin
region = us-east-1

Replace SuperAdmin with your SSO permission set name.

If you manage Linux servers alongside your Terraform infra, LinuxTools.app is a handy CLI reference I use daily.

Step 4: Run Terraform Locally

# Login to SSO (opens browser for authentication)
aws sso login --profile dev
aws sso login --profile shared-account

# IMPORTANT: Clear any old static credentials first
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

# Set the profile for the target account
export AWS_PROFILE=dev

# Verify you're using the SSO role (not the old IAM user)
aws sts get-caller-identity
# Should show: arn:aws:sts::<dev_account_id>:assumed-role/AWSReservedSSO_SuperAdmin_.../you@company.com

# Run Terraform
terraform init
terraform workspace select dev
terraform plan
terraform apply

Gotcha: If AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY are set in your environment, they take precedence over AWS_PROFILE. Always unset them first. I spent a while debugging this - aws sts get-caller-identity kept showing the old user/deployment identity.

Step 5: Set Up GitHub Actions with OIDC

We already had an OIDC provider configured in AWS using the unfunco/oidc-github/aws module. If you don't have one yet, add it:

module "oidc_github" {
  source  = "unfunco/oidc-github/aws"
  version = "1.8.0"

  github_repositories = [
    "your-org/your-terraform-repo"
  ]

  attach_admin_policy = true
}

output "oidc_role_arn" {
  value = module.oidc_github.iam_role_arn
}

Then update the GitHub Actions workflow:

Before (static keys):

permissions:
  contents: read

steps:
  - name: Configure AWS Credentials
    uses: aws-actions/configure-aws-credentials@v4
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: us-east-1

After (OIDC):

permissions:
  id-token: write   # Required for OIDC
  contents: read

steps:
  - name: Configure AWS Credentials
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: ${{ secrets.AWS_OIDC_ROLE_ARN }}
      aws-region: us-east-1

Key changes:

Added id-token: write permission (required for GitHub to issue OIDC tokens)
Replaced aws-access-key-id / aws-secret-access-key with role-to-assume

Set AWS_OIDC_ROLE_ARN per GitHub environment:

development environment: OIDC role ARN from your dev account
production environment: OIDC role ARN from your prod account

Step 6: Upgrade AWS Provider and Modules

After switching to SSO, I hit this error on terraform plan:

An argument named "enable_classiclink" is not expected here.

This happened because we were on AWS provider 4.67 and VPC module 3.18.1. EC2-Classic was fully retired by AWS, and these older versions still reference deprecated classiclink attributes.

The fix:

# Provider: 4.67 -> 5.x
required_providers {
  aws = {
    source  = "hashicorp/aws"
    version = "~> 5.0"
  }
}

# VPC module: 3.18.1 -> 5.16.0
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.16.0"
}

Then run:

terraform init -upgrade

Step 7: Migrate Module Sources from S3 to GitHub

We had custom Terraform modules stored in an S3 bucket:

module "my_module" {
  source = "s3::/my-tf-modules/1.0.41/my-module.zip"
}

After switching to SSO, terraform init failed with:

NoCredentialProviders: no valid providers in chain

The root cause: Terraform's module downloader uses the Go AWS SDK internally, which does not respect AWS_PROFILE when downloading S3 sources. The cleanest fix was switching to GitHub as the module source:

module "my_module" {
  source = "github.com/your-org/your-tf-modules//my-module?ref=v1.0.93"
}

Common Pitfalls

1. Old credentials overriding SSO

Environment variables take precedence over AWS_PROFILE. Always clear them first:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

2. DynamoDB lock table not found in the right account

Without profile in the backend config, you'll get:

AccessDeniedException: User is not authorized to perform: dynamodb:PutItem

3. S3 module downloads failing with NoCredentialProviders

Switch to GitHub-hosted modules or export credentials before terraform init:

eval "$(aws configure export-credentials --profile dev --format env)"
terraform init

4. Missing id-token: write permission in GitHub Actions

OIDC requires id-token: write permission. Without it, the OIDC token request fails silently.

5. Backend configuration changed error

After adding profile to the backend:

Error: Backend configuration changed

Run terraform init -reconfigure to fix.

Summary

Component	Before	After
Local auth	Shared `deployment` IAM user + static keys	Individual SSO login per engineer
CI/CD auth	Static keys in GitHub secrets	OIDC federation (no secrets needed)
Provider config	`assume_role` to `deployment` role	No assume_role (uses env credentials)
State backend	Direct access from shared account	`profile` pointing to shared account
Audit trail	"deployment" user for everyone	Individual engineer identity in CloudTrail
Key rotation	Manual, painful, shared	Automatic, per-session, no keys to manage
Module sources	S3 bucket (breaks with SSO)	GitHub repo (uses git credentials)
AWS provider	4.67	~> 5.0
VPC module	3.18.1	5.16.0

The migration took some troubleshooting, but the security benefits are significant. Every terraform apply is now traceable to an individual engineer in CloudTrail, credentials are short-lived and automatically rotated, and there are no static keys to leak or manage.

If you are working with Linux servers as part of your infrastructure, check out LinuxTools.app - a free reference for CLI commands and utilities I use daily.

Written by Khimananda Oli. Find more DevOps and cloud infrastructure content at khimananda.com.

I Built 30 Free Browser-Based Linux & DevOps Tools — Here's What I Learned

khimananda Oli — Mon, 23 Mar 2026 07:15:53 +0000

Every time I needed to calculate a subnet, generate a cron expression, or decode a JWT, I'd end up on some ad-infested site that wanted me to sign up, install an extension, or — worst of all — send my data to their server.

So I built LinuxTools.app — 30 free tools that run entirely in your browser. No sign-up. No tracking. No data leaves your machine.

Here's what I built and what I learned along the way.

What's Inside

The tools are organized into three categories:

🐧 Linux Tools (15)

These are the ones I use daily as a sysadmin:

Chmod Calculator — Visual permission calculator. Toggle rwx checkboxes, see the numeric value update in real-time. Way faster than doing the math in your head.
Cron Expression Generator — Build cron jobs visually with a preview of the next 5 execution times. No more guessing if */5 * * * * means every 5 minutes or every 5th minute.
SSH Config Generator — Build ~/.ssh/config visually. Add hosts, keys, tunnels, and proxy jumps without remembering the syntax.
Nginx Config Generator — Generate configs for reverse proxy, SSL termination, redirects, and more.
Systemd Unit File Builder — Create service files visually instead of copy-pasting from StackOverflow.
UFW / iptables Rule Generator — Build firewall rules without memorizing flags.
Server Hardening Checklist — Step-by-step security checklist with actual commands.

Plus: File Permission Converter, Linux Command Cheat Sheets, Shell Script Library, Vim/Nano shortcuts, Package Manager Comparison, Disk Usage Visualizer, Process Explorer, and Performance Analyzer.

☁️ Cloud & DevOps (5)

Subnet Calculator — CIDR notation, network/broadcast addresses, host ranges
Dockerfile Generator — Pick base image, add packages, expose ports, generate
Kubernetes YAML Generator — Deployments, services, ingress configs
Terraform Snippet Generator — AWS/GCP/Azure resource templates
Cloud Cost Calculator — Estimate costs across providers

🔧 Utilities (9)

Base64 Encoder/Decoder
JSON/YAML/TOML Converter
Regex Tester — Real-time match highlighting
Git Command Builder — Pick what you want to do, get the command
SSL Certificate Checker
UUID Generator — v1/v3/v4/v5 with bulk generation
JSON to .env Converter — AWS Secrets Manager / Vault JSON → dotenv
JWT Encoder/Decoder — Inspect headers, payloads, verify HMAC signatures
Network Tools — DNS lookup, WHOIS, reverse DNS, HTTP headers, and more

🛡️ NetOps — Network Reconnaissance

I also built a NetOps section with a self-hosted API backend:

Traceroute, Ping, MTR
DNS Lookup, Reverse DNS
WHOIS, GeoIP, ASN Lookup
Nmap scan, HTTP Headers, Page Links
Subnet Calculator

All powered by a FastAPI backend in Docker with local MaxMind GeoIP databases — zero external API dependencies.

The Tech Stack

Frontend:  Next.js 15 (static export) + TypeScript + Tailwind CSS
Backend:   Python FastAPI (Docker) — for network tools only
Fonts:     Inter (body) + JetBrains Mono (code) + Bebas Neue (display)
Hosting:   Self-hosted on a VPS behind Cloudflare
Deploy:    rsync + Docker Compose

Why Static Export?

Most tools are pure client-side JavaScript. No server needed for chmod calculations or cron parsing. Static export means:

Fast — HTML served directly by nginx
Cheap — No server-side rendering costs
Private — Data never leaves the browser
Reliable — No backend to go down

The only exception is the NetOps tools (ping, traceroute, nmap) which obviously need a server. Those run in a Docker container with a FastAPI backend.

Lessons Learned

1. Client-side tools are underrated

Most "online tools" unnecessarily send your data to a server. A chmod calculator doesn't need a backend. A JWT decoder doesn't need your token sent over the wire. Running everything client-side is faster, more private, and simpler to deploy.

2. The hardest part is the UI, not the logic

Calculating file permissions is trivial. Making a UI that's intuitive enough that someone can figure it out in 3 seconds — that's the actual challenge.

3. SEO matters for tools

People find tools through Google. Every tool page has:

Proper <title> and <meta description>
Canonical URLs
Hidden <h1> with keyword-rich text
Structured sitemap

4. Dark theme or nothing

Developers live in dark mode. I didn't even bother with a light theme toggle. GitHub-dark inspired palette with soft blue accents.

5. Self-hosting network tools requires security

When I added nmap and traceroute to the API, I had to think about:

Rate limiting — 5 nmap scans per 5 minutes
Internal IP blocking — Can't scan 192.168.x.x or 10.x.x.x
API key auth — Injected by nginx, never reaches the browser
Input validation — Strict regex on all inputs

What's Next

Some features on the roadmap based on user feedback:

Cmd+K search — Global keyboard shortcut to find tools instantly
Pin/favorite tools — Quick access to your most-used tools
Form state persistence — So you don't lose data on accidental refresh
More pentest tools — Building on the FastAPI backend

Try It Out

👉 linuxtools.app

All tools are free. No sign-up. No ads (ok, there's AdSense, but no paywalls).

If you find it useful, I'd love to hear which tools you use the most — or what tools you wish existed.

Drop a comment below or reach out on the contact page.

Built with ☕ and too many terminal sessions.

Reverse Proxy for Node.js — Nginx and Apache2 Side by Side

khimananda Oli — Tue, 17 Mar 2026 17:59:37 +0000

In Part 1, we set up NVM and PM2. In Part 2, we started the Node.js application. Now let's put a reverse proxy in front of it.

Why a Reverse Proxy?

Your Node.js app should never be directly exposed on port 80 or 443. A reverse proxy handles:

SSL/TLS termination — Node doesn't deal with certificates
Security headers — added at the proxy layer
Static file serving — offload from Node
Request buffering — protects Node from slow clients
Centralized access logs

Both Nginx and Apache2 get the job done. Pick whichever is already in your stack.

Nginx

Install

sudo apt update && sudo apt install -y nginx

Configuration

# /etc/nginx/sites-available/myapp.conf

upstream node_backend {
    server 127.0.0.1:3000;
    keepalive 64;
}

server {
    listen 80;
    server_name myapp.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name myapp.example.com;

    # SSL
    ssl_certificate     /etc/letsencrypt/live/myapp.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.example.com/privkey.pem;

    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Proxy
    location / {
        proxy_pass http://node_backend;
        proxy_http_version 1.1;

        # WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_cache_bypass $http_upgrade;

        # Pass client info
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouts
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    # Static files — serve directly, skip Node
    location /static/ {
        alias /opt/myapp/public/;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # Health check — suppress access logs
    location /health {
        proxy_pass http://node_backend;
        access_log off;
    }
}

Enable and Test

sudo ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Apache2

Install and Enable Modules

sudo apt update && sudo apt install -y apache2
sudo a2enmod proxy proxy_http proxy_wstunnel rewrite ssl headers
sudo systemctl restart apache2

Configuration

# /etc/apache2/sites-available/myapp.conf

<VirtualHost *:80>
    ServerName myapp.example.com

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName myapp.example.com

    SSLEngine On
    SSLCertificateFile    /etc/letsencrypt/live/myapp.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/myapp.example.com/privkey.pem

    # Security headers
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Proxy to Node.js
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    # WebSocket support
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} =websocket [NC]
    RewriteRule /(.*) ws://127.0.0.1:3000/$1 [P,L]

    # Pass real client IP
    RequestHeader set X-Real-IP "%{REMOTE_ADDR}s"
    RequestHeader set X-Forwarded-Proto "https"

    # Timeout
    ProxyTimeout 60

    # Static files
    Alias /static /opt/myapp/public
    <Directory /opt/myapp/public>
        Require all granted
        Options -Indexes
        Header set Cache-Control "public, max-age=2592000, immutable"
    </Directory>

    # Logging
    ErrorLog ${APACHE_LOG_DIR}/myapp-error.log
    CustomLog ${APACHE_LOG_DIR}/myapp-access.log combined
</VirtualHost>

Enable and Test

sudo a2ensite myapp.conf
sudo a2dissite 000-default.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

SSL with Let's Encrypt

# Nginx
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d myapp.example.com

# Apache2
sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache -d myapp.example.com

Verify auto-renewal:

sudo certbot renew --dry-run

If you already have certs (corporate CA, wildcard), just point the config to your cert and key paths.

Trust the Proxy in Your Node App

Your app needs to know it's behind a proxy to read the real client IP from X-Forwarded-For:

// Express
app.set('trust proxy', 1);

Without this, req.ip will always return 127.0.0.1.

Nginx vs Apache2 — Comparison

	Nginx	Apache2
Architecture	Event-driven, non-blocking	Process/thread per connection
Memory	Low footprint	Higher under load
Static files	Extremely fast	Good, not as fast
WebSocket	Native support	Needs `mod_proxy_wstunnel` + rewrite
SSL	Built-in	Needs `mod_ssl`
Load balancing	Built-in `upstream`	Needs `mod_proxy_balancer`
`.htaccess`	Not supported	Supported
Config reload	`nginx -t && systemctl reload`	`apache2ctl configtest && systemctl reload`
Best for	New setups, high concurrency	Legacy stacks, PHP apps

Bottom line: Starting fresh → Nginx. Apache2 already in your stack → stick with it.

Verify the Full Stack

# PM2 running?
pm2 status

# Port listening?
ss -tlnp | grep 3000

# Reverse proxy responding?
curl -I https://myapp.example.com

# SSL valid?
echo | openssl s_client -connect myapp.example.com:443 2>/dev/null \
  | grep 'Verify return code'

# Proxy logs
sudo tail -f /var/log/nginx/access.log          # Nginx
sudo tail -f /var/log/apache2/myapp-access.log   # Apache2

The Full Stack

Client (HTTPS:443)
    │
    ▼
┌──────────────────────┐
│  Nginx / Apache2     │  ← SSL, headers, static files
│  (port 80/443)       │
└──────────┬───────────┘
           │ proxy_pass http://127.0.0.1:3000
           ▼
┌──────────────────────┐
│  PM2 (cluster mode)  │  ← Process management, restarts
├──────────────────────┤
│  Node.js app         │  ← server.js / app.js
│  (port 3000)         │
└──────────────────────┘
           │
     NVM-managed Node binary
     ~/.nvm/versions/node/v20.18.0/bin/node

Series Recap

Part 1 — NVM, PM2, startup scripts, log rotation
Part 2 — Running the app, cluster mode, memory limits, monitoring
Part 3 — Reverse proxy (Nginx + Apache2), SSL, security headers, verification

This stack is simple, debuggable, and production-proven. No containers, no orchestration overhead — just a Node app running reliably behind a proper proxy.

Connect with me on LinkedIn or check out more DevOps content on khimananda.com.

Setting Up NVM, PM2, and Process Management on Linux

khimananda Oli — Tue, 17 Mar 2026 16:50:05 +0000

Why NVM Over System Node?

Don't apt install nodejs. You'll get a stale version pinned to your distro's release cycle, and switching between projects that need different Node versions becomes a mess.

NVM gives you per-user Node version management with zero system-level conflicts.

Install NVM

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

Reload your shell:

source ~/.bashrc

Verify:

nvm --version
# 0.40.1

Install Node.js

# Install LTS
nvm install --lts

# Or a specific version
nvm install 20.18.0

# Set default — without this, new shells may pick a different version
nvm alias default 20.18.0

# Verify
node -v && npm -v

Where Does Node Live?

NVM installs per-user. Your Node binary path looks like:

/home/deploy/.nvm/versions/node/v20.18.0/bin/node

This matters when PM2 needs to register a systemd service. Keep it in mind.

Install PM2

npm install -g pm2

Since we used NVM, PM2 lives at:

~/.nvm/versions/node/v20.18.0/bin/pm2

Quick sanity check:

pm2 --version

PM2 Startup — Survive Reboots

This is where NVM + PM2 gets tricky. PM2's startup script needs the full path to the Node binary because systemd runs non-interactively — NVM isn't loaded in that context.

Generate the startup script:

pm2 startup systemd

PM2 will print a command like:

sudo env PATH=$PATH:/home/deploy/.nvm/versions/node/v20.18.0/bin \
  /home/deploy/.nvm/versions/node/v20.18.0/lib/node_modules/pm2/bin/pm2 \
  startup systemd -u deploy --hp /home/deploy

Copy and run that exact command. Don't modify it.

Then save the current process list:

pm2 save

PM2 will now resurrect all managed apps on reboot.

The Stale `dump.pm2` Trap

If PM2 keeps resurrecting old or dead processes after a restart, it's because pm2 save wrote a dump.pm2 file with stale state.

Fix:

pm2 kill
rm -f ~/.pm2/dump.pm2
# start your apps again (covered in Part 2)
pm2 save

Always run pm2 save after any change to your process list. Forgetting this will bite you at 3 AM when the server reboots and your app doesn't come back.

PM2 Log Rotation

By default, PM2 logs grow unbounded. In production, that's a disk space incident waiting to happen.

Option A: pm2-logrotate (Recommended)

pm2 install pm2-logrotate

pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 10
pm2 set pm2-logrotate:compress true
pm2 set pm2-logrotate:dateFormat YYYY-MM-DD_HH-mm-ss
pm2 set pm2-logrotate:workerInterval 30
pm2 set pm2-logrotate:rotateInterval '0 0 * * *'

Verify:

pm2 conf pm2-logrotate

Option B: System logrotate

If you prefer the OS-level approach:

# /etc/logrotate.d/pm2-myapp
/home/deploy/.pm2/logs/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    copytruncate
}

Use copytruncate — PM2 holds the file handle open, so you can't move the log file out from under it.

Quick Reference — PM2 Commands

pm2 status              # list all managed processes
pm2 logs                # tail all logs
pm2 logs myapp          # tail specific app
pm2 monit               # real-time CPU/memory dashboard
pm2 reload myapp        # zero-downtime reload (cluster mode)
pm2 restart myapp       # hard restart
pm2 stop myapp          # stop without removing
pm2 delete myapp        # stop and remove from list
pm2 save                # persist process list
pm2 resurrect           # restore saved list

What We Have So Far

At this point:

✅ NVM installed with a pinned Node.js version
✅ PM2 installed globally via NVM
✅ Startup script registered — apps survive reboots
✅ Log rotation configured — no disk space surprises

Follow for Part 2 — Running Your Node.js Application with PM2

Running Your Node.js Application with PM2

khimananda Oli — Tue, 17 Mar 2026 16:46:29 +0000

In Part 1, we installed NVM, PM2, configured log rotation, and set up startup scripts. Now let's run the actual application.

Prerequisites

NVM, Node.js, and PM2 installed (Part 1)
A Node.js application with a server.js or app.js entry point
Dependencies installed (npm install or npm ci)

Start the Application

Single Instance

cd /opt/myapp
pm2 start server.js --name myapp

That's it. PM2 is managing the process.

pm2 status

┌────┬──────┬───────┬───┬─────┬──────────┐
│ id │ name │ mode  │ ↺ │ cpu │ memory   │
├────┼──────┼───────┼───┼─────┼──────────┤
│ 0  │ myapp│ fork  │ 0 │ 0%  │ 45.2 MB  │
└────┴──────┴───────┴───┴─────┴──────────┘

Cluster Mode — Use All CPU Cores

If your app is stateless (no in-memory sessions), cluster mode spawns one process per CPU core:

pm2 start server.js --name myapp -i max

┌────┬──────┬─────────┬───┬─────┬──────────┐
│ id │ name │ mode    │ ↺ │ cpu │ memory   │
├────┼──────┼─────────┼───┼─────┼──────────┤
│ 0  │ myapp│ cluster │ 0 │ 0%  │ 42.1 MB  │
│ 1  │ myapp│ cluster │ 0 │ 0%  │ 41.8 MB  │
│ 2  │ myapp│ cluster │ 0 │ 0%  │ 42.3 MB  │
│ 3  │ myapp│ cluster │ 0 │ 0%  │ 41.5 MB  │
└────┴──────┴─────────┴───┴─────┴──────────┘

Or specify a fixed count:

pm2 start server.js --name myapp -i 2

With Environment Variables

PORT=3000 NODE_ENV=production pm2 start server.js --name myapp -i max

Or pass them explicitly:

pm2 start server.js --name myapp --env production \
  --node-args="--max-old-space-size=512" \
  -- --port 3000

With a `.env` File

If your app uses dotenv, just make sure the .env file is in the app's working directory. PM2 runs from the directory where you execute the start command.

cd /opt/myapp
# .env file sits here alongside server.js
pm2 start server.js --name myapp

Memory Limit — Auto Restart on OOM

Set a memory ceiling so a leaky app doesn't eat the whole server:

pm2 start server.js --name myapp --max-memory-restart 512M

When any instance exceeds 512MB, PM2 restarts it automatically.

Watching for File Changes (Dev/Staging Only)

pm2 start server.js --name myapp --watch --ignore-watch="node_modules logs"

Don't use --watch in production. A deployment that touches multiple files triggers multiple restarts. Use pm2 reload instead.

Zero-Downtime Reload

In cluster mode, reload restarts workers one at a time — no dropped requests:

pm2 reload myapp

In fork mode (single instance), reload behaves like restart — there will be a brief downtime.

Verify the Application

# PM2 status
pm2 status

# Port listening?
ss -tlnp | grep 3000

# Hit the app
curl http://localhost:3000

# Logs
pm2 logs myapp --lines 50

Save the Process List

After starting your app, always save:

pm2 save

This writes the current process list to ~/.pm2/dump.pm2. On reboot, the startup script from Part 1 calls pm2 resurrect and restores everything.

Skip pm2 save and your app won't come back after a reboot. Simple as that.

Managing Multiple Applications

PM2 handles multiple apps without issue:

pm2 start /opt/app1/server.js --name api -i 2
pm2 start /opt/app2/app.js --name frontend
pm2 start /opt/app3/worker.js --name worker

pm2 save

┌────┬──────────┬─────────┬───┬─────┬──────────┐
│ id │ name     │ mode    │ ↺ │ cpu │ memory   │
├────┼──────────┼─────────┼───┼─────┼──────────┤
│ 0  │ api      │ cluster │ 0 │ 0%  │ 42.1 MB  │
│ 1  │ api      │ cluster │ 0 │ 0%  │ 41.8 MB  │
│ 2  │ frontend │ fork    │ 0 │ 0%  │ 38.5 MB  │
│ 3  │ worker   │ fork    │ 0 │ 0%  │ 35.2 MB  │
└────┴──────────┴─────────┴───┴─────┴──────────┘

Monitoring

Real-Time Dashboard

pm2 monit

Terminal UI showing CPU, memory, logs, and metadata per process.

Quick Health Check

pm2 show myapp

Outputs uptime, restart count, memory usage, log file paths, and more.

Troubleshooting

App crash-looping:

pm2 logs myapp --err --lines 100

Common culprits: missing env vars, port conflicts, unhandled promise rejections.

Port already in use:

sudo lsof -i :3000

PM2 shows errored status:

pm2 describe myapp

High restart_time = crash loop. Check error logs.

What We Have So Far

✅ Part 1: NVM + PM2 + startup + log rotation
✅ Part 2: App running with PM2, cluster mode, memory limits, zero-downtime reloads

The app is running on localhost:3000 but not exposed to the internet yet.

Follow for Part 3 — Reverse Proxy with Nginx and Apache2

Running Multiple Java Apps with Different JDK Versions on One Server

khimananda Oli — Thu, 19 Feb 2026 09:03:10 +0000

Running Multiple Java Apps with Different JDK Versions on One Server

Got microservices on different Java versions? Need to run them on one box? Here's the no-BS guide.

TL;DR

Install multiple JDKs via package manager (they coexist fine)
Use absolute paths to Java binary in systemd services
Don't rely on JAVA_HOME or system default
Plan memory — multiple JVMs add up fast

The Problem

Linux has one java in PATH. Running java -jar app.jar uses whatever that default is.

Your apps need Java 11, 17, and 21. Now what?

Solution: Don't use the default. Point each app to its specific Java binary.

Step 1: Install Multiple JDKs

Ubuntu/Debian

apt update
apt install -y openjdk-11-jre-headless \
               openjdk-17-jre-headless \
               openjdk-21-jre-headless

Amazon Linux / RHEL

yum install -y java-11-amazon-corretto-headless \
               java-17-amazon-corretto-headless \
               java-21-amazon-corretto-headless

Verify

ls /usr/lib/jvm/

Paths you'll see:

Distro	Java 11	Java 17	Java 21
Ubuntu	`/usr/lib/jvm/java-11-openjdk-amd64`	`/usr/lib/jvm/java-17-openjdk-amd64`	`/usr/lib/jvm/java-21-openjdk-amd64`
Amazon Linux	`/usr/lib/jvm/java-11-amazon-corretto`	`/usr/lib/jvm/java-17-amazon-corretto`	`/usr/lib/jvm/java-21-amazon-corretto`

Step 2: Systemd Services with Explicit Java Paths

Java 11 App

# /etc/systemd/system/legacy-api.service
[Unit]
Description=Legacy API (Java 11)
After=network.target

[Service]
User=appuser
WorkingDirectory=/opt/apps/legacy-api

ExecStart=/usr/lib/jvm/java-11-openjdk-amd64/bin/java \
    -Xms256m -Xmx512m \
    -jar /opt/apps/legacy-api/legacy-api.jar

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Java 17 App

# /etc/systemd/system/main-api.service
[Unit]
Description=Main API (Java 17)
After=network.target

[Service]
User=appuser
WorkingDirectory=/opt/apps/main-api

ExecStart=/usr/lib/jvm/java-17-openjdk-amd64/bin/java \
    -Xms512m -Xmx1g \
    -XX:+UseG1GC \
    -jar /opt/apps/main-api/main-api.jar

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Java 21 App (with ZGC)

# /etc/systemd/system/new-api.service
[Unit]
Description=New API (Java 21)
After=network.target

[Service]
User=appuser
WorkingDirectory=/opt/apps/new-api

ExecStart=/usr/lib/jvm/java-21-openjdk-amd64/bin/java \
    -Xms512m -Xmx1g \
    -XX:+UseZGC \
    -XX:+ZGenerational \
    -jar /opt/apps/new-api/new-api.jar

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Enable All

systemctl daemon-reload
systemctl enable --now legacy-api main-api new-api

Step 3: Using Environment Files (Cleaner)

For multiple apps, use .env files:

# /opt/apps/main-api/.env
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
JAVA_OPTS=-Xms512m -Xmx1g -XX:+UseG1GC
APP_PORT=8082

# /etc/systemd/system/main-api.service
[Service]
User=appuser
EnvironmentFile=/opt/apps/main-api/.env
ExecStart=/bin/bash -c 'exec $JAVA_HOME/bin/java $JAVA_OPTS -Dserver.port=$APP_PORT -jar /opt/apps/main-api/main-api.jar'
Restart=always

⚠️ Why bash wrapper? Systemd doesn't do shell-style variable expansion. ${JAVA_HOME} in ExecStart is passed as literal string. Wrapping in bash -c fixes this.

Bonus: ASG User Data Script

For Auto Scaling Groups — generate services dynamically at boot:

#!/bin/bash
set -e

# Install JDKs
yum install -y java-11-amazon-corretto-headless \
               java-17-amazon-corretto-headless \
               java-21-amazon-corretto-headless

# Config: name|java_version|s3_path|port|heap
APPS=(
  "legacy-api|11|s3://bucket/legacy-api.jar|8081|512m"
  "main-api|17|s3://bucket/main-api.jar|8082|1g"
  "new-api|21|s3://bucket/new-api.jar|8083|1g"
)

mkdir -p /opt/apps

for app_config in "${APPS[@]}"; do
  IFS='|' read -r name java_ver s3_path port heap <<< "$app_config"

  mkdir -p /opt/apps/${name}
  aws s3 cp ${s3_path} /opt/apps/${name}/${name}.jar

  JAVA_BIN="/usr/lib/jvm/java-${java_ver}-amazon-corretto/bin/java"

  cat <<EOF > /etc/systemd/system/${name}.service
[Unit]
Description=${name} (Java ${java_ver})
After=network.target

[Service]
User=ec2-user
ExecStart=${JAVA_BIN} -Xms256m -Xmx${heap} -Dserver.port=${port} -jar /opt/apps/${name}/${name}.jar
Restart=always

[Install]
WantedBy=multi-user.target
EOF

done

systemctl daemon-reload

for app_config in "${APPS[@]}"; do
  name=$(echo $app_config | cut -d'|' -f1)
  systemctl enable --now ${name}
done

Memory Planning

Multiple JVMs = plan carefully.

t3.large (8 GB) example:

OS reserved:     ~1 GB
legacy-api:      -Xmx512m
main-api:        -Xmx1g  
new-api:         -Xmx1g
worker:          -Xmx512m
scheduler:       -Xmx256m
----------------------------
Total heap:      ~3.3 GB
With overhead:   ~5-6 GB
Buffer:          ~2 GB ✅

JVMs use more than heap (metaspace, threads, native). Leave buffer.

Verify Runtime Versions

# Quick check
ps aux | grep java

# Detailed
for pid in $(pgrep -f "java.*jar"); do
  echo "=== PID: $pid ==="
  cat /proc/$pid/cmdline | tr '\0' ' '
  echo
done

Output:

=== PID: 1234 ===
/usr/lib/jvm/java-11-openjdk-amd64/bin/java -Xms256m -jar /opt/apps/legacy-api.jar

=== PID: 1235 ===
/usr/lib/jvm/java-17-openjdk-amd64/bin/java -Xms512m -jar /opt/apps/main-api.jar

Quick Reference

Task	Command
List JDKs	`ls /usr/lib/jvm/`
Check default	`java -version`
Change default	`update-alternatives --config java`
Find process Java	`ls -l /proc/<PID>/exe`

When NOT to Use This

Use containers instead when:

✅ Need independent scaling per service
✅ High deploy frequency
✅ Team prefers immutable infra

EC2 multi-JVM approach = cost savings, more ops overhead.

Wrapping Up

Running multiple Java versions on one server:

Install all versions via package manager
Use absolute paths in systemd services
Never rely on system defaults
Plan memory — JVMs add up fast

No SDKMAN complexity. No Docker overhead. Just explicit paths and systemd.

Questions? Drop them below. 👇

Environment Variable Naming Will Break Your App — Here's How Docker, systemd, and Kubernetes Handle It Differently

khimananda Oli — Wed, 18 Feb 2026 10:56:02 +0000

A Spring Boot application was crash-looping over 5,000 times on an EC2 instance managed by systemd. The logs showed nothing obvious — just status=1/FAILURE every 30 seconds. No connection errors, no missing JARs, no OOM kills.

The culprit? Hyphens in environment variable names.

PAYMENT-API-PROTOCOL=https
PAYMENT-API-HOST=10.0.1.50:8080
PAYMENT-CRED-USERNAME=svc-account

These were pulled from AWS Secrets Manager and written to a .env file. The systemd service used EnvironmentFile to load them. And systemd was silently ignoring every single one:

Ignoring invalid environment assignment 'PAYMENT-API-PROTOCOL=https'
Ignoring invalid environment assignment 'PAYMENT-CRED-USERNAME=svc-account'

The kicker? The exact same .env file worked perfectly in Docker.

The Rules Are Different Everywhere

Environment variable naming isn't universal. Each runtime has its own rules, and what works in one will silently break in another.

POSIX Standard (What Most Things Follow)

The POSIX specification for environment variables says names must match:

[a-zA-Z_][a-zA-Z0-9_]*

That's letters, digits, and underscores only. No hyphens, no dots, no special characters. The name must start with a letter or underscore.

Most Linux tooling follows this — bash, sh, env, export, systemd, and core utilities all enforce or expect POSIX-compliant names.

Docker: The Permissive One

Docker's --env-file parser is lenient. It accepts hyphens, dots, and other characters in variable names that POSIX wouldn't allow:

# docker-compose.yml or --env-file
PAYMENT-API-PROTOCOL=https    # ✅ works in Docker
my.app.config=value           # ✅ works in Docker

Docker passes these directly to the container's process environment without validation. The container runtime doesn't care — it just injects whatever key-value pairs you give it.

This is why teams that develop exclusively in Docker containers often don't realize they're using non-standard variable names — until they deploy to bare metal or systemd-managed services.

systemd: Strict POSIX

systemd's EnvironmentFile directive follows POSIX rules strictly. If a variable name contains a hyphen, systemd silently drops it with a log warning:

Ignoring invalid environment assignment 'PAYMENT-API-PROTOCOL=https'

The word "silently" is doing a lot of heavy lifting here. The service still starts. The variable just isn't there. Your application boots, can't find the config it needs, and crashes — often with a confusing error that points at dependency injection or missing beans, not at the actual missing variable.

# /etc/systemd/system/myapp.service
[Service]
EnvironmentFile=/opt/app/.env
ExecStart=/usr/bin/java -jar /opt/app/myapp.jar

# .env file
PAYMENT_API_PROTOCOL=https    # ✅ loaded
PAYMENT-API-PROTOCOL=https    # ❌ silently ignored

Kubernetes: POSIX with DNS Flexibility

Kubernetes ConfigMaps and Secrets follow POSIX for environment variable names injected via envFrom or env. But there's a nuance — ConfigMap keys can contain hyphens and dots because they can also be mounted as files:

# ConfigMap keys can have hyphens
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  PAYMENT_API_PROTOCOL: "https"        # ✅ works as env var
  payment-api-protocol: "https"        # ⚠️ works as file mount, NOT as env var

When you mount a ConfigMap as a volume, each key becomes a filename — and filenames can have hyphens. But if you use envFrom to inject them as environment variables, Kubernetes will skip keys that aren't valid POSIX variable names:

# This will silently skip non-POSIX keys
envFrom:
  - configMapRef:
      name: app-config

Kubernetes logs a warning event on the pod, but unless you're watching events closely, you'll miss it — just like systemd.

The Comparison Table

Feature	Docker	systemd	Kubernetes (env)	Kubernetes (volume)
Underscores	✅	✅	✅	✅
Hyphens	✅	❌ Silent drop	❌ Silent skip	✅ (as filename)
Dots	✅	❌ Silent drop	❌ Silent skip	✅ (as filename)
Error on invalid	No	Warning in journal	Event on pod	N/A
POSIX compliant	No	Yes	Yes	N/A

The Real Danger: Silent Failures

The common thread across systemd and Kubernetes is silent failure. The variable isn't there, but nothing crashes at the system level — the process starts, tries to read the missing config, and fails with an application-level error.

In the incident that prompted this article, the Spring Boot error was:

Caused by: java.lang.IllegalArgumentException: 
  Could not resolve placeholder 'PAYMENT_API_HOST' in value "${PAYMENT_API_HOST}"

This looks like a missing property issue. It is — but the root cause was three layers deep: Secrets Manager had hyphens → systemd dropped the variables → Spring couldn't find them.

Best Practices

1. Use Underscores Everywhere

Just use SCREAMING_SNAKE_CASE for all environment variables. It's POSIX-compliant and works everywhere — Docker, systemd, Kubernetes, bash, CI/CD pipelines, Lambda, ECS, everything.

# Do this
PAYMENT_API_PROTOCOL=https
PAYMENT_CRED_USERNAME=myuser

# Not this
PAYMENT-API-PROTOCOL=https
payment.api.protocol=https

2. Validate at Deploy Time

Add a preflight check in your deployment scripts that verifies all required variables are present before restarting the service:

REQUIRED_VARS="DB_HOST DB_PORT API_KEY SECRET_TOKEN"

for var in $REQUIRED_VARS; do
  grep -q "^${var}=" .env || { echo "FATAL: Missing $var in .env"; exit 1; }
done

systemctl restart myapp

This takes 5 lines and prevents crash loops at 3 AM.

3. Transform at the Boundary

If you can't control the source (like a third-party Secrets Manager with legacy keys), transform at the boundary — the point where secrets are pulled into the runtime:

# In deploy.sh — transform hyphens to underscores when pulling from Secrets Manager
aws secretsmanager get-secret-value \
  --secret-id myapp.prod \
  --query SecretString --output text \
  | jq -r 'to_entries|map("\(.key | gsub("-";"_"))=\(.value|tostring)")|.[]' > .env

4. Spring Boot Property Naming

Spring Boot has its own relaxed binding that maps environment variables to properties. Use this to your advantage:

# application.properties
# Spring property with dots — reads from PAYMENT_API_PROTOCOL env var automatically
payment.api.protocol=${PAYMENT_API_PROTOCOL}

But be careful with circular references. If your property name and placeholder are identical:

# ❌ Circular reference — Spring resolves against itself
PAYMENT_API_HOST=${PAYMENT_API_HOST}

# ✅ Different names — env var resolves correctly
payment.api.host=${PAYMENT_API_HOST}

5. Use `systemd-analyze` to Verify

Before deploying, verify your environment file is valid:

systemd-analyze verify /etc/systemd/system/myapp.service

Or manually test what systemd will actually load:

systemd-run --property=EnvironmentFile=/opt/app/.env /usr/bin/env

Wrapping Up

Environment variable naming is one of those things that "just works" until it doesn't. Docker's permissiveness masks issues that surface the moment you move to systemd or Kubernetes. The fix is simple — stick to POSIX-compliant names (letters, digits, underscores) and validate at deploy time.

The 5,000+ restarts and hours of debugging could have been avoided with two things: underscores instead of hyphens, and a 5-line validation script in the deployment pipeline.

Sometimes the smallest characters cause the biggest outages.

Have you run into similar environment variable gotchas? Drop your war stories in the comments 👇

If you enjoyed this article, you can read more DevOps and infrastructure engineering content on my personal website:

👉 https://khimananda.com
``

Forem: khimananda Oli

Ditch Static IAM Keys: Run Terraform with AWS SSO

Our Previous Setup

The Solution: AWS SSO + OIDC

Step 1: Remove the assume_role Block

Step 2: Fix the S3 Backend for Cross-Account State Access

Step 3: Set Up AWS SSO Profiles

Step 4: Run Terraform Locally

Step 5: Set Up GitHub Actions with OIDC

Step 6: Upgrade AWS Provider and Modules

Step 7: Migrate Module Sources from S3 to GitHub

Common Pitfalls

1. Old credentials overriding SSO

2. DynamoDB lock table not found in the right account

3. S3 module downloads failing with NoCredentialProviders

4. Missing id-token: write permission in GitHub Actions

5. Backend configuration changed error

Summary

I Built 30 Free Browser-Based Linux & DevOps Tools — Here's What I Learned

What's Inside

🐧 Linux Tools (15)

☁️ Cloud & DevOps (5)

🔧 Utilities (9)

🛡️ NetOps — Network Reconnaissance

The Tech Stack

Why Static Export?

Lessons Learned

1. Client-side tools are underrated

2. The hardest part is the UI, not the logic

3. SEO matters for tools

4. Dark theme or nothing

5. Self-hosting network tools requires security

What's Next

Try It Out

Reverse Proxy for Node.js — Nginx and Apache2 Side by Side

Why a Reverse Proxy?

Nginx

Install

Configuration

Enable and Test

Apache2

Install and Enable Modules

Configuration

Enable and Test

SSL with Let's Encrypt

Trust the Proxy in Your Node App

Nginx vs Apache2 — Comparison

Verify the Full Stack

The Full Stack

Series Recap

Setting Up NVM, PM2, and Process Management on Linux

Why NVM Over System Node?

Install NVM

Install Node.js

Where Does Node Live?

Install PM2

PM2 Startup — Survive Reboots

The Stale dump.pm2 Trap

PM2 Log Rotation

Option A: pm2-logrotate (Recommended)

Option B: System logrotate

Quick Reference — PM2 Commands

What We Have So Far

Running Your Node.js Application with PM2

Prerequisites

Start the Application

Single Instance

Cluster Mode — Use All CPU Cores

With Environment Variables

With a .env File

Memory Limit — Auto Restart on OOM

Watching for File Changes (Dev/Staging Only)

Zero-Downtime Reload

Verify the Application

Save the Process List

Managing Multiple Applications

Monitoring

Real-Time Dashboard

Quick Health Check

Troubleshooting

The Stale `dump.pm2` Trap

With a `.env` File

5. Use `systemd-analyze` to Verify