19 days ago
We recently deployed a headless 3D rendering software to Railway using DOCKER. Every time we deploy it, it builds the latest renderer code and runs its service, which is based in TCP.
Problem: For some reason, memory consumption only goes up. At first we believed it was a memory leak from our code, so we inspected it thoroughly, and we also exercised plenty of local testing, however, we could not replicate this behavior.
Because our renderer service kept reaching maximum memory usage limits (2GB), we decided to set up a cron job to restart the service automatically every 15 minutes - in theory, this should clear all the memory usage, if the fault was at our code level.
However, after making these changes, we noticed memory still kept climbing and never got cleared, as if the software never got restarted.
Therefore we are prone to believe this may be an issue with either docker, or railway.
image attached of 6 hours of usage - at 15 mins cronjob for restarts, the memory usage should have dropped every 15 minutes back to 185 MB (Standard usage of our renderer on startup), but that's not the case.
We have been revising our code and deployment options, we simply cannot find out what is wrong, and technical assistance would be most appreciated.
Attachments
3 Replies
Status changed to Open Railway • 19 days ago
19 days ago
We attached our dockerfile:
And our startup script:
19 days ago
Thank you very much for the response, we will try this now. Any additional information on achieving railway level resetarts? Is it through a script inside the container? Or some service?
Cheers.
Status changed to Open brody • 19 days ago
2 days ago
To answer your question about Railway-level restarts: Railway does not have a built-in scheduled restart, but the simplest way is to make your container exit cleanly — Railway will auto-restart it.
The cleanest approach is to wrap your renderer with a timeout in your Dockerfile CMD:
CMD timeout 900 your-renderer-binary; exit 0This exits the container after 15 minutes (900 seconds), and Railway's restart policy brings it back up fresh. No cron job needed.
Alternatively, from inside your container, you can send SIGTERM to PID 1 after a delay:
sleep 900 && kill -SIGTERM 1However — if memory is NOT clearing even after restarts, the issue is likely not your code. Here is what to check:
1. Confirm restarts are actually happening at container level
Check your Railway deployment logs for "Starting Container" entries. If you see them every 15 mins, restarts are working. If not, your cron job may be killing a child process but the main container (PID 1) is still running.
2. Check for Railway persistent volumes
If your service has a Railway Volume attached, files written there persist across restarts. If your renderer writes memory-mapped files or cache to a mounted volume path, they won't be cleared on restart.
3. Docker layer caching is not the cause
Docker image layers are read-only and don't accumulate memory at runtime — so that is not the issue.
4. Check if your renderer is using GPU/shared memory
Headless 3D rendering often uses OpenGL or Vulkan which can allocate GPU-shared memory outside the normal RSS. This would show as growing memory in Railway's metrics even though your process itself is "clean". If this is the case, Railway's memory metrics may be including GPU allocations that are not freed between renders.
Can you confirm whether Railway logs show "Starting Container" every 15 minutes, and whether your renderer uses GPU/OpenGL?