Node, ts-node, tsx, npm start — Which One Should You Use?

A practical guide for TypeScript + Agent API projects

If you’re new to Node.js or TypeScript, tools like node, ts-node, tsx, and npm start can feel confusing very quickly.
The problem is not that they’re complex — it’s that they solve different problems, but are often explained together.

This article gives you:

• A one-sentence conclusion
• A plain-English explanation (no Node.js background assumed)
• A clear recommendation for development vs production
• A ready-to-use project setup

---

One-sentence conclusion (what you should do)

For a TypeScript Agent API project:

• During development → use tsx
• In production (Cloud Run, server, container) → use node dist/server.js

You can safely ignore the other options for now.

---

First, let’s simplify the problem

All these tools answer two separate questions:

Question A

What program actually runs your code?

Question B

Is it running TypeScript (.ts) or JavaScript (.js)?

Once you separate these two, everything becomes straightforward.

---

1. node — the real engine

What it is

• node is the actual runtime
• It executes JavaScript
• It does NOT understand TypeScript

Typical usage

node server.js

When to use it

• Production environments (Cloud Run, VPS, containers)
• Anywhere stability and predictability matter

One thing to remember

Node runs JavaScript, not TypeScript.

If your code is .ts, it must be compiled first.

---

2. ts-node — the older “run TS directly” tool

What it is

• A helper that compiles TypeScript on the fly and then runs it
• Makes it look like Node can run .ts

Usage

ts-node server.ts

Pros

• No manual tsc step
• Looks convenient for beginners

Cons (important)

• Slower startup
• Fragile with modern ESM modules
• Not recommended for production
• Easy to hit edge-case bugs with newer SDKs

Bottom line

Avoid ts-node for new projects and production deployments.

---

3. tsx — the modern TypeScript dev tool (recommended)

What it is

• A modern replacement for ts-node
• Fast startup
• Minimal configuration
• Excellent ESM compatibility

Usage

tsx server.ts

Why it’s ideal for development

• You write TypeScript
• You use modern SDKs (ESM, Agents, etc.)
• You want fewer surprises

Important positioning

tsx is for development, not for production runtime.

---

4. npm start — not a tool, just a shortcut

This is the most misunderstood one.

What npm start really means

It simply runs whatever command is defined in package.json.

Example:

{
  "scripts": {
    "start": "node dist/server.js",
    "dev": "tsx src/server.ts"
  }
}

Then:

npm start

Is exactly the same as:

node dist/server.js

Key takeaway

npm start has no magic — always check what it runs.

---

Comparison table (bookmark this)

Name	Runs TS directly	Purpose	Recommended
node	❌ No	Run compiled JS	✅ Production
ts-node	✅ Yes	Legacy TS dev	❌ Avoid
tsx	✅ Yes	Modern TS dev	✅ Development
npm start	Depends on script	Command alias	✅

---

Recommended setup for your Agent API project

Project structure

project/
├─ src/
│  ├─ server.ts
│  └─ workflow.ts
├─ dist/          ← compiled output
├─ package.json
├─ tsconfig.json

---

Minimal package.json

{
  "type": "module",
  "scripts": {
    "dev": "tsx src/server.ts",
    "build": "tsc",
    "start": "node dist/server.js"
  }
}

---

How you actually use it day-to-day

Local development

npm run dev

Test production build locally

npm run build
npm start

Cloud Run / production

npm run build && npm start

---

The only rule you really need to remember

Write TypeScript → use tsx
Deploy to production → use node
See npm start → check what it runs

---

AI-Augmented Work Systems