Héberger Kledg sur Railway

Railway exécute l’application et sa base PostgreSQL dans un même projet, sans serveur à administrer. Le dépôt de Kledg contient le fichier railway.json : construction depuis le Dockerfile, migrations avant la bascule vers la nouvelle version, vérification de santé sur /api/health.

Il n’y a pas encore de bouton « Deploy on Railway » pour Kledg : le projet se crée en quelques étapes.

Ce qu’il vous faut

un compte GitHub, avec votre fork ou votre copie du dépôt kledghq/kledg ;
un compte Railway ;
de préférence, un compte Resend pour l’envoi des emails.

Déployer

Dans Railway, New Project, Deploy from GitHub repo, puis votre fork ou votre copie de Kledg. Railway lit railway.json.
Dans le même projet, New, Database, PostgreSQL. Le service s’appelle Postgres.
Dans les variables du service Kledg (Variables, Raw Editor), collez :
```
DATABASE_URL=${{Postgres.DATABASE_URL}}
BETTER_AUTH_SECRET=        # openssl rand -base64 32
SETUP_TOKEN=               # openssl rand -base64 24
ADMIN_EMAIL=vous@exemple.fr
TRUST_PROXY_HOPS=1
KLEDG_BACKUP=off
```
${{Postgres.DATABASE_URL}} est une référence de variable : Railway y met l’URL privée du service PostgreSQL, sur son réseau privé chiffré.
Settings, Networking, Generate Domain : Railway donne un domaine *.up.railway.app, que Kledg lit tout seul. BETTER_AUTH_URL n’est nécessaire qu’avec votre propre domaine, par exemple BETTER_AUTH_URL=https://compta.votre-societe.fr.
Ouvrez https://<domaine>/setup?token=<SETUP_TOKEN> et créez le compte administrateur avec l’email défini dans ADMIN_EMAIL.

Pour les emails, ajoutez RESEND_API_KEY et EMAIL_FROM ; pour la synchronisation bancaire quotidienne, CRON_SECRET (voir plus bas).

L’adresse IP des clients

Kledg limite les tentatives de connexion par adresse IP et l’écrit dans le journal d’audit. Le proxy de Railway ajoute l’adresse du client à l’en-tête X-Forwarded-For : d’où TRUST_PROXY_HOPS=1. Si vous placez Cloudflare devant (DNS en mode proxy), ajoutez 1. Vérifiez la valeur : connectez-vous, puis lisez l’adresse de l’entrée de connexion dans le journal d’audit ; ce doit être la vôtre. En cas de doute, choisissez la plus petite valeur.

Les migrations

preDeployCommand lance les migrations avant que la nouvelle version reçoive du trafic. Si une migration échoue, l’ancienne version continue de servir. Le conteneur relance la même commande au démarrage, sans effet si tout est déjà appliqué.

Mettre à jour

Railway redéploie à chaque push sur la branche suivie. Quand le déploiement vient d’un commit GitHub, la page Mises à jour de Kledg le reconnaît et propose la mise à jour en deux clics, comme sur Vercel. Voir Mettre à jour son instance.

Les sauvegardes

Le service PostgreSQL de Railway a ses propres sauvegardes, selon l’offre. Ajoutez un pg_dump régulier vers un stockage que vous contrôlez. KLEDG_BACKUP=off évite une sauvegarde inutile sur le disque du conteneur, effacé à chaque déploiement.

La synchronisation bancaire quotidienne

Railway ne la planifie pas pour vous : appelez chaque jour /api/cron/sync-banks avec le secret CRON_SECRET, par exemple depuis une GitHub Action planifiée. Voir La synchronisation bancaire quotidienne.

Le coût

Voir la tarification de l’hébergeur.

Pour aller plus loin

la documentation Railway : fichier de configuration et PostgreSQL ;
Choisir son hébergement ;
le guide de référence : docs/self-hosting.md.