Deployment troubleshooting

When a deployment doesn't make it to Live, the failure is almost always in one of two phases: the build (your code couldn't be packaged) or the release (your packaged code wouldn't start). This page covers both.

Open the failed deployment's log in the dashboard before you start; the error message in the log is your fastest path to a fix.

Build failures

Build failures happen during the Cloning or Building phase. Your live version is not affected — only the new deployment is marked Failed.

Cloning failed

Could not access repository inhank-org/my-app

The Inhank Cloud GitHub App can't read your repository. Common causes:

• The app was uninstalled from your GitHub account.
• The repository was removed from the App's Selected repositories list.
• The repository was renamed, moved, or deleted.

Fix:

1. Visit github.com/settings/installations.
2. Find Inhank Cloud → click Configure.
3. Make sure your repository appears under Repository access.
4. Back in Inhank Cloud, click Retry on the failed deployment.

Runtime not detected

Could not detect a supported runtime in your repository.

Inhank Cloud couldn't find any of the supported manifest files (package.json, requirements.txt, go.mod, etc.) at the root of your repository.

Fix options:

• Move your manifest file to the repository root if it's in a subdirectory.
• Add a Dockerfile at the root for a fully custom build.
• See Supported runtimes.

Dependency install failed

Examples:

npm ERR! 404 Not Found: package 'somelib@1.2.3'
ERROR: Could not find a version that satisfies the requirement xyz
fatal: go.sum is out of date

A dependency in your manifest can't be resolved. Almost always something to fix in your code, not in Inhank Cloud.

Fix:

• For Node.js: run npm install locally, commit the updated lockfile.
• For Python: check requirements.txt for typos or unavailable versions.
• For Go: run go mod tidy locally and commit go.sum.

Build command failed

npm run build exited with code 1

Your build script crashed. The lines just before this in the log tell you why — usually a TypeScript error, missing dev dependency, or out-of-memory.

Common fixes:

• Add the missing dependency to package.json and commit.
• Pin Node/Python/Go to the same version you use locally.
• For Node.js out-of-memory: add NODE_OPTIONS=--max-old-space-size=4096 as an environment variable.

Build timed out

If a build exceeds the maximum build duration, it's killed and marked Failed. Causes:

• Stuck network calls during dependency install.
• An infinite loop in a build script.
• Genuinely huge codebases with slow builds.

Fix:

• Audit your build step for runaway commands.
• Switch to a lockfile-based install (npm ci instead of npm install).
• If your build legitimately takes longer than the limit, contact support.

Release failures

The build succeeded, but the new version didn't start cleanly. Symptoms:

• Deployment status: Failed after the Releasing phase.
• Message: New version did not become healthy in time or similar.

Your live version keeps serving traffic — release failures are non-destructive.

App doesn't listen on PORT

By far the most common cause. Your application binds to a hard-coded port (e.g. 3000) instead of process.env.PORT.

Inhank Cloud sets PORT=8080 in your container env, then health-checks your service on that port. If you're not listening there, the health check never passes and the release is aborted.

Fix:

const port = Number(process.env.PORT) || 8080
app.listen(port)  // not app.listen(3000)

# Service settings → Start command:
gunicorn -b 0.0.0.0:$PORT app:app

port := os.Getenv("PORT")
if port == "" { port = "8080" }
http.ListenAndServe(":"+port, nil)

App listens on 127.0.0.1 instead of 0.0.0.0

Binding to 127.0.0.1 only accepts connections from inside the container. Inhank Cloud health-checks from outside. The release fails.

Fix: always bind to all interfaces:

• Express: app.listen(port, '0.0.0.0') (the default in Node, but check)
• Gunicorn: -b 0.0.0.0:$PORT
• Uvicorn: --host 0.0.0.0
• Rails: rails server -b 0.0.0.0
• Go: http.ListenAndServe(":"+port, nil) (note the leading colon)

App crashes on startup

The container starts, then exits immediately. The release fails because the instance never stays up long enough to be healthy.

Fix: open the deployment's runtime log. Look at the lines just before the crash. Common causes:

• A required environment variable is missing. Add it under Environment Variables and redeploy.
• A bad database URL or credentials. Verify the value.
• A migration that fails and exits non-zero.

Startup takes longer than the health-check window

Some applications (JVM, large Rails apps, anything that loads a big model file at boot) take longer than ~2 minutes to be ready.

Fix:

• Move slow startup work into a background task; serve health checks immediately.
• Cache heavy startup artifacts so they don't reload every release.
• Contact support if you legitimately need a longer health-check window.

Deployment stuck

If a deployment sits in Queued or Building for an unusually long time (more than 5 minutes for Queued, more than 30 minutes for Building):

1. Refresh the page — sometimes the UI lags behind reality.
2. Check the build log — if there's no output, something is genuinely wedged.
3. Click Cancel on the stuck deployment, then click Deploy again.
4. If the next deployment is also stuck, contact support with your service name and deployment ID.

App keeps restarting after deploy

The deployment went Live, but your app keeps crashing and restarting.

• Open Logs for the live deployment.
• Look for the crash message just before each restart.
• Common causes:
  • An uncaught exception in your code.
  • Hitting the memory limit (the app is restarted automatically on out-of-memory). See Resource Usage.
  • A bad query / external dependency that times out and panics your process.

Roll back to a previous deployment while you investigate, then ship the fix when ready.

Still stuck?

Email us with:

• Your service name (or its default URL)
• The deployment ID from the URL of the failed deployment
• The last ~20 lines of the build or runtime log

We respond within a business day.