# NexHost Documentation — Complete Corpus

> Full public documentation for NexHost by Nexthome Labs. Generated 2026-08-29T22:12:38.968Z. Source: https://nexthomelabs.com/docs and https://nexthomelabs.com/llms.txt

> This file is the combined simplified representation of public docs for AI consumption. No secrets or private data are included.

---

# NexHost Documentation

> Choose a service, deploy code, and operate releases on NexHost.

Source: https://nexthomelabs.com/docs
Slug: overview
Section: Getting Started
Keywords: nexhost, hosting, deployment, services
Last updated: 2026-08-30

---

# NexHost Documentation

NexHost lets a workspace deploy websites, server-rendered frontends, APIs, internal services, jobs, databases, and one-off workflows. This documentation describes the service choices and controls available in the NexHost dashboard.

## Start here

- [Getting Started](/docs/getting-started) explains the dashboard flow.
- [Your First Deployment](/docs/getting-started/your-first-deployment) takes a source archive or repository through a release.
- [Services Overview](/docs/services) helps you select the right execution model before you deploy.

## The service model

Each service has a source, build or launch settings where applicable, and a release history. The selected service type controls whether NexHost serves static files, starts a public process, keeps a process private, runs it in the background, schedules it, or provisions a database or workflow.

For a framework with server-side rendering or runtime routes, use a [Frontend App](/docs/services/frontend-app). A static export belongs in a [Static Site](/docs/services/static-sites). APIs and full-stack backends belong in a [Web Service](/docs/services/web-services).

## Working safely

Use the service configuration screen to review the source, commands, environment variables, health path, and deployment history before release. Build output and release status in the dashboard are the source of truth when a deployment needs investigation.

---

# Getting Started

> Create a project, choose the appropriate service type, and configure a first deployment.

Source: https://nexthomelabs.com/docs/getting-started
Slug: getting-started
Section: Getting Started
Keywords: getting started, project, service, deployment
Last updated: 2026-08-30

---

# Getting Started

Start a deployment from **Dashboard → New Project**. The creation flow asks for a service type before asking for source and build details. That choice is important: it determines how NexHost starts, checks, and exposes your application.

## Choose the right service

| If you are deploying… | Choose… |
| --- | --- |
| HTML, CSS, JavaScript, or a framework static export | [Static Site](/docs/services/static-sites) |
| Next.js, Nuxt, Remix, or another server-rendered UI | [Frontend App](/docs/services/frontend-app) |
| An API, backend, or public full-stack server | [Web Service](/docs/services/web-services) |
| A service only other workspace services should reach | [Private Service](/docs/services/private-services) |
| A continuous queue or asynchronous process | [Background Worker](/docs/services/background-workers) |
| A command that runs and exits on a schedule | [Cron Job](/docs/services/cron-jobs) |

## Add a source

The source choices shown depend on the service type. They can include a local folder, ZIP archive, hosted NexHost Git repository, GitHub, GitLab, public Git URL, or an existing container image. Choose the branch and root directory when those controls are shown.

## Configure the release

Set the build command, start command, output directory, and environment variables to match your application. Public runtime services must listen on the injected `PORT`; static services publish the selected output directory instead of starting a server.

For public runtime services, set a health path that returns a successful HTTP response after startup. The dashboard accepts health-check timeouts from 2 to 300 seconds.

## Deploy and inspect

Start the deployment from the final review step. Follow the release in **Deployments** and use its build output if it fails. A successful public service receives the hostname displayed by the dashboard; add a custom domain afterwards when needed.

Continue with [Your First Deployment](/docs/getting-started/your-first-deployment).

---

# Your First Deployment

> Deploy a project from a source archive or repository and verify the release in the dashboard.

Source: https://nexthomelabs.com/docs/getting-started/your-first-deployment
Slug: getting-started/your-first-deployment
Section: Getting Started
Keywords: deployment, zip, git, release, frontend app
Last updated: 2026-08-30

---

# Your First Deployment

This guide covers the dashboard path from local code to a recorded NexHost release. Select the service type before source configuration so the platform applies the right runtime model.

## 1. Prepare the project

Keep generated dependency folders and local secrets out of a source archive. For a static project, either upload source with a build command or an output folder that contains `index.html`. For a server-rendered application, upload the project source and use a **Frontend App** rather than trying to serve `.next` or another server build as static files.

```bash
zip -r my-app.zip . -x "node_modules/*" ".git/*" ".env*"
```

## 2. Create the service

