Si possono usare i file .htaccess su Pantheon? Guida completa

La risposta corta è no: su Pantheon non puoi usare i file .htaccess come leva di configurazione runtime, nel senso classico di Apache. Se vieni da hosting tradizionale con Apache o da un cPanel “vecchio stile”, è il primo punto da chiarire: su Pantheon non imposti regole locali nel filesystem e non ti aspetti che il web server le legga ad ogni richiesta. Il comportamento va spostato in un livello diverso, di solito applicazione, configurazione del progetto o strumenti messi a disposizione dalla piattaforma.

Questa differenza conta più di quanto sembri. Molti problemi che altrove si risolvono con un paio di righe in .htaccess su Pantheon si trattano con redirect gestiti dalla piattaforma, con le impostazioni del CMS, oppure con il repository del progetto e il deploy. Se provi a portarti dietro la mentalità “modifico il file e il sito cambia subito”, finisci per inseguire un falso problema: il file esiste magari anche nel codice, ma non è il punto di applicazione della logica HTTP.

Perché su Pantheon .htaccess non è il meccanismo giusto

Il punto non è solo tecnico, è architetturale. .htaccess nasce come configurazione distribuita di Apache: il server controlla quel file lungo il percorso della request e applica regole locali senza richiedere una modifica centrale. È comodo, ma ha un costo in prestazioni e introduce una gestione poco prevedibile in ambienti moderni orchestrati o multi-layer.

Pantheon, invece, è costruito per separare chiaramente ambiente, codice e runtime. Questo significa che le regole che vuoi rendere stabili devono stare nel posto corretto: nel codice dell’applicazione, in un livello di configurazione supportato dalla piattaforma, o in un redirect gestito centralmente. In pratica, il controllo non è “sul file”, ma “sul flusso di deploy e sulle opzioni supportate”.

Se il tuo obiettivo è cambiare il comportamento HTTP, devi chiederti subito quale layer stai toccando: redirect, rewrite, header, autenticazione, cache o routing applicativo. Su un hosting tradizionale la tentazione è usare sempre .htaccess; su Pantheon conviene invece scegliere la leva corretta fin dall’inizio.

Cosa fare al posto di .htaccess

La sostituzione dipende dal caso d’uso. Qui sotto la lettura pratica, senza teoria inutile.

• Redirect permanenti o temporanei: meglio gestirli con lo strumento della piattaforma, oppure nel livello applicativo se il CMS lo prevede.
• Rewrite per front controller: in molti CMS è già previsto dal codice del progetto; non serve inventare regole locali se il framework le gestisce da solo.
• Blocco di directory, accessi o policy HTTP: va verificato se esiste una funzione supportata da Pantheon, o se si deve agire nel CMS/plugin/modulo dedicato.
• Header di sicurezza: spesso conviene impostarli dove il progetto li controlla in modo esplicito, non con regole sparse nel filesystem.

Se stai migrando un sito da Apache “classico” a Pantheon, il primo lavoro serio non è copiare il file .htaccess, ma fare l’inventario delle regole che contiene. Molte saranno già standard del CMS; altre saranno workaround storici; altre ancora saranno regole di sicurezza o redirect accumulati negli anni. Senza questa pulizia, importi anche il debito tecnico.

Come capire se una regola .htaccess era davvero necessaria

Il test migliore è brutale: prendi ogni blocco del file e chiediti se serve al web server o all’applicazione. Se la regola serve a trasformare URL interni del CMS, probabilmente appartiene al CMS. Se serve a forzare HTTPS, HSTS, canonical host o redirect di vecchi percorsi, probabilmente va gestita in un punto più centrale e controllato.

Un esempio tipico: molti siti hanno un .htaccess con regole per riscrivere tutto su index.php. Se il sito è Drupal, WordPress o un framework PHP moderno, quella logica spesso è già parte del bootstrap o del routing. Su Pantheon non devi duplicarla. La duplicazione è pericolosa perché crea due fonti di verità: una nel codice e una nel file che tanto non è il meccanismo corretto.

Altro caso classico: redirect da http a https e da www a dominio canonico. Qui il rischio non è solo funzionale, è anche di loop. Se il redirect è pensato male, il sito diventa lento o irraggiungibile. Su una piattaforma gestita conviene sempre verificare prima dove passa il traffico: edge, origin e application layer non sono intercambiabili.

Esempio pratico: migrazione di un sito con .htaccess pieno di regole

Immagina un sito PHP migrato da hosting condiviso. Nel vecchio ambiente il file .htaccess contiene redirect, blocchi IP, regole anti-hotlink, compressione, rewrite del front controller e qualche eccezione per file legacy. Su Pantheon questa miscela non va incollata pari pari: prima si separano le funzioni, poi si decide il canale di implementazione.

1. Inventaria le regole: classifica ogni blocco come redirect, sicurezza, rewrite, performance, compatibilità legacy.
2. Elimina i duplicati del CMS: molte regole sono già native nel framework o nel modulo di routing.
3. Trasferisci i redirect critici nel punto supportato dalla piattaforma o nel livello applicativo.
4. Verifica i percorsi legacy con richieste reali, non con supposizioni.
5. Rimuovi il superfluo: se una regola non produce un effetto osservabile, non portarla avanti solo perché “c’era prima”.

