Railway tutorial: app da GitHub, database e dominio pubblico

👁 116 letture

Railway mette online un’app da un repository GitHub in pochi minuti: indichi il progetto, Railway lo compila e avvia automaticamente, e aggiungi il database con un clic. Questo tutorial ti guida da un account vuoto a un’app funzionante con database e indirizzo pubblico, seguendo la guida ufficiale di Railway.

Prima di iniziare: verifica il progetto in locale

Railway compilerà l’app così com’è nel repository, quindi la maggior parte dei problemi al primo deployment si può individuare prima. Assicurati che l’app si avvii in locale da un clone pulito del repository, senza file che hai solo tu. Annota tutte le variabili d’ambiente di cui ha bisogno, perché dovrai aggiungerle in Railway. Verifica su quale porta l’app è in ascolto e se la legge da una variabile, invece di averla hardcoded.

I file con segreti, ad esempio un file locale con le variabili, non devono finire nel repository.

Passo 1. Nuovo progetto da repository

Nel pannello clicchi New Project e scegli il deployment da repository GitHub. Railway richiede un account GitHub collegato, e se non l’hai ancora fatto ti chiederà di farlo. Poi cerchi il tuo progetto e lo selezioni dalla lista.

Hai due opzioni: Deploy Now avvia subito la compilazione, mentre Add variables ti permette prima di impostare le variabili d’ambiente. Se l’app ha bisogno di un database o di chiavi API, scegli la seconda opzione.

Passo 2. Come Railway compila l’app

Railway riconosce automaticamente come compilare il progetto. Se nel repository c’è un Dockerfile, lo userà, altrimenti sceglierà il metodo di compilazione in base al linguaggio e ai file del progetto. In questa fase i log di build e deployment sono fondamentali.

La documentazione dà un consiglio prezioso: leggi tutto il log, perché il vero errore raramente è nell’ultima riga. Nella maggior parte dei casi si tratta di una variabile d’ambiente mancante o di una versione del linguaggio diversa da quella che usi in locale.

Passo 3. Database

Aggiungi un database PostgreSQL con il pulsante + New nella dashboard del progetto, selezionando database e PostgreSQL. Railway lo crea come servizio separato e fornisce le variabili con i dati di connessione, incluso l’indirizzo del database.

Passo 4. Variabili e riferimenti

Nelle impostazioni del servizio dell’app aggiungi le variabili. Invece di copiare l’indirizzo del database, imposti un riferimento alla variabile del database, ad esempio al suo indirizzo di connessione. In questo modo, quando i dati del database cambiano, l’app riceve quelli nuovi automaticamente. Qui aggiungi anche le chiavi per servizi esterni e le impostazioni dell’ambiente di produzione.

Passo 5. Indirizzo pubblico

Questo è il passo che sorprende molti: dopo il deployment l’app per default non è accessibile da internet. Vai nelle impostazioni del servizio, sezione networking, e clicca Generate Domain. Ottieni un indirizzo pubblico dove l’app è raggiungibile. Puoi collegare il tuo dominio personalizzato nello stesso punto.

Passo 6. Deployment ad ogni modifica

Da questo momento ogni modifica pushata al repository avvia un nuovo deployment. Non devi fare login su nessun server, e la cronologia dei deployment ti permette di tornare alla versione precedente se qualcosa va storto.

Riga di comando

Railway ha anche uno strumento da riga di comando. Il comando railway up invia i file dell’app direttamente dal computer, senza repository, e comandi separati aggiungono database o generano domini. È utile per test rapidi e script.

Esempio: bot Discord con database

Hai un bot Discord che registra i punti degli utenti. Il repository è su GitHub. In Railway crei un progetto dal repository, scegli di aggiungere variabili, inserisci il token del bot, aggiungi un database PostgreSQL e imposti il riferimento al suo indirizzo. Il bot funziona 24 ore su 24, e ogni correzione pushata su GitHub arriva sul server automaticamente.

Dopo un deployment del genere vale la pena fare subito una cosa: pushare una piccola modifica e verificare che il bot si sia aggiornato da solo. Questo conferma che i deployment automatici funzionano, prima che siano davvero necessari. Vale anche la pena controllare il database dopo qualche giorno di funzionamento e assicurarsi che i punti degli utenti vengano salvati e non spariscano dopo un nuovo deployment.

Errori più comuni

• Mancanza di indirizzo pubblico e convinzione che l’app non funzioni.
• Chiavi nel codice invece che nelle variabili d’ambiente.
• Leggere solo la fine del log.
• Indirizzo del database hardcoded invece di un riferimento alla variabile.

Come valutare il primo deployment

Dopo il deployment apri l’indirizzo generato e testa le funzioni principali, non solo la homepage. Verifica che l’app salvi i dati nel database e che dopo un nuovo deployment rimangano. Controlla i log della prima ora di funzionamento: gli avvisi che ignoravi in locale, sul server possono essere il primo segnale di un problema. Infine pusha una piccola modifica e verifica che il nuovo deployment si sia avviato automaticamente.

Quando la prima app funziona, le successive le deployi allo stesso modo: progetto da repository, variabili, eventualmente database e dominio. Dopo il secondo progetto l’intera procedura richiede pochi minuti, e nella dashboard del progetto vedi tutti i servizi e le connessioni tra loro in un unico posto.

// continua a leggereEmbedding e database vettoriali spiegati in modo sempliceGuideClaude Code: password in 1.122 file su GitHub. Come controllareNotizieNash-MOPD: come bilanciare l’addestramento tra più dominiStato dell'IA

Kinetyra