Cos'è Render e quando conviene

Ti serve un posto dove far girare un backend, e le opzioni sembrano due estremi: una piattaforma semplice ma con una fattura che non riesci a prevedere, oppure AWS con la sua console piena di servizi di cui non sai il nome. In mezzo c'è una terza categoria, e Render è l'esempio più chiaro. In questo articolo trovi cosa offre davvero, la verità sul piano gratuito che sospende i servizi, e come si posiziona rispetto alle alternative.

Cos'è

Render è una piattaforma gestita che fa girare applicazioni backend, siti, processi pianificati, worker e database Postgres, con deploy automatico da Git e senza nessun server da amministrare.

È nata come risposta diretta a Heroku, la piattaforma che ha inventato questa categoria. Render ne ha preso il modello — un servizio, un comando di avvio, il deploy da Git — e lo ha ricostruito con prezzi e infrastruttura moderni.

Se arrivi da Vercel o Netlify, la differenza è una sola: lì il codice lato server gira in funzioni serverless che vivono il tempo di una richiesta, qui gira in un processo che resta acceso. Questo è il mondo dei processi.

Cosa puoi far girare

Render organizza tutto in tipi di servizio, e capirli è metà del lavoro perché scegliere il tipo giusto ti risparmia problemi dopo.

Web service

Il tipo principale: un processo che ascolta su una porta e risponde a richieste HTTP. La tua API, il tuo backend Django, la tua applicazione Express o Rails.

Render gli assegna un sottodominio con HTTPS già attivo, gestisce il certificato e lo rinnova da solo. Se colleghi un dominio tuo, il certificato viene emesso senza che tu tocchi nulla.

Il requisito da conoscere è uno solo, e sbagliarlo è l'errore del primo giorno: il processo deve ascoltare sulla porta indicata dalla variabile d'ambiente PORT, non su una porta fissa scelta da te.

const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0");

Anche 0.0.0.0 conta: se ascolti su localhost, il processo parte, i log sembrano a posto e nessuna richiesta arriva.

Cron job

Un comando che viene eseguito a orari fissi e poi termina. Pulizie notturne, invio di riepiloghi, sincronizzazioni con servizi esterni, generazione di report.

La differenza rispetto a metterlo dentro l'applicazione è che qui è un'entità a sé, con i suoi log e le sue notifiche di fallimento: se un job non parte, lo sai.

Background worker

Un processo sempre attivo che non riceve richieste HTTP. Sta in ascolto su una coda e smaltisce lavori: invio di email, elaborazione di immagini, chiamate lente a servizi esterni.

È il pezzo che rende un'applicazione decente. L'utente preme un pulsante, la richiesta si chiude in cinquanta millisecondi, il lavoro pesante avviene dietro le quinte. Senza worker, quella richiesta resta appesa venti secondi e a volte va in timeout.

Static site

Frontend costruito e servito da CDN. Funziona bene ed è incluso, ma è il terreno dove le piattaforme specializzate sono più curate: se il progetto è solo frontend, resta più pertinente il confronto in Vercel o Netlify.

Postgres gestito

Un'istanza PostgreSQL con backup automatici, raggiungibile dagli altri servizi sulla rete privata interna. Non installi niente, non gestisci utenti di sistema, non apri porte verso internet.

Dischi persistenti

Questa è una differenza sostanziale rispetto al mondo serverless: puoi collegare un disco a un servizio, e quel disco sopravvive ai deploy. File caricati dagli utenti, indici di ricerca, cache su file, SQLite se ti basta.

Attenzione a una conseguenza tecnica: un servizio con un disco collegato non può girare in più copie contemporaneamente, perché il disco è agganciato a una sola istanza. Se prevedi di dover distribuire il carico su più copie, lo storage deve stare fuori.

Come funziona il deploy

Il ciclo è standard: colleghi il repository, indichi comando di build e di avvio, e ogni push fa ripartire il giro.

Build command:  npm install && npm run build
Start command:  node dist/server.js

Render costruisce, e manda il traffico sulla nuova versione solo quando questa risponde, tenendo attiva la precedente nel frattempo. Se la build fallisce o il processo non parte, la versione online resta quella di prima. È una rete di sicurezza che su un server gestito a mano devi costruirti.

Il pezzo che distingue Render sul piano organizzativo è la definizione dell'infrastruttura in un file dentro il repository:

services:
  - type: web
    name: api
    env: node
    buildCommand: npm install && npm run build
    startCommand: node dist/server.js
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: db-principale
          property: connectionString

  - type: worker
    name: worker-email
    env: node
    buildCommand: npm install
    startCommand: node dist/worker.js

Il vantaggio non è estetico. La configurazione sta in Git, quindi è versionata, si rivede in una pull request e si ricrea identica altrove. Chi ha ereditato un progetto configurato solo a mano in un pannello, con impostazioni che nessuno ricorda di aver messo, capisce il valore al primo colpo. È lo stesso principio che rende utile la CI/CD.

Le credenziali si gestiscono come variabili d'ambiente, con gruppi condivisi tra più servizi.

Il piano gratuito e la sospensione: come stanno le cose

Questo è il punto su cui vale la pena essere chiari, perché è la caratteristica di Render più citata e più fraintesa.

Sul piano gratuito, un servizio web che non riceve richieste per un certo periodo viene sospeso. Il processo si ferma. Alla richiesta successiva riparte da zero.

In concreto: il primo visitatore dopo un periodo di inattività aspetta. Non un secondo, ma decine di secondi, perché il container va riavviato, il runtime caricato e l'applicazione inizializzata. Quanto esattamente dipende da quanto è pesante la tua applicazione all'avvio.