1. Open **Dashboard → New Project**.
2. Select the service type that matches the application.
3. Choose the source method offered by that service.
4. Select a stack when it matches your framework, then review the proposed commands.

For a Next.js application that uses server rendering, choose **Frontend App**, use the normal build command, and set the start command to the application’s production start command.

## 3. Configure runtime services

Runtime services need a process that binds to the `PORT` environment variable and accepts connections on the container interface. For Node applications, the usual shape is:

```ts
const port = Number(process.env.PORT);
server.listen(port, "0.0.0.0");
```

Set the health path to an endpoint that can return a successful response after the application is ready. A frontend can normally use `/`; an API may expose a small `/health` endpoint instead.

## 4. Deploy and verify

Start the deployment from the review screen. The deployment detail page shows source preparation, dependencies, build, and release status. When the release succeeds, open the generated hostname displayed for the service and confirm the health endpoint or application page loads.

If the deployment stops at health checks, confirm all of the following:

- the selected service is **Frontend App** or **Web Service**, not Static Site;
- the start command starts a persistent process;
- the process listens on `process.env.PORT` (or the runtime equivalent);
- the configured health path exists and returns a successful response within the selected timeout.

See [Deployment Troubleshooting](/docs/deployments/troubleshooting) for a guided diagnosis.

---

# Services Overview

> Select the NexHost service type that matches how your application runs.

Source: https://nexthomelabs.com/docs/services
Slug: services
Section: Create
Keywords: services, static site, frontend app, web service, worker, cron, postgres, workflow
Last updated: 2026-08-30

---

# Services Overview

NexHost service types separate static delivery, user-facing Node frontends, public APIs, private processes, background work, scheduled commands, databases, and one-off tasks. Choose the type based on the process you need to run—not just the framework name.

| Service type | Use it for |
| --- | --- |
| [Static Site](/docs/services/static-sites) | Pre-built files with no running application server |
| [Frontend App](/docs/services/frontend-app) | Server-rendered Node.js user interfaces with a public URL |
| [Web Service](/docs/services/web-services) | Public APIs and full-stack applications |
| [Private Service](/docs/services/private-services) | Internal services reachable from the workspace network |
| [Background Worker](/docs/services/background-workers) | Long-running queue consumers and asynchronous work |
| [Cron Job](/docs/services/cron-jobs) | Scheduled commands that finish and exit |
| [Postgres](/docs/services/postgres) | A private PostgreSQL database with generated credentials |
| [Workflow](/docs/services/workflows) | An on-demand container task with run history and retry limits |

## Sources and stacks

Static Sites and Frontend Apps accept repository and archive sources. Web Services, Private Services, Workers, and Cron Jobs can also use an existing image when the dashboard offers it. The selected stack supplies a starting configuration; review every command and directory before deployment.

## The Frontend App distinction

A **Frontend App** is a dedicated public Node.js runtime for UI applications such as Next.js, Nuxt, Remix, and SvelteKit with server output. It is not a backend API service, although it uses the same public-runtime essentials: a start command, `PORT`, and an HTTP health path. Use a Web Service when the product’s primary job is an API or general backend.

---

# Frontend Apps

> Deploy a server-rendered Node.js frontend with its own public runtime and health check.

Source: https://nexthomelabs.com/docs/services/frontend-app
Slug: services/frontend-app
Section: Create
Keywords: frontend app, next.js, node.js, ssr, health check, port
Last updated: 2026-08-30

---

# Frontend Apps

Choose **Frontend App** for a public UI that must run a Node.js server after the build. It is the correct service for Next.js server rendering, Nuxt server output, Remix, and similar frontend frameworks that cannot be deployed as plain static files.

## How it differs from a Static Site

A Static Site publishes generated files such as `dist`, `out`, or `build`; no application server is started. A Frontend App builds your project, then supervises its production start command. The runtime verifies the configured HTTP health path before the release is ready.

If your Next.js project uses `output: "export"`, it can be a Static Site. If it uses API routes, server components that need runtime data, middleware, image optimization, or other server features, choose Frontend App.

## Configure a Node frontend

For a typical Next.js project, the stack proposes:

```text
Build command: npm run build
Start command: npm run start
Health path: /
```

Ensure the application’s start script accepts the runtime port. For example, a Next.js script can be written as `next start -p $PORT`. Do not use `npm run build` as the start command; the runtime needs a long-running server after the build completes.

## Health checks

The default health path is `/`. You may choose another application route that returns a successful response after startup. Keep it lightweight and ensure it does not require a user session. If the health check times out, inspect the start command and build log first, then confirm the path and `PORT` handling.

