Services Overview
Select the NexHost service type that matches how your application runs.
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 — because each type applies a different runtime contract (no process, an automatically routed public server, a private server, a long-running worker, a finite schedule, a managed database, or a bounded container task).
Picking the right type on creation is cheaper than migrating later: the dashboard’s automatic listener discovery, network exposure, and execution model all branch from that first choice.
The catalog at a glance#
| Service type | Use it for | Public URL? | Lifecycle |
|---|---|---|---|
| Static Site | Pre-built files with no running application server (plain HTML, Vite dist, Astro dist, Next.js out with output: "export", SvelteKit build) | Yes — files are served directly | Built once per deployment; no process |
| Frontend App | Server-rendered Node.js user interfaces with a public URL (Next.js SSR, Nuxt server, Remix, SvelteKit server) | Yes — a Node server is supervised and automatically routed | Built, then a persistent server opens a TCP listener |
| Web Service | Public APIs and full-stack application backends | Yes — same public-runtime model as Frontend App, but for backends | Built, then a persistent server listens on PORT |
| Private Service | Internal services reachable only from inside the workspace network | No — workspace-private | Runtime server on an internal host/port, configured like a Web Service |
| Background Worker | Long-running queue consumers and asynchronous work | No — no external port is exposed | Long-lived process that must stay up; env-driven retries |
| Cron Job | Scheduled commands that finish and exit | No — executed by the scheduler | Finite command on a 5-field UTC cron; exit code signals success |
| Postgres | A private PostgreSQL database with durable storage | No — workspace-private | Managed database; credentials generated for the workspace |
| Workflow | An on-demand container task with run history, timeouts, and retry limits | No — single-shot | Bounded container execution on demand |
Short prompts for the common decisions:
- Content or marketing pages that build to files → Static Site.
- A Next.js / Nuxt / Remix UI that needs a running server → Frontend App.
- An API, a mixed full-stack backend, or anything that answers browser + mobile + webhooks → Web Service.
- Service-to-service APIs inside one workspace → Private Service.
- Continuously running processors → Background Worker.
- A command that should have finished already → Cron Job.
How to choose between the public options#
The three public host types look similar, but they serve different products:
- Static Site knows no notion of runtime listener discovery. It uploads a directory and serves it. There is no process to crash.
- Frontend App and Web Service both start a process, bind to
0.0.0.0, and have their TCP listener discovered automatically. Frontend App is the dedicated UI runtime; Web Service is the general backend runtime. The distinction exists so reviewers and on-call engineers can tell at a glance which service owns the user interface.
If a build can produce both a static folder and a server (for example Next.js), ask: *does any page, route, or feature require runtime execution* — server rendering, API routes, middleware, next/image optimization? If the answer is yes for even one path, choose a runtime type (Frontend App for a UI, Web Service for a backend), not a Static Site.
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 — useful when your build already happens elsewhere. See the Docker Quickstart for the image flow.
The selected stack supplies a starting configuration — build command, start command, and output expectations for a given framework or language. It is a starting point, not a lock-in. Review every command, directory, and environment variable before deployment. A stack that assumed npm run build → dist will misfire when pointed at a Python project or a monorepo with a different layout.
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 and a listener bound to 0.0.0.0. Use a Web Service when the product’s primary job is an API or general backend.
The split is organizational clarity, not technical necessity. Keeping frontends and backends on named, distinct runtimes makes the workspace layout self-documenting — future teammates can read the service list and know immediately which hostname renders the UI and which answers the API calls.
Related documentation#
- Getting Started — the full create → source → build → deploy flow.
- Your First Deployment — numbered archive-to-hostname walkthrough.
- Domains and Networking — public vs private access after the first successful release.
- Deployments and Deployment Troubleshooting — reading stage output when something fails.