# Logs > Use deployment build output and service details to investigate a NexHost release. Source: https://nexthomelabs.com/docs/operations/logs Markdown: https://nexthomelabs.com/docs-md/operations/logs Slug: operations/logs Section: Operate Last updated: 2026-08-30 Reading time: 5 min read --- # Logs The deployment detail page is the primary place to inspect release output on NexHost. Every release records the **source-preparation**, **dependency**, **build**, and **release** stages, plus TCP-readiness observations when the service runs a server. There is no separate "download the full raw log forever" artifact to chase — the detail page is where the platform accumulates the truth of that attempt. Understanding the shape of this output makes debugging faster and keeps you from rediscovering the same cause across multiple releases. ## When to open logs Reach for deployment logs when: - A build passed locally but the remote release failed on the same branch. - The platform accepted the source but startup readiness timed out. - You need to answer "what actually shipped, when, with which settings" for review or on-call triage. If the issue does not involve a deployment (for example a domain-ownership check or a workspace-permission question), the deployment log is unlikely to add signal — prefer the settings screen and its status display for that domain. ## Find the relevant release The workspace has a cross-project **Deployments** screen, and each **project has its own deployment history**. Use them in combination: the workspace view is a live system dashboard, and the per-project history isolates one service. 1. Open **Deployments** in the dashboard. 2. Filter or open the project’s deployment history. 3. Select the release whose status needs investigation — match the **timestamp, status, and source commit or archive name** rather than assuming the first row is your attempt. 4. Read the output **from the first error upward**; later messages often follow from the original failure and will misdirect you if you scan bottom-up. > [!TIP] > Match the exact release rather than skimming the top row. When two teammates deploy concurrently, the release you care about may be one line down. The commit hash or archive filename is the precise identifier — not the human-readable summary alone. ## What the stages mean The detail page splits every release into stages. The ordering is not cosmetic: it mirrors the sequence in which the platform actually performed the work. | Stage | What the platform did | Typical problems at this stage | What to try next | | --- | --- | --- | --- | | **Source** | Resolved the selected repository/archive/folder/image, checked out the chosen branch, and scoped to the root directory | Incorrect repository, archive file, branch, or root directory; image reference that does not resolve | Confirm the branch exists, the root points at the directory that contains the build manifest (`package.json`, `requirements.txt`, `go.mod`, etc.), and the source is the one you intended. | | **Dependencies** | Installed language dependencies (`npm ci`, `pip install -r requirements.txt`, etc.) | Missing lockfile, package not found, network restriction, wrong package-manager selection | Run the **identical** install command locally in a clean checkout of that branch and directory; compare. | | **Build** | Ran the configured build command | Compilation error, framework configuration error, missing environment value needed at build time, failing tests gated into the build step | Run the same production build locally and compare character-by-character with the service’s build command; verify variables scoped to Build/Both where the framework needs them at compile time. | | **Publish or startup** | Static Sites publish the output directory; runtime services start the configured process | Missing static output (`index.html` not found in the publish directory), invalid start command, application that exits immediately | For static: `ls` the local build output and confirm the publish directory (`dist`, `out`, `build`, `.`). For runtime: run the same **start command** locally and confirm it stays alive. | | **TCP readiness** | (Runtime services) Detected a listener and verified that it is reachable through the container network | The application did not open a port, bound only to `127.0.0.1`, or is blocked during initialization | Confirm `listen(port, "0.0.0.0")`; `process.env.PORT` defaults to `3000`, but a fixed internal port is also discoverable. | > [!INFO] > Client-side build values (`NEXT_PUBLIC_*`, `VITE_*`) are intentionally inlined into the artifact during the **Build** stage. An expired key is not a runtime secret rotation — it is a new deployment where the build re-inlines the new value. ## Reading output like a diff Two releases that differ by only one setting are dramatically easier to diagnose than two releases where several things changed at once. When debugging: 1. Make **one** change between attempts (a different publish directory, a corrected branch, an additional environment variable). 2. Re-run the deployment and read the new log against the previous one. The line that changed is where the diagnosis lives. 3. When the same stage fails identically across two corrected attempts, widen the hypothesis rather than retrying blindly. ## Share logs safely The raw deployment detail already contains everything an on-call engineer needs except access to the platform. When you share it, share precisely and without secrets. Before sharing output with another person — whether a teammate, a public forum, or support — **remove**: - Passwords, access tokens, connection strings, and private URLs - Internal hostnames or IP addresses that are not yours to disclose - Full workspace credentials or provider API keys The dashboard output is most useful for support when paired with: - The **project name** and **service name** as shown in the dashboard (not a screenshot of just the header). - The **deployment time** or **deployment URL** (the detail page URL itself). - The **failed stage** name and the first few lines around the earliest error. > [!WARNING] > Never paste real secrets into chat, logs, screenshots, or issue trackers. Redact values and keep key names so reviewers can reason about configuration without seeing the value. ## Related documentation - [Deployments](/docs/deployments) — the full release flow, retry semantics, and restoring a previous successful release. - [Deployment Troubleshooting](/docs/deployments/troubleshooting) — symptom tables that descend from exactly the stages described here. - [Environment Variables](/docs/configuration/environment-variables) — when a build-time vs runtime variable explains a missing value. - [Frontend Apps](/docs/services/frontend-app) / [Web Services](/docs/services/web-services) — runtime contracts for listener binding and startup that determine the final stage.