Skip to content
Dashboard
Configure 4 min read

Domains and Networking

Understand public and private service access before connecting applications.

Updated 2026-08-30 · 4 min readView as Markdown

Domains and Networking#

NexHost separates public services from internal workspace services at the service-type boundary. The type you choose at creation determines which access model applies, how hostnames are provisioned, and which configuration knobs exist. Understanding that split before you wire applications together prevents the most common connectivity mistakes: trying to reach a private service from the public internet, or exposing an internal worker on a URL that the internet can fetch.

Why the split exists#

Public services are internet-reachable. NexHost provisions a managed hostname, handles inbound HTTP routing, and supports an optional custom domain after your first successful release. Private services and Postgres are reachable only from other services in the same workspace — they are intentionally not on the public internet so internal traffic can stay scoped and least-privileged without extra firewalling on your side.

Public access#

Static Sites, Frontend Apps, and Web Services receive a public hostname after a successful release. Before that release there is no URL to browse — the hostname is a property of the release, not the service declaration.

  • After a successful release the dashboard displays the generated hostname for that service. Open it to confirm the service is responding.
  • You can add a custom domain through the dashboard once the service is ready; see Custom Domains.
  • Public runtime services (Frontend Apps and Web Services) run behind automatic TCP listener discovery and isolated Docker ingress. Static Sites have no process and do not need readiness detection.

What NexHost handles versus what you handle:

ConcernResponsibility
External HTTPS and hostname allocationNexHost handles. Do not front the generated hostname with another reverse proxy unless you intend to operate routing yourself.
Process binding inside the serviceYour application must bind to 0.0.0.0. NexHost supplies PORT=3000 as a compatibility default and discovers the listener it actually opens. Binding only to 127.0.0.1 makes the process unreachable.
External port and readiness URLNexHost handles both. It assigns a unique host port behind the public route and verifies TCP reachability; no customer health path is required.
Info

A fixed internal port such as 3000 or 8080 is safe: every service runs in its own container network namespace. NexHost assigns the external host port and public route.

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. The dashboard is authoritative here — hostnames, ports, connection strings, and internal URLs shown there are the correct values for the current release of that service.

Guidelines for private wiring:

  • Treat the workspace as the network boundary. An internal service in workspace A is not reachable from workspace B, even if both are yours.
  • Read connection information from the private service or database detail screen, not from another service’s logs or from memory of a previous release. Values can change between releases.
  • Do not use a Private Service where users or third-party clients need a public URL. If callers are on the public internet, ship a public runtime instead and enforce application-level authentication.

TCP readiness#

NexHost waits for the application to open a reachable TCP listener during startup. It does not fetch an application URL or require a /health route. Keep a health endpoint if it is useful to your own monitoring, but deployment readiness depends on the process remaining alive, completing initialization, and binding to 0.0.0.0.

Choosing between public types#

The three public host types are distinct products, not aliases for the same runtime:

  • Use Frontend App for a server-rendered UI — Next.js server rendering, Nuxt server output, Remix, SvelteKit with a server adapter, and similar stacks.
  • Use Web Service for an API or general backend — Express, Fastify, Koa, Django, Flask/FastAPI, Go, and other persistent servers that answer API callers.
  • Use Static Site for pre-built files with no server process — hand-written HTML, Vite/React dist, Astro dist, Next.js with output: "export" publishing out, or SvelteKit’s static adapter producing build.
Tip

When in doubt between Frontend App and Web Service, ask where the primary user interaction is. If the product *is* the UI, choose Frontend App. If the product *serves* an API to many clients and the UI is elsewhere, choose Web Service.