## Deploy

Choose the Frontend App service in **New Project**, connect a supported source, review the commands, and deploy. The generated public URL and deployment detail page are shown after a successful release.

---

# Static Sites

> Publish pre-built HTML, CSS, JavaScript, and assets without a long-running application server.

Source: https://nexthomelabs.com/docs/services/static-sites
Slug: services/static-sites
Section: Create
Keywords: static site, vite, react, astro, next export, publish directory
Last updated: 2026-08-30

---

# Static Sites

A Static Site serves a generated directory of files. Choose it for plain HTML and for frameworks configured to produce a static export. Because no server process runs after the build, a Static Site does not use a start command or runtime health check.

## Common output directories

| Project | Typical build command | Publish directory |
| --- | --- | --- |
| Vite or React | `npm run build` | `dist` |
| Astro | `npm run build` | `dist` |
| Next.js static export | `npm run build` | `out` |
| SvelteKit with a static adapter | `npm run build` | `build` |
| Plain HTML | none | `.` |

The directory must contain the final `index.html` and referenced assets. Review the detected framework and publish directory in the service configuration before deployment.

## Next.js static export

Set `output: "export"` in the project’s Next configuration, build the project, and publish `out`. Do not upload a normal `.next` directory to a Static Site; it needs a running server and should be deployed as a [Frontend App](/docs/services/frontend-app).

## Deploy

Select **Static Site**, choose a repository or archive source, set the build command and publish directory, then deploy. Use the deployment detail page to check whether the configured output directory was found.

---

# Web Services

> Run a public API or full-stack application that listens on an HTTP port.

Source: https://nexthomelabs.com/docs/services/web-services
Slug: services/web-services
Section: Create
Keywords: web service, api, backend, node.js, port, health check
Last updated: 2026-08-30

---

# Web Services

Choose **Web Service** for public APIs, application backends, and full-stack servers. It starts a persistent process behind a public URL and checks an HTTP path before the release becomes ready.

## Required runtime behavior

Your application must start successfully and listen on the port provided in `PORT`. It should bind to `0.0.0.0`, not only to localhost. A Node server normally follows this pattern:

```ts
const port = Number(process.env.PORT);
app.listen(port, "0.0.0.0");
```

Set a health path such as `/health` to a route that returns a successful response without an authenticated session. The release waits for that route within the timeout selected in the dashboard.

## Configure and deploy

Choose a supported source, select a compatible stack or enter the build and start commands, then set environment variables and the health path. Use the build log to diagnose dependency or build failures; use the deployment details to distinguish a successful build from an application startup or health-check failure.

## When to choose Frontend App instead

Use [Frontend App](/docs/services/frontend-app) when the service is primarily a server-rendered user interface. Both types are public Node runtimes, but the dedicated Frontend App choice makes the frontend execution model explicit in the project workflow.

---

# Private Services

> Run an internal service that is reachable by services in the same workspace network.

Source: https://nexthomelabs.com/docs/services/private-services
Slug: services/private-services
Section: Create
Keywords: private service, internal service, workspace network
Last updated: 2026-08-30

---

# Private Services

A Private Service is a persistent application that does not receive a public URL. Use it for internal APIs, internal webhooks, or application components that should only be called by services in the same workspace network.

## Configure it like a runtime service

Choose a source, set build and start commands, and configure any required environment variables. If the service exposes HTTP, provide a health path so the deployment can verify startup. Keep credentials and service connection details in the workspace configuration rather than committing them to source.

## Connect from other services

The dashboard provides the private service’s connection details in its service configuration. Use those displayed details from other services in the same workspace. Do not expect a private service to be reachable directly from the public internet.

---

# Background Workers

> Run a long-lived process for queues, media processing, and asynchronous work.

Source: https://nexthomelabs.com/docs/services/background-workers
Slug: services/background-workers
Section: Create
Keywords: background worker, queue, asynchronous, worker
Last updated: 2026-08-30

---

# Background Workers

Choose **Background Worker** for a process that should remain running but does not serve a public HTTP application. Typical uses include queue consumers, media processing, event handlers, and continuous synchronization jobs.

## Configure the process

Set the source and start command that keeps the worker running. Configure its connection strings, credentials, and queue settings as environment variables in the dashboard. A worker should handle retries and failures in its own job logic; use a [Cron Job](/docs/services/cron-jobs) instead when work is naturally scheduled and finite.

## Observe releases

Use the deployment detail page to inspect source preparation, dependency installation, and startup state. If a worker exits unexpectedly, review the start command and its application output before redeploying.

