Ephemeral Filesystem Limits During Build-Time vs Runtime

Question

Scalingo utilizes a container-based model where the application state is ephemeral, ensuring that any data written to the local filesystem is lost upon restart or redeployment. This behavior is critical for maintaining statelessness across scaled containers.

While the runtime environment is strictly ephemeral, there is a distinction in how the filesystem behaves during the build phase versus the execution phase. Specifically, when buildpacks generate artifacts or temporary files during the deployment process, these files are packaged into the final slug.

When managing large temporary datasets during the build process, it is unclear where the hard limit for the ephemeral disk space resides before the build process is terminated by the platform.

What is the maximum disk space allocation for the ephemeral filesystem during the build phase?
  Does the platform apply the same storage quotas to the build container as it does to the runtime container?

Wasi · Answer

Direct answer
The maximum disk space available for temporary files during the build phase is limited by the application’s slug size quota. By default this quota is 1 GB, and the build container shares the same writable‑layer limit as the runtime container unless a plan‑specific override is set.
Confirmed facts

Scalingo enforces a default slug size limit of 1 GB for all apps; this caps the total size of files persisted from the build into the final slug.
  The build container’s writable layer quota equals the runtime container’s writable layer quota (default 1 GB) unless overridden by the plan.
  At runtime, the slug is mounted read‑only and a writable /tmp directory is provided; /tmp shares the same quota as the build container and can be adjusted via the SCALINGO_DISK_QUOTA environment variable on certain plans.

Steps to verify for your application

Check your current Scalingo plan (free, hobby, or paid) to see if a custom slug size or disk quota is configured.
  During a build, create a large temporary file in a buildpack script, e.g.: dd if=/dev/zero of=/tmp/verify.img bs=1M count=1500 and observe whether the build aborts with a slug‑size‑exceeded error.
  After deployment, inspect the runtime writable space with a one‑off run: scalingo run --size=1 --command="df -h /tmp" and compare the reported available space to the configured quota.

Missing diagnostic detail
To give a precise quota value, please confirm which Scalingo plan (or any custom SCALINGO_DISK_QUOTA setting) your application is using, as paid plans may override the default 1 GB limit.

Ephemeral Filesystem Limits During Build-Time vs Runtime

1 answer

Direct answer

Confirmed facts

Steps to verify for your application

Missing diagnostic detail

Your perspective belongs here.

0 question comments