Driftsätt en webbapp i Node.js eller Python

Med Node.js

Exemplet är en liten Express-app. Node.js utvecklas av sina bidragsgivare som ett projekt inom OpenJS Foundation och är öppen källkod under MIT-licensen. Paketen kommer från NodeSources paketförråd, deb.nodesource.com, som servern kontaktar vid varje apt update. npm hämtar appens beroenden från registry.npmjs.org och kollar där som standard också efter en nyare npm, vilket driftsättningen nedan stänger av.

Med Python

Exemplet är en liten Flask-app som körs av gunicorn, med en kommentar för FastAPI. Python utvecklas av sin community under Python Software Foundation, en amerikansk ideell organisation, och är öppen källkod under PSF-licensen. Det kommer från Debians egna paket. pip hämtar appens beroenden från PyPI, pypi.org, som Python Software Foundation driver.

Med Node.js

Debian 13 levereras med Node.js 20, som Node.js-projektet slutade stödja i april 2026. NodeSource bygger varje versionsserie av Node.js som Debian-paket, så du får den aktuella versionen med långtidsstöd, 24, och dess uppdateringar kommer via apt som allt annat. En versionshanterare som nvm installerar Node.js i en användares hemkatalog och uppdaterar det aldrig av sig själv: bra på en laptop, inte på en server.

Som root lägger du till NodeSources signeringsnyckel och paketförråd:

apt update
apt install -y curl
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key -o /etc/apt/keyrings/nodesource.asc

Skapa /etc/apt/sources.list.d/nodesource.sources:

Types: deb
URIs: https://deb.nodesource.com/node_24.x
Suites: nodistro
Components: main
Signed-By: /etc/apt/keyrings/nodesource.asc

Installera Node.js, som har npm med sig, och Caddy och Git från Debian:

apt update
apt install -y nodejs caddy git
node -v

v24.21.0

Debians automatiska uppdateringar installerar bara från Debian. För att de också ska installera uppdateringar av Node.js skapar du /etc/apt/apt.conf.d/51unattended-upgrades-nodesource:

Unattended-Upgrade::Origins-Pattern {
    "site=deb.nodesource.com";
};

Kontrollera att filen läses in:

unattended-upgrade --dry-run --debug 2>&1 | grep 'Allowed origins'

Raden slutar med site=deb.nodesource.com.

Med Python

Debians Python får säkerhetsuppdateringar från Debians säkerhetsteam, och de installeras av sig själva på en server uppsatt som i säkerhetsguiden. Appens egna paket hamnar i en virtuell miljö (venv), en egen katalog, så att de aldrig blandas med Debians.

Som root:

apt update
apt install -y python3-venv caddy git curl
python3 -V

Python 3.13.5

Med Python

Skapa appens venv:

runuser -u myapp -- python3 -m venv /home/myapp/venv

Med Node.js

Exempelappen, server.js:

const express = require('express');

const app = express();
// Caddy on this server passes the visitor's address in X-Forwarded-For.
app.set('trust proxy', 'loopback');

app.get('/', (req, res) => {
  res.send(`Hello from Node.js ${process.version}. Your address: ${req.ip}, via ${req.protocol}\n`);
});

const port = process.env.PORT || 3000;
const server = app.listen(port, '127.0.0.1', () => {
  console.log(`Listening on 127.0.0.1:${port}`);
});

// On a restart, finish the requests that are open before exiting.
process.on('SIGTERM', () => {
  console.log('SIGTERM: finishing open requests');
  server.close(() => process.exit(0));
});

Med trust proxy satt till loopback blir req.ip besökarens adress när förfrågan kommer från Caddy på samma server, och headern ignoreras om den kommer från något annat håll. npm ci på servern installerar exakt det som står i package-lock.json, så checka in den filen.

Med Python

Exempelappen, app.py:

import sys

from flask import Flask, request
from werkzeug.middleware.proxy_fix import ProxyFix

app = Flask(__name__)
# Caddy on this server passes the visitor's address in X-Forwarded-For.
app.wsgi_app = ProxyFix(app.wsgi_app, x_for=1, x_proto=1, x_host=1)


@app.get("/")
def index():
    return f"Hello from Python {sys.version.split()[0]}. Your address: {request.remote_addr}, via {request.scheme}\n"

Och requirements.txt:

flask==3.1.*
gunicorn==26.*

gunicorn litar som standard på X-Forwarded-Proto från 127.0.0.1, så appen vet att besökaren kom via HTTPS, men tar inte besökarens adress från X-Forwarded-For. Utan ProxyFix ser appen varje besökare som 127.0.0.1. gunicorn gör redan klart öppna förfrågningar när den stängs.