---

# Cron Jobs

> Run a finite command on a UTC schedule.

Source: https://nexthomelabs.com/docs/services/cron-jobs
Slug: services/cron-jobs
Section: Create
Keywords: cron, scheduled job, utc, task
Last updated: 2026-08-30

---

# Cron Jobs

A Cron Job starts a command on a schedule, performs a finite task, and exits. It is appropriate for reports, cleanup, data imports, and periodic synchronization—not for a process that must stay online.

## Schedule and command

Choose **Cron Job**, configure a supported source or image, set the command, and enter a standard five-field cron expression. NexHost schedules cron jobs in UTC, so convert business-time requirements before saving the schedule.

## Good job behavior

Make each run safe to retry, exit with a non-zero code on failure, and write actionable application output. Use a [Background Worker](/docs/services/background-workers) for queue consumers or any process that should not exit after a single run.

---

# Postgres

> Provision a private PostgreSQL database with durable storage and generated connection credentials.

Source: https://nexthomelabs.com/docs/services/postgres
Slug: services/postgres
Section: Create
Keywords: postgres, database, connection string, private database
Last updated: 2026-08-30

---

# Postgres

Choose **Postgres** to provision a private PostgreSQL database for services in your workspace. The service creation flow provides generated connection credentials and durable local storage.

## Connect an application

Create the database first, then copy its displayed connection details into the environment configuration of the service that needs it. Treat the connection string as a secret: do not put it in browser code or commit it to a repository.

## Operations

Manage the database through its project and service screens. Before making destructive schema or data changes, create and verify a backup plan appropriate for the application.

---

# Workflows

> Run an on-demand container task with run history, timeouts, and bounded retries.

Source: https://nexthomelabs.com/docs/services/workflows
Slug: services/workflows
Section: Create
Keywords: workflow, task, container, retry, timeout
Last updated: 2026-08-30

---

# Workflows

A Workflow runs a container task on demand. Use it for bounded work that should have a recorded run history, a timeout, and retry limits instead of a permanently running process.

## Configure the task

Choose **Workflow**, provide the container image and command required for the task, then set the task timeout and retry limit. Keep the command deterministic and make it safe to retry where possible.

## Review runs

The workflow screen records each invocation and its outcome. Inspect a failed run before retrying so a configuration or input problem is not repeated automatically.

---

# Environment Variables

> Configure build-time and runtime values for a NexHost service without committing them to source.

Source: https://nexthomelabs.com/docs/configuration/environment-variables
Slug: configuration/environment-variables
Section: Configure
Keywords: environment variables, configuration, secrets, build, runtime
Last updated: 2026-08-30

---

# Environment Variables

Use the service configuration screen to supply values that vary by environment, such as database connection strings, API credentials, and feature flags. Keep these values out of source archives and repositories.

## Scopes

Each variable can be available during one or both parts of a deployment:

| Scope | Use it when |
| --- | --- |
| Build | A build tool needs the value while generating the application output |
| Runtime | The running process needs the value after it starts |
| Both | The value is required during the build and by the running service |

Static-site values are incorporated into the built output. Change a build-time value and deploy again so a new artifact is produced. Runtime services receive their runtime configuration when they start; redeploy or restart the service after changing values that affect startup.

## Set a value

1. Open the service settings in the dashboard.
2. Add the key, value, and appropriate scope.
3. Save the configuration.
4. Start a deployment when the change needs a new build or runtime process.

## Keep secrets server-side

Do not use browser-exposed variables for credentials. Frontend frameworks may embed specially prefixed values into client-side bundles; check your framework’s documentation before putting any sensitive value in a build-time variable.

## Runtime port

Public Node services receive `PORT` from the runtime. Do not replace it with a hard-coded port; configure the application to listen on the provided value instead.

---

# Custom Domains

> Attach a domain to a public NexHost service and complete the dashboard-guided DNS verification.

Source: https://nexthomelabs.com/docs/configuration/custom-domains
Slug: configuration/custom-domains
Section: Configure
Keywords: custom domain, dns, tls, ssl, domain verification
Last updated: 2026-08-30

---

# Custom Domains

Add a custom domain from the project’s domain settings after a public service has a successful release. The dashboard provides the exact DNS records required for the selected domain and reports the current verification status.

## Add the domain

1. Open **Dashboard → Domains** or the project’s domain settings.
2. Enter the hostname you want to use, such as `www.example.com`.
3. Choose the available DNS management option.
4. Copy the ownership and routing records shown by the dashboard into your DNS provider.
5. Run verification after the records have propagated.

