Reference
Internal error codes
Lofenta uses internal 6xx codes for platform-side deployment states and failures. These codes appear on deployment holding pages and help narrow down the failure class before you read the full log.
How to read them
600 is the active deployment code. It means the project is still building, starting, or waiting for health checks.
The rest of the catalog groups failures by class: repository access, runtime detection, build failure, container startup, and health-check timeout.
These codes do not replace the deployment log. They exist to make the first screen more precise than a generic platform 500.
For health checks, Lofenta treats the service as alive once it responds with any HTTP status below 500 on an expected path. That is intentional: many real apps redirect, challenge, or return 401, 403, or 404 on generic probes before the final routes are configured.
Where they appear
Internal error codes appear first on the temporary project domain page while a deployment is still in progress or after a deployment has failed before the app becomes live.
They are also written into deployment state metadata, which means the dashboard can evolve later to show the same codes inline next to failed deploys and timeline steps.
For now, the most important distinction is simple:
Non-failure state
The service is still deploying. Do not treat it as an outage yet.
Failure class
The deployment stopped. Open the deployment log and use the code to narrow down where to look first.
Catalog
Deployment in progress
Lofenta is still preparing, building, or starting the service.
The deployment has not failed. Lofenta is still building the image, starting the container, or waiting for the app to become healthy.
Template preparation failed
A built-in template could not be prepared before build started.
Lofenta could not scaffold or clone the selected starter template cleanly.
Repository access failed
Lofenta could not clone the repository with the current credentials.
This usually means the repository is private, GitHub organization approval is missing, or the saved OAuth access is no longer valid.
Runtime unsupported
The repository layout did not match a supported runtime.
Lofenta could not detect a valid Dockerfile, static app, or supported server runtime for this project.
Start command missing
The app built, but there was no valid command to launch it.
Add a start script, produce a static build output, or provide a Dockerfile so Lofenta knows how to run the service.
Build failed
The image build or application build step failed.
The build process exited with an error. This includes failing dependency installs, broken builds, or framework compile errors.
Container start failed
The runtime container could not start cleanly.
Lofenta built the image, but the container process exited early or could not bind successfully.
Health check timeout
The service did not respond successfully before the health deadline.
The container started, but Lofenta did not receive a successful HTTP response from the expected port and path in time.
Transferring to another node
Your project is being moved to a healthy node after a fault on its current node.
Automatic high-availability failover for a Standard-tier project. The node running this service became unreachable, so Lofenta is rebuilding it on a healthy node and will route traffic back the moment it is live. No action is needed. This screen clears itself once the service is back. Premium HA keeps a warm standby and fails over instantly, with no transfer screen.
Dedicated IP needed
WHMCS needs a dedicated IP to finish. See the message for the next step.
WHMCS license validation requires a dedicated egress IP attached to this project. This is a one-more-step state, not a platform fault, follow the message shown on the deploy screen to resolve it and redeploy.
Deployment failed
The deployment failed for a reason that does not yet have a narrower internal code.
Check the deployment log for the exact command output. This is the generic fallback code for uncategorized platform-side deploy failures.
Mapping to the deployment lifecycle
These codes intentionally line up with the deployment phases described in the Deployments guide.
Template preparation and repository access problems happen before dependency installation even starts.
Lofenta could not determine how to run the project or did not find a valid launch command.
Dependencies, framework compilation, or image build steps failed.
The image built, but the runtime process did not stay up or was not reachable as expected.
The process is up, but Lofenta never received a successful response on the expected port/path before the timeout.
The platform saw a failure but did not yet match it to a narrower internal class.
Operator playbook
610 / 611
Check template selection first, then GitHub access. Private repositories and newly joined organizations often need a fresh GitHub reconnect or explicit org approval.
620 / 621
Look at the repository shape. Confirm whether the project has a Dockerfile, a supported runtime, or a valid start command. If it is static, verify that the build output really contains an index.html.
630
Read the build log from the top, not just the final line. Most real causes are dependency conflicts, lockfile drift, framework compile errors, or external asset fetch failures.
640 / 650
Read container logs and verify the app binds to the expected port. For Dockerfile-based apps, make sure the container listens on the same internal port Lofenta exposes and health-checks.
690
Treat this as a classification gap. The deployment log is still authoritative, but the failure did not match a narrower internal code yet.