FastAPI: kör den i gunicorn med uvicorns worker. Lägg till uvicorn-worker i requirements.txt, och byt i steg 5 ut app:app mot -k uvicorn_worker.UvicornWorker main:app. uvicorn litar som standard på headrarna från 127.0.0.1, så du behöver ingen ProxyFix. Det testades med FastAPI 0.142 i samma tjänst, omladdningen i steg 10 inräknad.

Med Node.js

install -m 600 /dev/null /etc/myapp.env
printf 'PORT=3000\nSESSION_SECRET=%s\n' "$(openssl rand -hex 32)" >> /etc/myapp.env

Med Python

install -m 600 /dev/null /etc/myapp.env
printf 'SECRET_KEY=%s\n' "$(openssl rand -hex 32)" >> /etc/myapp.env

Med Node.js

Skapa /etc/systemd/system/myapp.service:

[Unit]
Description=myapp (Node.js)
After=network.target

[Service]
User=myapp
Group=myapp
WorkingDirectory=/home/myapp/app
EnvironmentFile=/etc/myapp.env
Environment=NODE_ENV=production
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=2

# Hardening
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
ProtectControlGroups=yes
ProtectClock=yes
ProtectHostname=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictSUIDSGID=yes
RestrictRealtime=yes
LockPersonality=yes
CapabilityBoundingSet=
SystemCallArchitectures=native
SystemCallFilter=@system-service
UMask=0077

[Install]
WantedBy=multi-user.target

Hoppa över MemoryDenyWriteExecute=yes, som finns med i andra listor över härdning: Node.js kompilerar JavaScript till maskinkod medan det körs och kraschar direkt med den.

Med Python

Skapa /etc/systemd/system/myapp.service:

[Unit]
Description=myapp (Python)
After=network.target

[Service]
User=myapp
Group=myapp
WorkingDirectory=/home/myapp/app
EnvironmentFile=/etc/myapp.env
ExecStart=/home/myapp/venv/bin/gunicorn --bind 127.0.0.1:8000 --workers 2 --no-control-socket app:app
ExecReload=/bin/kill -s HUP $MAINPID
Restart=on-failure
RestartSec=2

# Hardening
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
ProtectControlGroups=yes
ProtectClock=yes
ProtectHostname=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictSUIDSGID=yes
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
CapabilityBoundingSet=
SystemCallArchitectures=native
SystemCallFilter=@system-service
UMask=0077

[Install]
WantedBy=multi-user.target

app:app betyder objektet app i app.py. --no-control-socket stänger av den kontrollsocket som gunicorn 26 öppnar i användarens hemkatalog, och som den skrivskyddade hemkatalogen annars gör till ett fel vid varje start. ExecReload låter systemctl reload ladda om appen utan avbrott, som steg 10 visar.

Med Node.js

Skapa /home/myapp/app.git/hooks/post-receive:

#!/bin/sh
# Deploy every push to main: check out the code, install dependencies, restart.
set -e
while read -r old new ref; do
  [ "$ref" = refs/heads/main ] || continue
  git --work-tree="$HOME/app" checkout -f -q main
  cd "$HOME/app"
  npm ci --omit=dev --no-audit --no-fund --no-update-notifier
  sudo systemctl reload-or-restart myapp.service
  echo "Deployed $new"
done

Med Python

Skapa /home/myapp/app.git/hooks/post-receive:

#!/bin/sh
# Deploy every push to main: check out the code, install dependencies, reload.
set -e
while read -r old new ref; do
  [ "$ref" = refs/heads/main ] || continue
  git --work-tree="$HOME/app" checkout -f -q main
  cd "$HOME/app"
  "$HOME/venv/bin/pip" install -q -r requirements.txt
  sudo systemctl reload-or-restart myapp.service
  echo "Deployed $new"
done

Med Node.js

remote: added 68 packages in 2s
remote: Deployed 6f3dbefd446c5710ef8d159e346792a021949777
To app.example.com:app.git
 * [new branch]      main -> main

Med Python

remote: Deployed 5bf1717456588772fdf3bdd2f91182806d035cb4
To app.example.com:app.git
 * [new branch]      main -> main

Med Node.js

systemctl is-active myapp
curl -s http://127.0.0.1:3000/

active
Hello from Node.js v24.21.0. Your address: 127.0.0.1, via http

Med Python

systemctl is-active myapp
curl -s http://127.0.0.1:8000/

active
Hello from Python 3.13.5. Your address: 127.0.0.1, via http

Med Node.js

{
    email you@example.com
}

app.example.com {
    reverse_proxy 127.0.0.1:3000 {
        # While the app restarts, hold requests for up to 5 seconds instead of answering 502.
        lb_try_duration 5s
    }
}

Med Python

{
    email you@example.com
}

app.example.com {
    reverse_proxy 127.0.0.1:8000 {
        # While the app restarts, hold requests for up to 5 seconds instead of answering 502.
        lb_try_duration 5s
    }
}

