Fix Railway deployment failure caused by file-based logging configuration

[Copilot]

Problem

The application was failing to deploy on Railway.app due to winston logger attempting to write log files to a logs/ directory that doesn't exist in Railway's ephemeral filesystem. The logger was configured to use file transports in production, which is incompatible with cloud platforms that capture logs from stdout/stderr.

Root Cause

Railway.app (and similar cloud platforms) have ephemeral filesystems where:

• Files don't persist across deployments or restarts
• Directories created during deployment are lost
• Log aggregation systems capture output from stdout/stderr, not file systems

The existing logger configuration attempted to write to file transports in all environments, causing deployment failures when the logs/ directory couldn't be created or accessed.

Solution

Refactored server/config/logger.js to use environment-aware logging strategies:

Production Mode (Railway, Heroku, etc.):

• Logs output to console (stdout/stderr)
• Railway's log aggregation captures and displays all logs
• No filesystem dependencies

Development Mode (Local):

• Logs written to files in logs/ directory for persistence
• Also outputs to console for real-time monitoring
• Logs directory automatically created if it doesn't exist

Changes Made

Code

• server/config/logger.js: Implemented conditional transport configuration based on NODE_ENV
• Added automatic logs directory creation only in non-production environments
• Maintained all existing log levels (error, warn, info, http, debug)

Documentation

• RAILWAY_DEPLOYMENT.md: Added logging configuration section and troubleshooting guidance
• RAILWAY_CHECKLIST.md: Updated deployment checklist with logging verification steps
• Documented how to view logs in Railway dashboard

Testing

✅ Verified logger outputs to console in production mode
✅ Verified logger creates files and logs to console in development mode
✅ Confirmed logs directory auto-creation works correctly
✅ Validated syntax and module imports
✅ Tested all log levels (error, warn, info, http, debug)

Impact

• ✅ Resolves Railway deployment failures
• ✅ Enables proper log viewing in Railway dashboard
• ✅ Maintains backward compatibility with local development
• ✅ Follows cloud platform best practices for logging
• ✅ No changes required to existing logger usage throughout the application

Logs can now be viewed in Railway dashboard under Deployments → Logs.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• binaries.prisma.sh
  • Triggering command: node scripts/postinstall.js (dns block)
  • Triggering command: node /home/REDACTED/work/SpareChair/SpareChair/node_modules/prisma/build/index.js generate --postinstall "UNABLE_TO_FIND_POSTINSTALL_TRIGGER__ENVAR_MISSING" (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>See railway.app deploy log</issue_title>
<issue_description>logs.1759349834958.json</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #8

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.