Do not guess record names or targets from another project. The values displayed for the domain you are adding are authoritative.

## TLS

When the domain is verified and attached to a public service, NexHost manages certificate issuance for that hostname. Leave the verification records in place unless the domain screen tells you otherwise.

## Common issues

| Status | What to check |
| --- | --- |
| Ownership pending | The ownership record exactly matches the dashboard value and has propagated at the DNS provider. |
| Routing pending | The host record matches the target shown for this domain. |
| Certificate pending | Complete ownership and routing verification first, then check the domain screen for its current status. |

If a record looks correct but verification remains pending, use the dashboard’s support path and include the domain and displayed status—never post DNS credentials or service secrets.

---

# Domains and Networking

> Understand public and private service access before connecting applications.

Source: https://nexthomelabs.com/docs/configuration/networking
Slug: configuration/networking
Section: Configure
Keywords: networking, public service, private service, domain, port
Last updated: 2026-08-30

---

# Domains and Networking

NexHost separates public services from internal workspace services. The type you choose at creation determines which access model applies.

## Public access

Static Sites, Frontend Apps, and Web Services receive a public hostname after a successful release. You can add a custom domain through the dashboard once the service is ready. Public runtime services listen on the injected `PORT`; NexHost handles the external HTTP routing.

## Private access

Private Services and Postgres are intended for use inside the workspace network. Use the connection details displayed in the dashboard from other workspace services. Do not use a Private Service where users or third-party clients need a public URL.

## Health paths

Frontend Apps and Web Services can use an HTTP health path. The path must start with `/` and return a successful response before the configured timeout. Use a page such as `/` for a frontend or a small unauthenticated endpoint such as `/health` for an API.

## Choosing between public types

- Use [Frontend App](/docs/services/frontend-app) for a server-rendered UI.
- Use [Web Service](/docs/services/web-services) for an API or general backend.
- Use [Static Site](/docs/services/static-sites) for pre-built files with no server process.

---

# Deployments

> Follow a NexHost release from source preparation through build, startup, and readiness.

Source: https://nexthomelabs.com/docs/deployments
Slug: deployments
Section: Operate
Keywords: deployments, releases, build logs, health check, restore
Last updated: 2026-08-30

---

# Deployments

Every deployment records the source, configuration, build output, and final status. Open **Deployments** from the dashboard to see releases across the workspace or use a project’s deployment history for a single service.

## Release flow

1. **Source** — NexHost prepares the selected repository, archive, folder, or image.
2. **Dependencies and build** — the configured install and build commands run when required.
3. **Publish or start** — a Static Site publishes its output directory; a runtime service starts its configured process.
4. **Readiness** — public runtime services must pass their configured HTTP health path before the release is ready.

The release detail page shows which step failed. A successful build followed by a failed health check is a startup/configuration issue, not a source-build issue.

## Review a deployment

Open a deployment to review its source information, framework detection where available, output directory, build log, and timestamps. Use **Retry deployment** only after correcting the relevant source or configuration problem.

## Restore a release

When the project shows a previous successful release, use the restore action on that release to make it active again. Review the release summary before confirming the change so the correct service and version are selected.

## Next steps

- [Deployment Troubleshooting](/docs/deployments/troubleshooting)
- [Logs](/docs/operations/logs)
- [Frontend Apps](/docs/services/frontend-app)

---

# Deployment Troubleshooting

> Diagnose source, build, startup, and health-check failures from the deployment detail page.

Source: https://nexthomelabs.com/docs/deployments/troubleshooting
Slug: deployments/troubleshooting
Section: Operate
Keywords: troubleshooting, build failure, health check, port, deployment
Last updated: 2026-08-30

---

# Deployment Troubleshooting

Start with the exact stage and message shown on the deployment detail page. The most useful first distinction is whether the release failed while preparing/building source or after the application started.

## Source and build failures

| Symptom | Check |
| --- | --- |
| Dependency installation fails | Lockfiles, package manager selection, and the configured root directory. |
| Build command fails | Run the same production build locally and compare the command with the service configuration. |
| Static output is not found | Confirm the publish directory contains the generated `index.html` and assets. |
| Wrong service type | Use Static Site only for exported files; use Frontend App or Web Service for a server build. |

## Startup and health-check failures