Med Node.js

Hello from Node.js v24.21.0. Your address: 198.51.100.7, via https

Med Python

Hello from Python 3.13.5. Your address: 198.51.100.7, via https

Med Node.js

En ensam Node.js-process kan inte lämna över sin port till en ny, så varje driftsättning är en omstart. Det du kan göra är att göra den osynlig:

• Utan lb_try_duration i Caddyfile fick 8 av 228 förfrågningar 502 under en driftsättning: ett glapp på ungefär 0,4 sekunder.
• Med lb_try_duration 5s håller Caddy kvar nya förfrågningar tills den nya processen lyssnar: 222 av 222 fick svar, ingen misslyckades.
• SIGTERM-hanteraren i server.js låter förfrågningar som redan pågår bli klara. Utan den avslutas Node.js direkt: en POST-förfrågan på 3 sekunder som skickades strax före en omstart fick 502. Caddy skickar själv om en avbruten GET, men inte en POST. Med hanteraren blev samma POST klar som vanligt.

Om appen håller anslutningar öppna länge, som WebSockets eller server-sent events, väntar server.close på dem, och systemd avslutar processen efter 90 sekunder, sitt standardvärde (inte testat här). De anslutningarna bryts vid varje driftsättning, och klienten måste ansluta igen.

Flera processer som turas om skulle stänga även det sista glappet, men det kräver en processhanterare eller en andra tjänst och lastbalansering, vilket är mer än de flesta appar behöver.

Med Python

gunicorn kan ladda om utan glapp. Vid systemctl reload myapp, som hooken kör, får gunicorns huvudprocess signalen HUP, startar nya workers med den nya koden och låter de gamla bli klara med sina förfrågningar innan de avslutas. Porten är öppen hela tiden.

• En systemctl restart myapp, utan lb_try_duration i Caddyfile: 11 av 126 förfrågningar fick 502.
• En systemctl reload myapp: 140 av 140 fick svar.
• En git push av en ny version: 245 av 245 fick svar, och den nya texten syntes direkt efteråt.

Journalen visar omladdningen:

[INFO] Hang up: Master
Reloaded myapp.service - myapp (Python).
[INFO] Booting worker with pid: 16461
[INFO] Booting worker with pid: 16463
[INFO] Worker exiting (pid: 15393)
[INFO] Worker exiting (pid: 15394)

En omladdning läser in appens kod och paket på nytt, men inte gunicorn själv, som körs i huvudprocessen. När du har uppdaterat gunicorn, eller Python som i steg 12, använder du systemctl restart myapp. lb_try_duration i Caddyfile döljer även den omstarten.

Med Node.js

Uppdateringar inom Node.js 24 installeras av sig själva, tillsammans med Debians, tack vare filen från steg 1. Den körande appen behåller den gamla versionen tills den startas om. Så här ser du om den behöver det:

ls -l /proc/$(systemctl show -p MainPID --value myapp)/exe

lrwxrwxrwx 1 myapp myapp 0 Oct  2 19:05 /proc/17446/exe -> /usr/bin/node (deleted)

(deleted) betyder att en nyare Node.js är installerad. Starta om appen:

systemctl restart myapp

För att gå över till nästa serie med långtidsstöd, till exempel 26, ändrar du node_24.x till node_26.x i /etc/apt/sources.list.d/nodesource.sources och kör:

apt update
apt install -y nodejs

Pusha sedan en tom commit från din egen dator, så att npm ci installerar om beroendena för den nya versionen och appen startas om:

git commit --allow-empty -m "Redeploy on Node.js 26"
git push live main

Bytet från 24 till 26 och tillbaka testades på det här sättet.

Med Python

Säkerhetsuppdateringar av Python installeras av sig själva tillsammans med Debians. Den körande appen behåller den gamla versionen tills den startas om. Så här ser du om den behöver det:

ls -l /proc/$(systemctl show -p MainPID --value myapp)/exe

Om länken slutar med (deleted) är en nyare Python installerad. Starta om appen:

systemctl restart myapp

Appens egna paket uppdateras när du ändrar requirements.txt och pushar.

Nästa Debian-version har en ny Python-version, och en venv fungerar bara med den version den skapades med. Skapa om venv:en som root efter uppgraderingen:

rm -rf /home/myapp/venv
runuser -u myapp -- python3 -m venv /home/myapp/venv

Pusha sedan en tom commit från din egen dator, så att pip installerar paketen igen:

git commit --allow-empty -m "Rebuild venv"
git push live main

Avsluta med systemctl restart myapp på servern, eftersom en omladdning inte byter ut gunicorn själv. Att skapa om venv:en och pusha testades. En uppgradering till nästa Debian-version testades inte.