Skip to content
ErawanACADEMYไทย

Keep it running

A build failed. See where it stopped, and let your AI fix it.

When a build fails, the reason comes back as one message, not a wall of log, and the AI that writes your code reads it and keeps fixing. This lesson shows what the common failures look like, and which ones a plain retry will not clear.

Stuck somewhere? Erawan looks into it for free on Hobby and above.

Tell your AI to fix it

When a build fails, the reason goes back to the AI that is putting the app online: a short message saying where it stopped, not the whole log. Most of the time the AI reads it, fixes the code and tries again on its own. If it stops and waits for you, this is enough:

The build failed. Read the reason and fix it.

To see the reason yourself, run this. It is on the last error line, with the list of past versions under it.

erawan status my-app

The version already online keeps running

A failed build changes nothing. If the app was online before, that version keeps serving everyone while your AI fixes the new one. All you lose is the wait.

The common failures

An empty log and the number 137

The build ran out of memory. It was stopped before it could print anything, so the log is empty, and on its own that looks like nothing happened. So Erawan says it in words: the build used up its memory and was stopped (exit 137).

Retrying without changing anything fails the same way, and a bigger plan does not help, because this is a limit on the build, not on the app. Make the build lighter: fewer jobs running at once, a smaller base image, or fewer files copied before the install step. You can tell your AI exactly that.

failed to compute cache key

This reads as if our system broke, but it means a file the Dockerfile copies with COPY did not come up with the rest. The file's name is put at the start of the message for you. Usually the file is listed in .gitignore, and those files are not uploaded, or the path in COPY is spelled differently from the real file.

A dependency will not install

A version that does not exist, a package that was renamed, a lockfile made on a different system. The failing line comes first, followed by the last lines of log before it. Hand this one straight to your AI: it wrote the dependency list, and it can read this error.

The build finished but produced no files

This happens to websites that are built before they go online, such as a site made with Vite or Astro. npm run build ends with no error but writes nothing in the folders Erawan looks in: dist, build, out, public or .output/public. Usually the build is set to write somewhere else. Have your AI point it at one of those folders.

The image is too big for your plan

The build passed, but the image is over your plan's size limit, so it is not kept, and the message gives its size next to the limit. The usual causes are a base image with a full toolchain where a slim one would do, build tools left in the final image, and a package that pulls in ML or GPU libraries. Have your AI shrink the image first. Move up a plan only if the app really needs to be that big.

If the build passed and the app went online, but the new version has a problem in use, the way back is in the next lesson.

All Erawan Cloud lessons