Riferimento al deploy self-hosted Node di Emdash CMS

Pubblicato il 2026-04-08 di Emdash Cms Everything

Quando il self-hosting è la scelta giusta

Scegli il self-hosting quando i vincoli sono operativi, legali o architetturali:

• i requisiti di residenza dei dati sono rigidi
• gestisci già internamente servizi di piattaforma condivisi
• hai bisogno di pieno controllo su runtime, modello di processo e percorsi di rete
• vuoi evitare nelle fasi iniziali la dipendenza da cloud gestiti

Il self-hosting non è automaticamente più economico. Di solito è più controllabile.

Modello di progressione consigliato

Non partire dalla massima complessità. Usa un rollout a fasi:

1. Node.js + SQLite + storage file locale
2. PostgreSQL per sicurezza multi-istanza e maggiore durabilità
3. object storage compatibile S3 per portabilità dei media
4. supervisione dei processi e rafforzamento dell’osservabilità

Questa sequenza minimizza lo shock di migrazione mantenendo un percorso di produzione pulito.

Architettura di base (Fase 1)

Per produzione single-node o lancio iniziale:

• runtime applicativo: adapter Node (standalone)
• database: file SQLite su disco persistente
• media: directory upload locale
• reverse proxy: Nginx o Caddy

Questa configurazione è sufficiente per carichi editoriali da bassi a moderati con una singola istanza runtime.

# Build ed esecuzione in produzione
npm install
npm run build
npm run start

Criteri di upgrade alla Fase 2 (passaggio a PostgreSQL)

Aggiorna il database quando si verifica uno di questi casi:

• la contesa su scritture concorrenti diventa frequente
• gli obiettivi di backup/recovery superano la strategia di copia file
• hai bisogno di deploy multi-istanza più sicuro

Passa a PostgreSQL prima di aggiungere scaling orizzontale dell’app. Scalare nodi applicativi su SQLite crea rapidamente rischi operativi.

Strategia storage: file locali vs object storage

File locali (inizia da qui)

Adatto ad ambienti a singola istanza con crescita dello storage prevedibile.

Object storage compatibile S3 (passa qui per scalare)

Usalo quando:

• più istanze applicative richiedono accesso condiviso ai media
• backup e disaster recovery devono essere standardizzati
• la strategia CDN ed edge cache dipende da URL oggetto stabili

MinIO può essere usato su infrastruttura privata per un comportamento compatibile S3.

Baseline di processo runtime e proxy

Gestione dei processi

Usa uno tra:

• systemd per controllo servizi nativo Linux
• pm2 per team che vogliono metriche di processo e riavvii rapidi

Reverse proxy

Termina il TLS sul proxy e inoltra all’app Node:

• preserva header Host e X-Forwarded-*
• configura il percorso di health check
• imposta limiti dimensione body allineati alla policy upload

Policy di backup e recovery

Tratta la policy di backup come requisito bloccante per il lancio, non come attività post-lancio.

Baseline minima:

• snapshot database pianificati
• backup o replica dello storage media
• prova di restore almeno una volta prima del lancio pubblico

Un backup mai ripristinato in test è una voce, non un controllo.

Checklist di prontezza operativa

Prima del cutover in produzione, conferma:

• il riavvio a freddo funziona senza modifiche manuali
• i log applicativi sono centralizzati e ricercabili
• l’alerting 5xx è attivo
• uso disco e crescita storage sono monitorati
• il processo di rotazione secret è documentato

Note di migrazione da setup orientato a Cloudflare

Se il tuo progetto è nato con assunzioni Cloudflare:

• rimuovi i binding esclusivi cloud dalla configurazione runtime
• sostituisci adapter D1/R2 con adapter database e storage compatibili Node
• rivalida auth e callback URL dietro il reverse proxy

Il rischio di migrazione è soprattutto nelle assunzioni ambientali, non nel codice a livello pagina.

Quadro decisionale per i team

Usa questa regola:

• se ti servono velocità e minima operatività, preferisci il percorso cloud gestito
• se ti servono controllo e integrazione con l’infrastruttura esistente, preferisci il percorso self-hosted

Scegli un percorso predefinito per ambiente. Modelli di deploy ibridi sono possibili, ma aumentano carico cognitivo e onere di supporto.