La parte importante è la verifica. Non basta leggere il file, bisogna testare le risposte HTTP. Un controllo rapido con curl -I ti dice subito se il redirect avviene, se il codice è corretto e se hai loop o catene inutili. Se una regola era solo cosmetica, la vedi sparire senza effetti collaterali. Se invece era essenziale, emerge subito dal comportamento.

curl -I https://example.com/vecchio-percorso

Output atteso: un 301 o 302 verso la destinazione prevista, senza passaggi intermedi inutili. Se vedi una catena di redirect, il problema non è “manca .htaccess”, ma che hai distribuito la logica in più punti e devi consolidarla.

Rewrite, redirect e sicurezza: cosa cambia davvero

Molti associano .htaccess a tre categorie di intervento: riscrittura URL, redirect e protezioni. Su Pantheon il punto non è se queste funzioni esistano, ma dove vanno implementate. Il rischio, altrimenti, è fare affidamento su un meccanismo non supportato o non persistente tra ambienti.

Per i redirect, la cosa più pulita è centralizzare la logica. Se ogni ambiente deve comportarsi allo stesso modo, il redirect non deve stare in una modifica manuale fatta una volta sola. Per i rewrite, la domanda è ancora più semplice: il CMS o framework ha già il suo router? Se sì, non serve altro. Per la sicurezza, come blocco di directory o restrizioni di accesso, conviene preferire funzioni native della piattaforma o dell’applicazione, perché sono più facili da auditare e meno fragili in deploy successivi.

Un dettaglio spesso trascurato: ciò che in Apache si risolveva con una regola nel filesystem, su una piattaforma come Pantheon può diventare una decisione da trattare in fase di build o di deploy. Questo è un vantaggio, non una complicazione. Significa che la modifica è versionabile, ripetibile e verificabile. Il costo iniziale è un po’ più alto, ma il comportamento diventa meno casuale.

Il controllo reale passa dai test HTTP

Se vuoi sapere se una migrazione da .htaccess a Pantheon è andata bene, non guardare il file: guarda le risposte. I tre segnali minimi sono questi: codice HTTP corretto, destinazione corretta, assenza di loop. Tutto il resto è rumore finché non emerge un problema specifico.

Un set di test essenziale può includere la homepage, un vecchio URL noto, una pagina protetta e un percorso che prima veniva riscritto. Se uno di questi cambia comportamento, hai già una pista. Se tutti rispondono come previsto, la vecchia logica nel .htaccess era probabilmente ridondante o sostituibile.

curl -I https://example.com/
curl -I https://example.com/vecchio-url
curl -I https://example.com/pagina-protetta

Controlla anche i log applicativi e, se disponibile, i log del livello edge o del reverse proxy. Se una richiesta fallisce, il punto utile non è “il file non è letto”, ma “dove si interrompe il flusso”. Questo approccio ti evita di inseguire sintomi sbagliati e ti fa vedere subito se il problema è DNS, edge, origin o app.

Quando devi davvero cambiare configurazione e non solo il codice

Ci sono casi in cui la tentazione di usare .htaccess nasce solo dalla comodità. Ma su Pantheon conviene distinguere tra modifica temporanea e modifica strutturale. Se stai facendo un fix rapido su un ambiente non produttivo, puoi testare il comportamento con la minima variazione possibile. Se invece il cambiamento deve vivere nel tempo, deve stare nel posto previsto dal flusso di deploy.

Questa scelta ha anche un impatto operativo: meno file sparsi, meno sorprese tra ambienti, meno differenze non tracciate. In una piattaforma gestita, la configurazione non deve dipendere da un intervento manuale locale che nessuno ricorda più dopo sei mesi. Il vero guadagno non è solo tecnico, è di manutenzione.

Se il progetto ha bisogno di regole particolari non coperte nativamente, la strada corretta è verificare la documentazione della piattaforma e del CMS prima di inventare workaround. Se la funzione non c’è, va dichiarato esplicitamente nel progetto e si valuta un’alternativa supportata. Non è elegante, ma è molto meglio di una soluzione che sembra funzionare finché non arriva il prossimo deploy.

Risposta pratica alla domanda iniziale

Se per “usare i file .htaccess su Pantheon” intendi caricarli come su Apache e aspettarti che definiscano il comportamento del sito, la risposta è no. Se invece intendi portare quelle stesse esigenze funzionali su Pantheon, allora sì: ma devi farlo nel modo supportato dalla piattaforma, non con un copia-incolla meccanico.

La regola operativa è semplice: prendi il contenuto del vecchio .htaccess, separa ciò che è davvero necessario, verifica se esiste già nel CMS o nella piattaforma, poi valida il risultato con richieste HTTP reali. È il percorso più pulito per evitare regressioni, ridurre il debito tecnico e non portarsi dietro abitudini da hosting tradizionale in un ambiente che ragiona in modo diverso.