Deployment failed
Diagnose the most common causes of failed app deployments and runtime startup failures.
How a deploy works
Deploys are driven by GitHub Actions, not by a button in the portal. When you
push to your trusted branch, the workflow builds your image, pushes it to your
registry on alawadi.cloud over OIDC, then deploys it to the target container.
You watch the result in the container's Recent deployments list and its
logs. Every deployment shows up as queued, running, succeeded, or
failed. See Deploy with GitHub Actions for the
full flow.
When a deploy fails, the failure is almost always one of the causes below.
Failure checklist
Deploy trust not configured. A push to your registry does not deploy on its
own. The target container needs a GitHub Actions deploy trust. On the
project-scoped container page (Projects > your project > the container), in the
Continuous deployment (GitHub Actions) card, confirm the GitHub
repository and Branch ref you set there match the
repo and branch the workflow runs from (the ref must start with refs/, e.g.
refs/heads/main). If you set an Environment, the workflow job must use that
same environment. A mismatch returns a 403 deploy authorization failure, and
no deployment is recorded.
Image not from your registry. Deployed images must come from
registry.alawadi.cloud/... and belong to a registry your account owns.
Arbitrary public images (for example nginx:1.27 from Docker Hub) are rejected
with 400 BAD_IMAGE.
Mutable image tag. :latest and untagged images are rejected with
400 BAD_IMAGE. Pin the commit SHA (...:${{ github.sha }}) or a @sha256:...
digest. The generated workflow already does this; see the
image rules.
App not listening on port 8080. The platform always routes to 8080. Bind
to 0.0.0.0 and read the PORT environment variable (it is set to 8080). A
container that exits immediately or never binds the port will report unhealthy
after rollout.
Image runs as root. Restricted Pod Security rejects root containers. Your
Dockerfile must add a non-root user and USER it. The
supporting Dockerfile the portal
generates already does.
Resource limits. Out-of-range CPU, memory, or disk are rejected with
400 BAD_RESOURCES. Review the reserved resources on the container's Edit
dialog against the limits.
Insufficient balance. Creating an app or database requires a positive credit
balance. When your balance is zero or negative, the request is rejected with
402 INSUFFICIENT_BALANCE. Redeem a voucher to top up,
then try again. A brand-new account can briefly return
402 ACCOUNT_NOT_INITIALIZED while billing is being set up; wait a moment and
retry.
Account suspended. An account that has run out of credit is suspended and
cannot provision new resources; the request returns 403 ACCOUNT_SUSPENDED.
Redeem a voucher to restore a positive balance and lift
the suspension.
Review recent logs on the container detail page (the Logs card; toggle
Follow for a live stream) and the Recent deployments list for the
failure message. Image, port, or runtime-policy rejections return a 400 (e.g.
BAD_IMAGE, BAD_RESOURCES); see error codes.
Restart the container after changing environment variables so the new values take effect.
Open a support ticket and link the affected project or container if the same error repeats. Include the deployment timestamp and the visible error message.
Previous image stays live
A failed deploy does not replace the last healthy image. Your running app keeps serving while you fix the rollout.