Railway stap voor stap: app deployen met database

👁 116 keer gelezen

Railway zet een app uit je GitHub-repository in enkele minuten online: je wijst het project aan, Railway bouwt en start het zelf, en een database voeg je toe met één klik. Deze tutorial leidt je van een leeg account naar een werkende applicatie met database en publiek adres, volgens de officiële Railway-handleiding.

Voordat je begint: test je project lokaal

Railway bouwt de applicatie zoals die in de repository staat, dus de meeste problemen bij de eerste deployment kun je van tevoren opsporen. Zorg ervoor dat de applicatie lokaal start vanuit een schone clone van de repository, zonder bestanden die alleen jij hebt. Noteer alle environment variables die nodig zijn, want elk ervan moet je in Railway toevoegen. Controleer op welke poort de applicatie luistert en of die uit een variabele wordt gelezen, niet hardcoded.

Bestanden met secrets, bijvoorbeeld een lokaal bestand met variabelen, horen niet in de repository thuis.

Stap 1. Nieuw project vanuit repository

In het dashboard klik je op New Project en kies je voor deployment vanuit een GitHub-repository. Railway vereist een gekoppeld GitHub-account, en als je dat nog niet hebt gedaan, vraagt het daarom. Daarna zoek je je project op en selecteer je het uit de lijst.

Je hebt twee opties: Deploy Now start het bouwen meteen, en Add variables laat je eerst environment variables instellen. Als de applicatie een database of API-sleutels nodig heeft, kies dan de tweede optie.

Stap 2. Hoe Railway je app bouwt

Railway herkent automatisch hoe het project gebouwd moet worden. Als er een Dockerfile in de repository staat, gebruikt het die, anders kiest het een buildmethode op basis van de taal en projectbestanden. In deze fase zijn de build- en deployment-logs het belangrijkst.

De documentatie geeft hier waardevol advies: lees de hele log, want de echte fout staat zelden in de laatste regel. Meestal gaat het om een ontbrekende environment variable of een andere taalversie dan die je lokaal gebruikt.

Stap 3. Database

Een PostgreSQL-database voeg je toe met de knop + New op het projectdashboard, door database en PostgreSQL te kiezen. Railway maakt het aan als aparte service en biedt variabelen met verbindingsgegevens, waaronder het database-adres.

Stap 4. Variabelen en referenties

In de instellingen van de applicatieservice voeg je variabelen toe. In plaats van het database-adres te kopiëren, stel je een referentie in naar de database-variabele, bijvoorbeeld naar het verbindingsadres. Zo krijgt de applicatie automatisch nieuwe gegevens wanneer de database-gegevens wijzigen. Hier voeg je ook sleutels voor externe services en productie-instellingen toe.

Stap 5. Publiek adres

Dit is de stap die veel mensen verrast: na deployment is de applicatie standaard niet bereikbaar vanaf internet. Je gaat naar de service-instellingen, sectie netwerk, en klikt op Generate Domain. Je krijgt een publiek adres waarop de applicatie draait. Een eigen domein kun je op dezelfde plek koppelen.

Stap 6. Deployments na elke wijziging

Vanaf nu start elke wijziging die naar de repository wordt gepusht een nieuwe deployment. Je logt niet in op een server, en de deployment-geschiedenis laat je terugkeren naar een eerdere versie als er iets misgaat.

Command line

Railway heeft ook een command line tool. Het commando railway up stuurt applicatiebestanden rechtstreeks vanaf je computer, zonder repository, en aparte commando’s voegen een database toe of genereren een domein. Handig voor snelle tests en scripts.

Voorbeeld: Discord-bot met database

Je hebt een Discord-bot die punten van gebruikers opslaat. De repository staat op GitHub. In Railway maak je een project aan vanuit de repository, kiest voor het toevoegen van variabelen, voert het bot-token in, voegt een PostgreSQL-database toe en stelt een referentie naar het database-adres in. De bot draait 24/7, en elke fix die naar GitHub wordt gepusht komt vanzelf op de server terecht.

Na zo’n deployment is het verstandig om meteen één ding te doen: push een kleine wijziging en controleer of de bot zichzelf heeft geüpdatet. Dat bevestigt dat automatische deployments werken, voordat je ze echt nodig hebt. Het is ook goed om na een paar dagen in de database te kijken en te controleren dat gebruikerspunten worden opgeslagen en na een nieuwe deployment niet verdwijnen.

Meest voorkomende fouten

• Geen publiek adres en de overtuiging dat de applicatie niet werkt.
• Sleutels in de code in plaats van in environment variables.
• Alleen het einde van de log lezen.
• Database-adres hardcoded in plaats van een referentie naar een variabele.

Hoe je de eerste deployment beoordeelt

Na deployment open je het gegenereerde adres en test je de belangrijkste functies, niet alleen de homepage. Controleer of de applicatie gegevens in de database opslaat en of die blijven staan na een nieuwe deployment. Bekijk de logs van het eerste uur: waarschuwingen die je lokaal negeerde, zijn op de server vaak het eerste signaal van een probleem. Push ten slotte een kleine wijziging en controleer of de nieuwe deployment vanzelf is gestart.

Als de eerste applicatie werkt, deploy je volgende op dezelfde manier: project vanuit repository, variabelen, eventueel database en domein. Na het tweede project duurt de hele procedure nog maar een paar minuten, en op het projectdashboard zie je alle services en verbindingen ertussen op één plek.

// lees verderWat zijn embeddings en vector databases? Uitleg en testHandleidingenQwen3.6-27B op een RTX 4090: welke kwantisatie pastHandleidingenPinokio installeren en testen op Windows: lokale AIHandleidingen

Kinetyra