| Symptom | Check |
| --- | --- |
| Health check timed out | The start command launches a persistent process, and the configured path exists. |
| Connection refused | The application listens on the injected `PORT` and binds to `0.0.0.0`. |
| Health path returns an error | Use a route that is available without user authentication and succeeds after startup. |
| Next.js static deployment fails | If the project does not use `output: "export"`, create a Frontend App instead. |

## Make one correction at a time

Update the source or configuration, then start a new deployment. Compare the new log with the previous one instead of changing several settings at once. If the same failure persists, collect the deployment URL, stage, and relevant log lines for support—remove secrets before sharing any output.

---

# Logs

> Use deployment build output and service details to investigate a NexHost release.

Source: https://nexthomelabs.com/docs/operations/logs
Slug: operations/logs
Section: Operate
Keywords: logs, build logs, deployment details, troubleshooting
Last updated: 2026-08-30

---

# Logs

The deployment detail page is the primary place to inspect release output. It records the source-preparation, dependency, build, and release stages for a deployment.

## Find the relevant release

1. Open **Deployments** in the dashboard.
2. Filter or open the project’s deployment history.
3. Select the release whose status needs investigation.
4. Read the output from the first error upward; later messages often follow from the original failure.

## What the stages mean

| Stage | Typical problems |
| --- | --- |
| Source | Incorrect repository, archive, branch, or root directory. |
| Dependencies | Missing lockfile, unavailable package, or install-command failure. |
| Build | Compilation, framework configuration, or missing environment value. |
| Publish or startup | Missing static output, invalid start command, or an application that exits. |
| Health check | The application did not listen on `PORT`, the path is wrong, or it did not become ready in time. |

## Share logs safely

Before sharing output with another person, remove passwords, access tokens, connection strings, and private URLs. The dashboard output is useful for support when paired with the project name, deployment time, and failed stage.

---

# Storage and Release Artifacts

> Understand the difference between immutable deployment artifacts and application data.

Source: https://nexthomelabs.com/docs/storage
Slug: storage
Section: Create
Keywords: storage, artifacts, releases, persistence, data
Last updated: 2026-08-30

---

# Storage and Release Artifacts

Each successful build produces the artifact used for that release. Release artifacts are managed by NexHost and are separate from the source archive or repository you uploaded.

## Release artifacts

Static Sites publish the configured output directory. Runtime services use the prepared build and startup configuration for their release. Treat artifacts as deployment outputs: make source changes in your repository or archive, then create a new release rather than editing a previous artifact.

## Application data

Do not rely on a deployment artifact as mutable application storage. Store durable relational data in [Postgres](/docs/services/postgres) or use the data service appropriate to the application. Keep backups and data-retention decisions under your team’s control.

## Secrets and uploads

Keep secrets in [Environment Variables](/docs/configuration/environment-variables), not in source or release files. Decide how user uploads and generated media will be stored before deployment; a deployment release can change independently of that application data.

---

# Workspaces and Access

> Keep project ownership, access, and support information organized within a NexHost workspace.

Source: https://nexthomelabs.com/docs/teams
Slug: teams
Section: Teams and Billing
Keywords: workspace, team, access, projects, billing
Last updated: 2026-08-30

---

# Workspaces and Access

Projects, services, repositories, domains, and billing are organized in a NexHost workspace. Confirm the active workspace before creating a project or changing a domain so the new resource is visible to the intended team.

## Practical access hygiene

- Keep project ownership and billing contact information current in workspace settings.
- Use a dedicated project or service for each independently deployable application.
- Review deployment history before restoring a release.
- Remove credentials from source and deployment logs before sharing them with collaborators or support.

## Getting help

Use **Documentation** from the dashboard navigation for product guidance and **Support** for an account or deployment issue. Include the project name, service name, and deployment time when relevant; do not include passwords, access tokens, or database credentials.

---

# Billing

> Review workspace billing information and complete payment actions from the NexHost dashboard.

Source: https://nexthomelabs.com/docs/billing
Slug: billing
Section: Teams and Billing
Keywords: billing, invoices, payment, workspace
Last updated: 2026-08-30

---

# Billing

Open **Dashboard → Billing** to review the billing information associated with the active workspace. Use the values and actions presented there as the current source of truth for plan, payment, and account details.

## Before changing billing details

Confirm that you are in the correct workspace and that the billing contact is current. Keep payment information in the secure dashboard flow; do not send card details, account credentials, or transaction references through project logs or support messages unless the support channel explicitly requests a safe method.

## Need help?

Use the dashboard’s Support entry for a billing question and include the workspace name and any non-sensitive reference shown in the billing view.

---

# Next CLI

> Use the NexHost Git command-line interface to work with hosted repositories.

