// hosting
Come ospitare un sito Astro: opzioni statiche e SSR
Una guida pratica al deploy di un sito Astro — la differenza tra output statico e output server (SSR), come funzionano gli adattatori, i comandi di build, e come scegliere un host per ciascuna modalità.
Astro può consegnare il tuo sito in due modi molto diversi, e quello che scegli decide dove e come lo ospiti. Per impostazione predefinita Astro costruisce una cartella di semplici file HTML, CSS e JS — file che qualsiasi host statico può servire. Ma Astro può anche girare su un server, renderizzando le pagine su richiesta (SSR) per cose come autenticazione, moduli o dati per richiesta. Questa guida spiega entrambe le modalità di output, i comandi di build che vi stanno dietro, come si inseriscono gli adattatori, e come scegliere un host per ciascuna.
Statico vs server: la decisione centrale
Ogni scelta di hosting per Astro nasce da una domanda: il tuo sito ha bisogno di un server in esecuzione al momento della richiesta?
- Statico (l'impostazione predefinita). Le pagine vengono renderizzate una volta, al momento del build, in file HTML. Non c'è alcun processo server — carichi la cartella costruita su un CDN o un host statico ed esso serve i file. Il più veloce, il più economico, il più semplice. Ideale per blog, documentazione, siti di marketing e la maggior parte dei siti di contenuto.
- Server / SSR. Le pagine vengono renderizzate per richiesta da un processo Node (o edge). Necessario quando il contenuto dipende dalla richiesta: utenti loggati, gestione di moduli, personalizzazione al volo, o dati che devono essere freschi a ogni caricamento.
Puoi anche mescolare i due: mantenere il sito perlopiù statico e far passare specifiche route al rendering su richiesta. Il punto è renderizzare staticamente ovunque tu possa, e pagare per un server solo dove ne hai realmente bisogno.
I comandi di build
Qualunque sia la modalità, il flusso di lavoro sono gli stessi due comandi — installare, poi costruire:
# install dependencies
npm install
# produce the production build
npm run build
# preview the production build locally before deploying
npm run preview Per impostazione predefinita npm run build scrive un sito statico nella cartella dist/. Quella cartella è l'intero tuo sito distribuibile in modalità statica — non c'è nient'altro da eseguire.
Configurare la modalità di output
Controlli la modalità in astro.config.mjs. Lo statico è l'impostazione predefinita, quindi una configurazione minima non ha bisogno di nulla di speciale. Per renderizzare sul server, aggiungi un adattatore — un piccolo pacchetto che insegna ad Astro come girare su una piattaforma specifica (Node, o un runtime edge/serverless):
// astro.config.mjs — server (SSR) output with the Node adapter
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';
export default defineConfig({
output: 'server',
adapter: node({ mode: 'standalone' }),
}); Con l'adattatore Node standalone, npm run build produce un punto di ingresso server che avvii come qualsiasi app Node:
# after building with the Node adapter
node ./dist/server/entry.mjs Se ti servono solo una manciata di route dinamiche, mantieni l'output statico predefinito ed escludi singole pagine dal prerendering invece di passare l'intero sito alla modalità server:
---
// src/pages/dashboard.astro — render this page per request
export const prerender = false;
---
Scegliere un host per modalità
Hosting statico
Per l'output statico ti serve solo un posto dove servire il contenuto di dist/ via HTTPS, idealmente da un CDN. Le impostazioni di build/pubblicazione sono semplici:
Build command: npm run build
Publish/output: dist Molte piattaforme lo fanno — host statici gestiti, object storage dietro un CDN, o un host generico in grado di servire una cartella. Poiché non c'è alcun server da tenere in vita, l'hosting statico è economico e senza sforzo da scalare. Ospitare su infrastruttura europea è una buona scelta qui quando il tuo pubblico o le tue esigenze di residenza dei dati puntano in quella direzione.
Hosting server (SSR)
L'SSR ha bisogno di un runtime che tenga vivo un processo. Due vie generali:
- Un host Node / VPS. Con l'adattatore Node costruisci un server standalone e lo esegui come qualsiasi servizio Node. Un VPS ti dà pieno controllo su processo, ambiente e scaling — comodo se vi esegui già altri servizi.
- Serverless / edge. Adattatori specifici della piattaforma impacchettano la tua app per eseguirla come funzioni. Meno da gestire, ma sei legato al modello di quella piattaforma.
Un modo semplice per eseguire il build Node sul tuo server è un gestore di processi affinché si riavvii in caso di crash o riavvio:
# example: keep the Astro Node server running with PM2
npm install -g pm2
pm2 start ./dist/server/entry.mjs --name astro-site
pm2 save Riferimento rapido
| Esigenza | Modalità | Cosa ospitare |
|---|---|---|
| Blog, documentazione, marketing, contenuto | Statico (predefinito) | La cartella dist/ su un CDN/host statico |
| Perlopiù statico, poche route dinamiche | Statico + prerender = false per pagina | Un host/adattatore che supporta route su richiesta |
| Auth, moduli, dati per richiesta ovunque | Server (SSR) | Un runtime Node / VPS o piattaforma serverless |
Come decidere
Inizia statico — è l'impostazione predefinita per un motivo: più economico, più veloce e più semplice da ospitare. Ricorri all'adattatore server solo quando un requisito reale (stato loggato, elaborazione di moduli, dati sempre freschi) impone il rendering per richiesta, e anche allora considera di escludere dal prerendering solo quelle route invece di eseguire l'intero sito su un server. Adatta l'host alla modalità con cui finisci: un host statico supportato da CDN per i file costruiti, o un VPS in grado di eseguire Node / piattaforma serverless quando hai genuinamente bisogno di un server.