fix

When it deploys to the container have you told it to put anything in the container as log connection to database?

No explicit "connected to database" log - we use the Supabase JS client, which doesn't require an upfront connection step, so there's nothing logged for that specifically.

However, the app does unconditionally log on every successful startup:

1. "[Cron] First daily run in X minutes" - printed as soon as the process starts, before the server even begins listening
2. A banner: "Magnolia Woods Platform API / Running on port X" - printed once Express successfully binds and starts listening

Neither of these lines - nor anything else - is appearing in the Deploy Logs tab for any of tonight's deployments, including the rolled-back one that was previously working. Since line 1 prints almost immediately on process start (before any network/DB activity), its absence suggests the container may not be reaching the point of executing our code at all, rather than our code hanging or crashing partway through.

Happy to add additional temporary logging (e.g. a console.log as the very first line of the file) if that would help you pinpoint where in the startup sequence things are stalling.

Given the pattern you're describing (works fine locally, fails identically after rollback, zero logs, flat metrics), I'd push on two things before anything else: proving whether it's actually your app or something Railway-side, and adding logging that's low enough level to survive even a very early crash.

For isolating it — spin up a throwaway service in the same project, literally just a "hello world" express app that listens and logs on boot. If that also comes back with zero logs and "Application failed to respond," that's basically confirmation this isn't your code, it's something with the project/environment on Railway's end, and worth pushing to their support directly rather than digging further into your app. Also worth trying an actual restart on the instance rather than a redeploy — redeploy can reuse a build that's inheriting a stuck state, restart forces a clean container. And if your service is pinned to a region, try switching regions, just to rule out a regional issue.

On the logging side — since literally nothing is showing up, not even your [Cron] line that should fire almost instantly, I'd go a level below your app code. Stick something in the actual start command itself so it fires before Node even loads:

echo "CONTAINER BOOT $(date)" && node dist/index.js

If that echo doesn't show up in Deploy Logs, that's pretty damning — it means either the container isn't running your start command at all, or Railway's log capture is broken, and either way it's not something you can fix from your side.

Then as the literal first line of your entry file, before anything else loads:

jsprocess.stdout.write(BOOT ${new Date().toISOString()} pid=${process.pid}\n);

process.stdout.write instead of console.log just to rule out any logging lib swallowing output if the process dies fast. Right under that, add handlers for uncaught exceptions and unhandled rejections that also write directly to stdout — this catches a synchronous throw during module load that would otherwise die completely silently, before your normal logger or Express even spins up:

jsprocess.on('uncaughtException', e => { process.stdout.write(FATAL ${e.stack}\n); process.exit(1); });

process.on('unhandledRejection', e => { process.stdout.write(REJECTION ${e}\n); });

If you want to go further, drop a log line after each init step (env load, Supabase client, Express app creation, the .listen() callback) so if it does start but stalls somewhere, you can see exactly where.

If you deploy with all that and still get absolutely nothing in Deploy Logs — no echo, no BOOT line — that's about as clean a proof as you can get that the container isn't executing your start command at all. That's worth taking straight to Railway support (not just this bounty thread) since it's a much stronger case than "logs are empty" — it shows the earliest possible instrumentation point still isn't showing up.