From ee873e01a4d8ed9fcb7639b2426a147dc88930e9 Mon Sep 17 00:00:00 2001 From: ArsHaider <104385372+ArsHaider@users.noreply.github.com> Date: Mon, 9 Dec 2024 15:58:06 -0500 Subject: [PATCH] Update _kbarticles/2024-12-09-apt-buildpack-cache-issue.md Co-authored-by: Mark Boyd Signed-off-by: ArsHaider <104385372+ArsHaider@users.noreply.github.com> --- _kbarticles/2024-12-09-apt-buildpack-cache-issue.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_kbarticles/2024-12-09-apt-buildpack-cache-issue.md b/_kbarticles/2024-12-09-apt-buildpack-cache-issue.md index 2cfa09a7d..216c54fa5 100644 --- a/_kbarticles/2024-12-09-apt-buildpack-cache-issue.md +++ b/_kbarticles/2024-12-09-apt-buildpack-cache-issue.md @@ -11,7 +11,7 @@ The buildpack cache (aka "app cache," or "build artifacts cache") is a per-appli Different buildpacks use this cache for different things. [System buildpacks]({% link _docs/deployment/frameworks.md %}#supported-languages-and-frameworks) are cached on the VM hosting the application container and then mounted as read-only volumes into each staging container. If your application references a custom buildpack or buildpack version via a URLs (to a git repo or a zip file), those buildpacks are downloaded every time application staging occurs. -## The potential issue with the apt buildpack +### The potential issue with the apt buildpack The potential issue involves the / directory disk allocation. The apt buildpack uses /tmp like other buildpacks. The / directory is allocated approximately 9% of the disk allocation. For most buildpacks, this is sufficient as all the possible packages that they could be installing is known with the only variable being the application code. The apt buildpack however, can install a vast number of packages including large packages for example the AWS CLI. When this occurs this allotted 9% of disk space is not sufficient.