Source: https://nexthomelabs.com/docs/cli
Slug: cli
Section: Operate
Keywords: next cli, nexhost cli, git, repositories, source control
Last updated: 2026-08-30

---

# Next CLI

The Next CLI is NexHost’s hosted Git command-line interface. It manages repository authentication and delegates source-control operations to the standard Git workflow. It does **not** trigger deployments, stream service logs, or set deployment environment variables.

## Install

Download the current package from [CLI Downloads](/cli/downloads). On Debian or Ubuntu, install the downloaded package with:

```bash
sudo apt install ./next-cli_0.1.0_all.deb
```

The platform command names are `next`, `nexhost`, and `nex`. `next` is the first-class source-control command; do not overwrite an existing Next.js framework binary without checking your local environment.

## Sign in and work with a repository

```bash
next login --team YOUR_WORKSPACE
next repo list
next clone YOUR_WORKSPACE/YOUR_REPOSITORY
cd YOUR_REPOSITORY
next status
next add .
next commit -m "Initial commit"
next push
```

You can also use `next login --device --team YOUR_WORKSPACE` for browser approval or `next login --pat` to enter a personal access token securely.

## Available commands

| Command | Purpose |
| --- | --- |
| `login`, `logout`, `whoami` | Manage the current hosted-Git session |
| `repo list`, `repo create` | View or create hosted repositories |
| `init`, `clone` | Start or retrieve a repository |
| `status`, `add`, `commit`, `push`, `pull`, `sync` | Run familiar source-control operations |
| `doctor` | Check the local CLI and Git setup |

After you push source, connect that repository to a NexHost service in the dashboard to create a deployment.

---

# NexHost Git

> Create, clone, and connect a NexHost-hosted Git repository to a service.

Source: https://nexthomelabs.com/docs/git
Slug: git
Section: Operate
Keywords: git, repository, clone, push, nexhost git
Last updated: 2026-08-30

---

# NexHost Git

NexHost Git provides hosted repositories that can be selected as a service source. Repository access is managed through the dashboard and the [Next CLI](/docs/cli).

## Create a repository

Open **Dashboard → Repositories** and create a repository in the intended workspace. Choose its visibility and copy the clone information presented by the dashboard.

You can also create a repository from the CLI:

```bash
next login --team YOUR_WORKSPACE
next repo create my-service --private
```

## Push source

```bash
next clone YOUR_WORKSPACE/my-service
cd my-service
next add .
next commit -m "Initial service"
next push
```

Use `next doctor` if authentication or the local Git configuration is not ready. The CLI keeps credentials out of repository remote URLs.

## Connect it to a service

During **New Project**, choose NexHost Git as the source when it is offered, select the repository and branch, then review the service’s build, start, or publish settings. A source push does not by itself change a live release; start or configure the service deployment from the dashboard.

---

# API Access and Availability

> Understand the current supported programmatic interfaces for NexHost.

Source: https://nexthomelabs.com/docs/api
Slug: api
Section: Operate
Keywords: api, cli, git, automation, programmatic access
Last updated: 2026-08-30

---

# API Access and Availability

The NexHost dashboard uses authenticated control-plane endpoints for its own interface. Those browser endpoints are not published as a general-purpose public REST API contract and should not be used for unsupported automation.

## Supported programmatic interface

For hosted repository workflows, use the [Next CLI](/docs/cli). It supports repository login, creation, clone, push, pull, sync, and diagnostics using the authenticated NexHost Git interface.

## Dashboard actions

Create and manage services, deployments, domains, and billing through the dashboard. The exact actions available to your workspace are shown there and can change as the product evolves.

## Building integrations

If you need an integration that cannot be completed in the dashboard or through the Git CLI, contact NexHost support with the workflow you need. Do not embed browser session credentials in scripts or rely on undocumented dashboard URLs; that can break without notice and may expose account access.

---

# Node.js Quickstart

> Deploy a small Node.js HTTP application as a NexHost Web Service.

Source: https://nexthomelabs.com/docs/quickstarts/node
Slug: quickstarts/node
Section: Quickstarts
Keywords: node.js, express, web service, port, quickstart
Last updated: 2026-08-30

---

# Node.js Quickstart

This quickstart deploys a small HTTP application as a [Web Service](/docs/services/web-services). Use [Frontend App](/docs/services/frontend-app) instead for a server-rendered Next.js or similar UI.

## Create the application

```bash
mkdir my-node-app && cd my-node-app
npm init -y
npm install express
```

Create `index.js`:

