1. Does the dashboard "Memory" metric (and billing) use raw cgroup memory.current, or is it adjusted to exclude reclaimable file cache?

The Metric: Platform dashboards and monitoring tools typically ingest the raw container cgroup metrics (memory.current) directly from the container runtime or node exporter.

The Sawtooth Pattern: Because memory.current inherently aggregates anonymous memory + file cache + kernel memory, any accumulation of clean page cache directly inflates the metric you see on your dashboard. When the system or container runtime hits an internal watermark or pressure threshold, the kernel reclaims the file cache, causing the sharp drop in the graph.

1. If it's the raw figure, is this reclaimable cache actually included in usage-based billing?

Usage-Based Impact: If a host or platform calculates billing strictly using raw continuous samples of memory.current, file cache can technically factor into the raw metric readings. However, because page cache is inherently reclaimable and drops instantly the moment other processes or containers demand RAM, it does not represent actual application memory leakage (as proven by your rss/`anon tracking staying flat).

1. What's driving the file growth on an otherwise idle container in the first place?

Even with zero incoming traffic, background processes, runtimes, and logging utilities continually interact with the filesystem. The file growth is typically driven by:

Log Files & Buffers: Node.js, package managers, application logging frameworks, or system utilities writing to stdout/stderr or local log files. Even if flushed, the kernel keeps these recently accessed blocks cached in page cache (file) to speed up subsequent reads.

Runtime & Dependency Activity: Node modules, background garbage collection checks, and dynamic imports read files off the container's overlay filesystem. Every file read results in the kernel caching those disk pages into RAM as page cache, where they remain until memory pressure forces a reclaim.

When you said "idle" do you mean serverless ? because if not, it's a common issue with Linux Kernel. Activate the option serverless and it should stop "billing when idle"

Yes, exactly. When referring to "idle" in standard container hosting, it usually just means zero incoming user traffic while the process itself remains fully booted and running in the background.

Activating Railway's Serverless mode changes this behavior. When enabled, Railway monitors the container and puts it to sleep after 10 minutes of complete inactivity, cutting compute charges entirely while it's sleeping.

If you want to stop paying for those idle hours (and stop watching the page cache sawtooth climb on a container doing nothing), turning on Serverless is the exact fix:

1. Open your service on Railway and go to Settings > Deploy > Serverless.
2. Toggle Enable Serverless.

Keep a couple of things in mind when enabling it:

• Inactivity trigger: Railway detects activity based on outbound packets, not just inbound HTTP requests. If your app has background tasks, persistent database connection poolers, or telemetry phoning home, it will keep sending outbound data and won't sleep. You'll want to ensure database pools close idle connections so the container can actually go quiet.
• Cold boots: When a new request finally hits a slept service, the next request will experience a slight delay while the container spins back up.

Thank you for your answers. By the way yes, idle and serverless are two different things. I do not wish to activate that option as I want the service up all the time, but just curious as to why that's the memory behavior. It doesn't happen with every container, in fact, deploying the same app with node 22 has a different memory print and pattern.

To abidhissain12678-design: Is this information from Railway-internal docs/confirmation on other threads, or general Linux/cgroup reasoning applied here? Reference would help.

The real open question is billing specifically: is reclaimable file cache actually counted in usage-based billing, or excluded? Would appreciate a firmer yes/no, ideally from someone with visibility into the billing pipeline, possibly a Railway employee. But very grateful for your answers so far.

To answer your follow-up questions directly:

• Source attribution: The previous explanation regarding the page cache sawtooth pattern (memory.current aggregating anon, file cache, and kernel memory) is rooted in standard Linux kernel architecture and cgroup v2 behavior (specifically how memory limits, file-backed page caching, and kernel reclaim watermarks operate under memory.stat). It is not a proprietary Railway internal document, but rather standard container runtime mechanics.
• Why Node 22 behaves differently: Different Node.js versions (and their corresponding V8 engines, underlying Alpine/Debian base images, bundled dependency trees, or default GC/serialization profiles) interact with the filesystem differently. A minor shift in how modules are dynamically required, how internal telemetry/source maps are parsed, or how log buffers flush to disk will change the rate at which the kernel populates the page cache (file).
• The Billing Pipeline Question: While I cannot speak directly as an internal Railway billing engineer or provide an official contractual guarantee from deep inside their pipeline, cloud platforms using containerized infrastructure (such as those tracking resource consumption via cgroup metrics) typically bill based on the allocated service limit (e.g., your configured 8GB container ceiling or your specified replica limits) rather than micro-fluctuations in raw active usage—unless operating under strict true-up usage metrics where raw metrics can matter. However, because page cache is inherently volatile, transient, and reclaimed automatically under memory pressure, relying on platform support channels or opening a ticket directly inside Railway's Help/Central Station is the best way to get a definitive, authoritative confirmation from a platform engineer regarding how their precise metering collector samples memory for invoicing.

Then if you don't want to setup serverless, you should probably upgrade or downgrade the underlying config you have (some have the issue and other like node 22 seems to not have the issue)

For billing, Railway will bill anything that use memory or CPU, even if not intended, the issue you reported is continuously using a little bit of memory. As a cloud provider and PaaS they bill for usage of any kind

Thanks for the clarification. I agree that different Node.js versions can influence page-cache behavior, which explains why Node 22 shows a different pattern.

However, I think the remaining unanswered question is whether Railway's billing pipeline charges based on raw memory.current or applies any adjustment to exclude reclaimable file cache. Since that detail isn't part of standard Linux/cgroup behavior, only Railway can confirm it.

If anyone from the Railway team could clarify how the billing collector measures memory usage, that would definitively answer the original question.