• # Un reproche à Railway que je ne partage pas

    Posté par . En réponse au journal "Cursor et Claude ont supprimé ma prod". Évalué à 7 (+5/-0). Dernière modification le 29 avril 2026 à 11:07.

    1. The Railway GraphQL API allows volumeDelete with zero confirmation. A single API call deletes a production volume. There is no "type DELETE to confirm." There is no "this volume is in use by a service named [X], are you sure?" There is no rate-limit or destructive-operation cooldown. No environment scoping. Nothing between an authenticated request and total data loss.

    Une API c'est fait pour automatiser. Et quand on automatise c'est justement pour ne pas se prendre ces confirmations. Et je ne suis pas convaincu que ça aurait pu empêcher l'agent de forcer la suppression s'il en avait envie. Pour moi le problème est surtout là :

    1. Railway's volume backups are stored in the same volume. This is the part that should be a red alert for every Railway customer reading this. Railway markets volume backups as a data-resiliency feature. But per their own docs: "wiping a volume deletes all backups."

    La doc de Railway appelle effectivement un backup quelque chose qui ne l'est pas ..... mais au final c'est écrit quand même dans la doc. Alors, oui on peut reprocher la terminologie utilisée par Railway, mais aussi les personnes qui l'ont mis en oeuvre sans lire la doc ...

    Perso, je suis d'avis que la grosse partie de la responsabilité n'est ni chez l'IA, ni chez Railway.