E le conseguenze vanno oltre la lentezza:

• Chi arriva su una pagina bianca per venti secondi pensa che il sito sia rotto e chiude.
• Le richieste API dal frontend possono andare in timeout prima che il servizio sia in piedi.
• Un webhook esterno può fallire perché ha una soglia di attesa breve, e non tutti riprovano.
• Uno stato tenuto in memoria — una cache, una sessione, un contatore — sparisce a ogni sospensione.

Il giudizio onesto: per un progetto personale, un portfolio con una piccola API, un esperimento, un servizio interno che usi tu tre volte al giorno, va benissimo. Zero euro per qualcosa che funziona è un ottimo affare, e l'attesa la sopporti.

Per qualcosa che usano i clienti, no. Non è una questione di eleganza: è che il primo contatto con il tuo prodotto diventa l'esperienza peggiore che offre. Una demo a un cliente, una pagina che riceve traffico da una campagna, qualcuno che ti paga — quello è un servizio che deve stare acceso.

Un ultimo avvertimento, perché è un classico: la soluzione non è un servizio esterno che chiama la tua applicazione ogni pochi minuti per tenerla sveglia. Funziona, ma stai aggirando i termini di un piano gratuito consumando risorse per finta, e smette di funzionare senza preavviso.

Render, Railway o un VPS

	Render	Railway	VPS
Modello di prezzo	Canone per servizio	Consumo di risorse	Canone per macchina
Prevedibilità della spesa	Alta	Variabile	Alta
Configurazione in Git	Sì, file dichiarativo	Parziale	Da costruirsi
Piano gratuito	Sì, con sospensione	Credito iniziale	No
Tipi di servizio	Web, cron, worker, statico	Qualsiasi processo	Qualsiasi cosa
Dischi persistenti	Sì	Sì (volumi)	Sì, è il tuo disco
Manutenzione sistema	Nessuna	Nessuna	Tutta tua
Costo a parità di risorse	Più alto	Più alto	Il più basso
Adatta a	Servizi strutturati e stabili	Prototipi rapidi, esperimenti	Carico stabile, budget stretto

Il posizionamento in una riga: Render è più prevedibile di Railway e molto più semplice di AWS. Paghi una cifra per servizio e sai cosa spendi a fine mese, invece di scoprirlo. In cambio hai meno elasticità: non paghi meno se il servizio è scarico.

Sul confronto con un server tuo la risposta non cambia rispetto a qualsiasi piattaforma gestita: a parità di CPU e RAM, un VPS costa meno. Quello che compri qui è il tempo che non passi a installare, mettere in sicurezza, monitorare e aggiornare — più le cose che dai per scontate e che a mano vanno costruite: HTTPS automatico, deploy senza interruzione, backup del database, log centralizzati, riavvio automatico.

Il VPS torna a essere la scelta giusta quando il carico è stabile e conosciuto, quando i servizi si moltiplicano e ognuno ha il suo canone, o quando sai già amministrare Linux: in quel caso il percorso è configurare un VPS da zero.

Gli errori che fanno perdere ore

Ascoltare sulla porta sbagliata. Ignorare PORT o restare su 127.0.0.1: il servizio risulta avviato, i log sono puliti e il traffico non arriva. È il primo problema di quasi tutti.

Scrivere file sul filesystem senza un disco collegato. Caricamenti degli utenti salvati in una cartella locale spariscono al deploy successivo. Serve un disco dichiarato o uno storage esterno.

Mettere un lavoro pesante dentro la richiesta HTTP. Se un'operazione dura più di qualche secondo, deve andare in un worker. Altrimenti l'utente aspetta e la richiesta rischia il timeout.

Dimenticare un cron job che fallisce in silenzio. Un job che non parte da tre settimane non fa rumore. Attiva le notifiche di fallimento, non fidarti del fatto che "prima funzionava".

Non gestire le migrazioni del database. Il codice nuovo che si aspetta una colonna che non esiste ancora rompe la produzione. Le migrazioni vanno in un passo esplicito, non improvvisate al primo avvio.

Contare sulla memoria del processo. Un servizio può essere riavviato in qualsiasi momento. Sessioni e cache in memoria vanno perse: mettile in Redis o nel database.

Quando conviene e quando no

Conviene se: hai un backend con più pezzi — API, worker, processi pianificati — e vuoi vederli in un posto solo; vuoi la spesa prevedibile; ti serve un disco persistente; vieni da Heroku e cerchi lo stesso modello.

Non conviene se: il progetto è solo frontend, dove le piattaforme dedicate sono migliori. Nemmeno se il carico è molto variabile — lì il canone fisso ti fa pagare capacità inutilizzata — o se il budget è la variabile dominante e sai gestirti un server.

In sintesi

Render è l'erede pratico di Heroku nella sua idea originale: dai un repository, ottieni un servizio online, senza toccare un server.

Copre i quattro pezzi di un backend reale — servizi web, cron job, worker in background e Postgres gestito — più i dischi persistenti, che il mondo serverless non ha.

Il posizionamento è "prevedibile": canone per servizio invece di consumo, e infrastruttura descritta in un file versionato in Git. Meno elastico di Railway, molto più semplice di AWS.

Sul piano gratuito i servizi si sospendono, e il primo accesso dopo l'inattività è lento. Per un progetto personale è un compromesso accettabile. Per qualcosa che usano i clienti, no: quello è il momento di pagare.

Costa più di un VPS a parità di risorse, e ha senso comunque finché il tempo che ti risparmia vale più della differenza.

Per l'alternativa più elastica leggi cos'è Railway, e per il quadro d'insieme come mettere online un'app.