```js
const express = require("express");
const app = express();
const port = Number(process.env.PORT);

app.get("/", (_request, response) => response.send("Hello from NexHost"));
app.get("/health", (_request, response) => response.status(200).json({ ok: true }));

app.listen(port, "0.0.0.0");
```

Set the start script in `package.json`:

```json
{ "scripts": { "start": "node index.js" } }
```

## Configure the service

1. In **New Project**, select **Web Service**.
2. Choose a supported source and connect this project.
3. Set **Start command** to `npm start`.
4. Set **Health path** to `/health`.
5. Deploy and open the generated hostname shown by the dashboard.

The server must use `process.env.PORT` and bind to `0.0.0.0`. See [Deployment Troubleshooting](/docs/deployments/troubleshooting) if the health check fails.

---

# Python Quickstart

> Deploy a Python HTTP application as a NexHost Web Service.

Source: https://nexthomelabs.com/docs/quickstarts/python
Slug: quickstarts/python
Section: Quickstarts
Keywords: python, flask, fastapi, web service, quickstart
Last updated: 2026-08-30

---

# Python Quickstart

Use a [Web Service](/docs/services/web-services) for a Python HTTP application. The runtime command must bind to the port supplied in `PORT`.

## Create a Flask application

Create `app.py`:

```python
import os
from flask import Flask

app = Flask(__name__)

@app.get("/")
def home():
    return "Hello from NexHost"

@app.get("/health")
def health():
    return {"ok": True}

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=int(os.environ["PORT"]))
```

Create `requirements.txt`:

```text
Flask
gunicorn
```

## Configure the service

1. Select **Web Service** in **New Project**.
2. Connect the repository or archive containing `app.py` and `requirements.txt`.
3. Set **Build command** to `pip install -r requirements.txt`.
4. Set **Start command** to `gunicorn app:app --bind 0.0.0.0:$PORT`.
5. Set **Health path** to `/health`, then deploy.

For FastAPI, use a comparable `uvicorn` start command that sets `--host 0.0.0.0` and `--port $PORT`.

---

# Static Sites Quickstart

> Deploy a Vite, React, Astro, or exported Next.js frontend as a NexHost Static Site.

Source: https://nexthomelabs.com/docs/quickstarts/static-sites
Slug: quickstarts/static-sites
Section: Quickstarts
Keywords: static site, vite, react, astro, next.js, quickstart
Last updated: 2026-08-30

---

# Static Sites Quickstart

Use a [Static Site](/docs/services/static-sites) when your project produces files that can be served without a running Node or application server.

## Example: Vite and React

```bash
npm create vite@latest my-site -- --template react
cd my-site
npm install
npm run build
```

The build creates `dist/index.html` and its assets.

## Configure the service

1. Select **Static Site** in **New Project**.
2. Connect a repository, folder, or ZIP archive.
3. Set **Build command** to `npm run build`.
4. Set **Publish directory** to `dist`.
5. Deploy and open the generated hostname displayed by the dashboard.

## Other static outputs

| Project | Publish directory |
| --- | --- |
| Astro | `dist` |
| Next.js with `output: "export"` | `out` |
| SvelteKit with static adapter | `build` |
| Plain HTML | `.` |

If the application needs a runtime server after build, use [Frontend App](/docs/services/frontend-app) instead.

---

# Docker Quickstart

> Deploy an existing container image as a compatible NexHost runtime service.

Source: https://nexthomelabs.com/docs/quickstarts/docker
Slug: quickstarts/docker
Section: Quickstarts
Keywords: docker, container image, web service, worker, quickstart
Last updated: 2026-08-30

---

# Docker Quickstart

Choose an existing container image source when you already build and publish your application image. Image sources are available for Web Services, Private Services, Background Workers, and Cron Jobs—not Static Sites or Frontend Apps.

## Select the service type first

- **Web Service**: a public HTTP server.
- **Private Service**: an internal HTTP or application service.
- **Background Worker**: a persistent process without a public URL.
- **Cron Job**: a command that runs on a schedule and exits.

## Configure the image

1. Start **New Project** and select the appropriate runtime service.
2. Choose **Existing image** when it is offered as the source.
3. Enter the image reference and required command settings.
4. Add environment variables in the service configuration.
5. For a public Web Service, configure an HTTP health path and ensure the container listens on the injected `PORT`.

Use the deployment detail page to verify that image preparation, startup, and any health check complete successfully.

---


> End of corpus. 28 articles. Sitemap: https://nexthomelabs.com/sitemap.xml