A Node API, run as one process that stays up.
One long-running Node process runs on a dedicated instance, sized to the app. Attach a managed database when the app needs one. CodeHerder ships the small changes that follow launch.
When this isn't the right fit Does the app never answer a live request, like a scheduled batch job with no endpoint? Then read Background jobs instead. A job that never listens needs no standing web process.
What it needs to run
The shape of the workload, before any hosting decision gets made.
- Runtime
- Node.js, long-running
- Build step
- Install and (if used) a TypeScript or bundler build, on every push
- Standing process?
- Yes: one process, kept alive by a process manager
- Data store
- Optional. Most APIs attach Postgres once they need to store anything.
- Verdict
- Dedicated, almost always
How it runs here
The same management as every other tier we run, written in Node.js's own terms.
Provisioning
A dedicated instance with Node installed. A process manager restarts the app on a crash or a deploy.
Deploys
Push to main. The pipeline builds the app and restarts the process. You run no CI of your own.
Data + backups
Attach a managed Postgres tier and it backs up every night with the app.
TLS / DNS / monitoring
Certificates renew on their own and we manage DNS end to end. Monitoring restarts a crashed process and alerts a person.
What a visitor sees during a restart →
Moving it in
Already running somewhere else? The full migration playbook covers the general steps. Below is what is specific to Node.js.
- 1
Point us at the repo
We need read access and the start command. We read the runtime from the package file, so there is no questionnaire.
- 2
We stand up a copy
We provision it as code, and build and start it the way your deploys will run. We check it before anything goes live.
- 3
Cutover on your schedule
DNS and TLS switch over with little-to-no downtime. A rollback stays ready if anything looks wrong.
- A process manager restarts a crashed app. It does not fix the bug that crashed it. Check the logs first, then brief the fix.
- In-memory state does not survive a restart. A cache, a session or a queue held in RAM needs a store that outlives the process.
- The app must read its port from the environment at start, not from a hard-coded value. Check `process.env.PORT` before the first deploy.
- A queue worker or a scheduled job needs its own process. Run one as a route inside the API and it only delays the request that triggers it.
The loop, on Node.js
A Node API rarely needs a rewrite after launch. It needs new routes, bug fixes and small dependency bumps, and the loop ships each one.
- 01Build
CustomLabs
Bring an API you already run. Or CustomLabs designs and builds the first version in the framework you picked.
- 02Iterate
CodeHerder
Brief a new route, a validation fix or a dependency bump in plain language. An agent opens a pull request against the real repo.
- 03Run
CustomHosted
One long-running process on a dedicated instance, restarted on a crash and on a deploy. We patch it and back it up.
- The brief
- A rate limit on a public endpoint, plus a clearer error when a request is missing a required field.
- What the pull request holds
- The middleware and the validation check, in one pull request the agent opens against the real repo.
- What happens next
- A human reviews and merges. It ships through the same pipeline.
- A real one
- The site is blinding at night (+751 −258 · 19 files · merged 2026-07-31).
This page covers a plain Node API, and nothing else
Six other pages already own the topics a Node app runs into. This page draws the line, so no two pages say the same thing.
This page is for a plain Express or Nest service: one process, one job, and no framework-specific rendering rules. Next.js is a different case. It has a static-export mode and a server-rendered mode, and that choice decides the hosting shape. The language underneath does not. See Next.js hosting for that split.
If the app already ships as a container, run it on the container path instead. The pricing is the same single-process shape. Only the provisioning step changes. See Docker hosting for how that works.
A long-running process answers requests. That is all it does on its own. It does not run a queue worker or keep a session alive past a restart. It does not hold an uploaded file or add capacity to itself. Background jobs owns the first, Logins the second, Files the third, and Scaling and Deploys the fourth. A release restarts the instance, and there is no second copy to move traffic to while it does.
A starting configuration
A production Node API: a dedicated instance sized for the app, plus the iteration add-on.
- Base plan
- Dedicated S
- Iteration — CodeHerder loop
- +$25/mo
- Estimated total
- $54/mo
Node.js questions
The questions this stack raises on its own. General hosting questions live on the homepage.
01Do you support TypeScript?
Yes. The build step compiles it before the process starts, and the compiled output is what runs.
02What if the app needs a database?
Attach a managed Postgres tier at any time. It backs up every night with the app. Dedicated M covers the extra load.
03Can the process run a queue or a scheduled job?
A queue worker or a cron job runs as its own process on the same instance. See Background jobs for how the clock and failure handling work.
04Do sessions survive a deploy?
Not if they live in the process’s own memory, because a deploy restarts it. See Logins for what that means for a signed-in user.
05What if we outgrow Dedicated S?
Move up a tier at any time, for more CPU and RAM on the same process. The resize is one short restart, in a window you pick. You do not rebuild anything.
Keep exploring
Ready to start?
Tell us what you're running — one fixed monthly rate, within a business day.