Tulipes (tulipesjs): the TypeScript framework for Express 5 that refuses to boot a broken API

Most Node.js APIs find out they are misconfigured from their first request: a STRIPE_API_KEY that was never set, a permission check someone forgot, a route nobody guarded. Tulipes (tulipesjs, published on npm as @tulipes/core) is a TypeScript framework for Express 5 built on the opposite rule. It checks everything that can be checked before the server listens, and when something is wrong it refuses to start, with one report that lists every problem at once.

This article introduces Tulipes from a real session: the published CLI, a scaffolded app, and the same app broken on purpose to capture what the framework actually prints. You will see the twelve-phase boot pipeline, the module layout, typed environment variables, route-level permissions, OpenAPI generation without a database, and the AI agent tools Tulipes serves over MCP. The runnable sandboxes below are small ports of the framework's own source, so you can break things in your browser too.

What is Tulipes (tulipesjs)?

Tulipes is a module-based framework for building HTTP APIs, background workers and scripts on Express 5 in TypeScript. You write features as folders called modules — each holding its own routes, permissions, configuration, translations and jobs — and Tulipes discovers them, sorts them into a load order, validates their contracts and wires them into a running process. Core mounts no middleware and installs no database driver: MongoDB, BullMQ and Socket.IO arrive only when an app declares them as providers.

It is not a toy. The backend of this blog, k13, runs on Tulipes, and the tools this draft was filed through — the k13 MCP server's agent_mcp_* actions — are, in its own description, "the actions its modules declare".

Validate environment variables at startup: three broken, one crash

Here is the first thing to know about Tulipes, captured from a real run. A billing module declares three environment variables; the deployment sets two of them badly and forgets the third:

$ BILLING_TRIAL_DAYS=abc BILLING_WEBHOOK_URL=not-a-url node app.tsTulipesBootError: Boot aborted during "environment" — 3 issue(s):  ✖ [billing] required variable "STRIPE_API_KEY" has no value (Server-side Stripe key)  ✖ [billing] variable "BILLING_TRIAL_DAYS": "abc" is not a number  ✖ [billing] variable "BILLING_WEBHOOK_URL": "not-a-url" is not a valid URL

Nothing was served, and nothing was half-started. The boot stopped in its first phase and named every problem in it, so one deploy fixes all three instead of three deploys discovering them one at a time.

The Twelve-Factor App puts configuration in environment variables, and validating them at start-up is already good practice: t3-env, envalid and hand-written Zod schemas do it, and NestJS's @nestjs/config checks them during bootstrap and reports every failing variable together. Tulipes applies the same idea to the whole application: the module graph, provider requirements, settings, translations, permissions and every route get the same treatment, each in its own phase.

Try the environment phase yourself. This sandbox is a trimmed port of the resolver in @tulipes/core (src/env/coerce.ts): process.env wins over the .envs/.env.<APP_ENV> file, which wins over the declared default, and every value is coerced to its declared type.

// ▶ Press Run. The boot refuses and lists every problem at once.
//
// Try this, one step at a time:
//   1. Set BILLING_TRIAL_DAYS to "7" below and run again: one problem fewer.
//   2. Add STRIPE_API_KEY: "sk_test_123" to processEnv, use a real https URL
//      and set BILLING_SANDBOX to "true".
//   3. Once it boots, look at the last line: JSON.stringify prints {}
//      because Tulipes makes environment values non-enumerable.

import { contract } from "./contract.mjs";
import { resolveEnv } from "./resolve.mjs";

// What the container injects. It wins over the file.
const processEnv = {
  BILLING_TRIAL_DAYS: "abc",
  BILLING_WEBHOOK_URL: "not-a-url",
};

// What .envs/.env.development holds.
const envFile = {
  PORT: "3000",
  BILLING_SANDBOX: "maybe",
};

try {
  const config = resolveEnv(contract, processEnv, envFile);
  console.log("booted. config.billing.trialDays =", config.billing.trialDays);
  console.log("JSON.stringify(config.billing) =", JSON.stringify(config.billing));
} catch (error) {
  console.error(error.message);
  console.error("\nOne crash, every problem. Fix the values above and run again.");
}

The Tulipes boot pipeline, phase by phase

A Tulipes process boots through twelve phases in a fixed order. Each phase either hands a clean result to the next or stops the process with its own aggregate report, so a later phase never runs on top of an earlier mistake. The same path serves the web server, the queue worker and one-off scripts; only phase 11 differs.

Now play with it. Pick a process mode, switch on one or more faults and press Boot: like the real framework, the simulator stops at the first phase that fails and lists every fault inside that phase, while faults in later phases stay hidden. Every message it shows was printed by @tulipes/core 0.13.0 when the scaffolded app was broken in that exact way.

<!doctype html><html lang="en"><head>  <meta charset="utf-8">  <meta name="viewport" content="width=device-width, initial-scale=1">  <title>Tulipes boot simulator</title>  <link rel="stylesheet" href="style.css"></head><body>  <main class="sim">    <header class="intro">      <p class="eyebrow">Boot simulator</p>      <h1>Break the app, then boot it</h1>      <ol class="how">        <li><b>1</b> Pick how the process runs</li>        <li><b>2</b> Switch on one or more faults</li>        <li><b>3</b> Press <kbd>Boot</kbd> and watch where it stops</li>      </ol>    </header>     <section class="controls" aria-label="Simulator settings">      <div class="group">        <h2>Process mode</h2>        <div class="seg" role="radiogroup" aria-label="Process mode">          <label><input type="radio" name="mode" value="backend" checked><span>backend<small>HTTP API</small></span></label>          <label><input type="radio" name="mode" value="worker"><span>worker<small>queue jobs</small></span></label>          <label><input type="radio" name="mode" value="script"><span>script<small>one-off task</small></span></label>        </div>      </div>       <div class="group">        <div class="row"><h2>Faults</h2><button id="clear" type="button" class="link">Clear</button></div>        <p class="hint">Each one is a real mistake. Turn on several: the boot reports every fault in the phase that fails.</p>        <div id="faults" class="faults"></div>      </div>       <button id="boot" type="button" class="boot">Boot <span id="cmd">node app.ts</span></button>    </section>     <section class="run" aria-label="Result">      <div class="card">        <div class="row"><h2>Boot phases</h2><span class="legend"><i class="ok"></i>passed <i class="bad"></i>refused <i class="skip"></i>never ran</span></div>        <ol id="phases" class="phases"></ol>      </div>      <div class="term">        <div class="bar"><span></span><span></span><span></span><em id="status">ready</em></div>        <pre id="out" aria-live="polite"><span class="dim">Press Boot to start. Every line here was printed by @tulipes/core 0.13.0.</span></pre>      </div>    </section>  </main>  <script src="app.js"></script></body></html>

Quick start: create an Express 5 API with tulipes init

Every command and output below is from a clean run of the published packages on 17 October 2026, Node 24.22.0, Linux. Your timings will differ.

1. 1

   Install the CLI

   The CLI needs Node.js 24. Generated apps use pnpm, pinned through packageManager.

   npmpnpmbun

   npm install -g @tulipes/cli

2. 2

   Scaffold an app

   $ tulipes init my-api  create app.ts  create config/app.config.ts  create modules/core/package.json  create modules/hello/routes/web.hello.routes.ts  …  create AGENTS.md  create CLAUDE.md  create .claude/skills/tulipes-endpoint/SKILL.md  …Project "my-api" is ready.No MongoDB or Redis required. Health: http://localhost:3000/health

   The default preset is minimal: a core and a security module (sys tier), a hello module and an agent module, with tests. It took under half a second here. --preset production copies the full reference application instead: JWT auth with refresh rotation, users, settings, MongoDB, BullMQ, Socket.IO, PM2 and nginx templates.

   • my-api/
     • app.tsboot({ mode: "backend" })
     • mcp.tsserves the agent tools over MCP
     • package.json
     • pnpm-workspace.yaml
     • tsconfig.json
     • vitest.config.ts
     • AGENTS.mdconventions for coding agents
     • CLAUDE.md
     • .claude/
       • skills/14 task-scoped skills: endpoint, env variable, model, queue…
     • config/
       • app.config.tsapp name, API prefix, port, time zone
       • mcp.config.ts
     • modules/
       • core/sys tier, priority 0: the roles and the PORT variable
         • package.json
         • module.acl.ts
       • security/sys tier, priority 10: helmet and a 100 kB body limit
         • package.json
         • routes/
           • security.routes.ts
       • hello/
         • package.json
         • module.acl.ts
         • i18n/
           • en.json
         • routes/
           • web.hello.routes.ts
           • web.hello.health.routes.ts
         • agent/
           • hello.agent.ts
       • agent/serves the agent tool manifest over HTTP
         • package.json
         • module.acl.ts
         • routes/
           • web.agent.routes.ts
     • tests/
       • app.test.tsboots the app once and checks spec parity

3. 3

   Install, generate types, check the environment

   $ cd my-api && pnpm installDone in 8.2s using pnpm v10.28.0$ pnpm syncwrote types/tulipes.d.tswrote .env.example$ pnpm checkAPP_ENV=development — 1 variable(s) resolved:  ✔ config.core.port ← PORT=3000

   tulipes sync generates types from your modules; tulipes env:check resolves every variable without booting, which makes it a cheap CI gate.

4. 4

   Run the tests

   $ pnpm test Test Files  1 passed (1)      Tests  4 passed (4)   Duration  756ms

   One of the four generated tests boots the app twice — once for real, once in inspection mode — and asserts that both produce the same OpenAPI document.

5. 5

   Start it and call it

   $ pnpm dev  ▲ my-api  development · backend mode  ➜  Server      http://localhost:3000  ● listening  ➜  Models      no provider declared  ➜  Queues      no provider declared  ➜  Sockets     no provider declared  ➜  Settings    no module declares settings  ➜  Modules     4 (core*, security*, hello, agent)  ·  * sys tier  ➜  Locales     en  ·  1 translated module(s)  ➜  Time zone   UTC  ·  requests may ask for any zone  ·  process  ➜  Roles       1 (guest)  ➜  Runtime     Node v24.22.0  ·  PID 785  ·  ready in 116ms

   $ curl -s localhost:3000/api/v1/hello{"success":true,"data":{"message":"Hello"},"errors":[],"meta":{}}$ curl -s localhost:3000/nope{"success":false,"data":null,"errors":[{"field":null,"message":"no route for GET /nope","code":"ROUTE_NOT_FOUND"}],"meta":{}}

npm install -g @tulipes/cli
tulipes init my-api --minimal
cd my-api
pnpm install
pnpm dev

One folder per feature: a modular Express app structure

A module is a workspace package under modules/. Every file is optional except package.json, and each file's role comes from its name, so there is no registration list to keep in step. Delete the folder and the feature is gone.

That is the full set from the @tulipes/core README. tulipes new module billing generates only the files your declared providers allow, and every one except package.json can be deleted.

Load order comes from three keys in package.json: tier (sys before app), then priority, then a topological sort on dependsOn. Sys modules load first, which is how the security module's helmet and body-size limit end up at the head of every request without core mounting anything itself.

{  "name": "@my-api/billing",  "tulipes": { "tier": "app", "priority": 100, "dependsOn": ["core"] },  "dependencies": { "@tulipes/core": "^0.13.0", "@my-api/core": "workspace:*" }}

This sandbox is a port of sortModules() from @tulipes/core (src/modules/graph.ts). Give hello a dependency on billing and you get exactly the line the real boot printed: dependency cycle: billing → hello → billing.

// ▶ Press Run to see the order Tulipes loads these modules in.
//
// Try this in modules.mjs:
//   1. Give "hello" dependsOn: ["billing"]   → a dependency cycle
//   2. Give "security" dependsOn: ["billing"] → a sys module may not depend on an app module
//   3. Change a priority and run again: the tier (sys before app) always wins

import { modules } from "./modules.mjs";
import { sortModules } from "./sort.mjs";

const { order, issues } = sortModules(modules);

if (issues.length) {
  console.error(`Boot aborted during "module graph" — ${issues.length} issue(s):`);
  for (const issue of issues) console.error(`  ✖ ${issue}`);
} else {
  console.log("Load order (routes mount, ACLs merge and bootstraps run in this order):\n");
  order.forEach((m, i) =>
    console.log(`  ${String(i + 1).padStart(2)}. ${m.name.padEnd(9)} ${m.tier}  priority ${m.priority}`),
  );
  console.log("\nShutdown runs bootstrap cleanups in the reverse of this order.");
}

Typed environment variables, declared per module

A module declares what it needs from the deployment in plain JSON, so tooling can read the contract without running the module's code:

{  "tulipes": {    "env": {      "stripeApiKey": { "key": "STRIPE_API_KEY", "type": "secret", "group": "billing", "required": true, "description": "Server-side Stripe key" },      "trialDays":    { "key": "BILLING_TRIAL_DAYS", "type": "number", "group": "billing", "default": 14, "description": "Free trial length" },      "webhookUrl":   { "key": "BILLING_WEBHOOK_URL", "type": "url", "group": "billing", "required": true, "description": "Where Stripe posts events" }    }  }}

pnpm sync turns that into types and a documented .env.example. A misspelt name no longer compiles:

declare module "@tulipes/core/config" {  interface EnvValues {    "billing": {      /** STRIPE_API_KEY — Server-side Stripe key */      readonly stripeApiKey: string;      /** BILLING_TRIAL_DAYS — Free trial length */      readonly trialDays: number;      /** BILLING_WEBHOOK_URL — Where Stripe posts events */      readonly webhookUrl: string;    };  }}

# ━━━ billing ━━━# Server-side Stripe key (secret, REQUIRED) → config.billing.stripeApiKeySTRIPE_API_KEY=# Free trial length (number) → config.billing.trialDaysBILLING_TRIAL_DAYS=14# Where Stripe posts events (url, REQUIRED) → config.billing.webhookUrlBILLING_WEBHOOK_URL=

Code reads the values as ctx.config.billing.trialDays, beside the module's settings. The detail that matters for security is that they are read-only and non-enumerable. A script booted against the app above printed this:

const app = await boot({ rootDir: import.meta.dirname, mode: "script" });console.log(app.ctx.config.billing.trialDays);           // 14console.log(Object.keys(app.ctx.config.billing));        // []console.log(JSON.stringify(app.ctx.config.billing));     // {}await app.shutdown();

So res.json(ctx.config.billing), a spread into a log line, or a settings export cannot leak STRIPE_API_KEY. tulipes env:check masks secrets too: ✔ config.billing.stripeApiKey ← STRIPE_API_KEY=•••. Tulipes also reads APP_ENV, deliberately not NODE_ENV, because bundlers and libraries overload NODE_ENV as an optimisation flag.

{
  "tulipes": {
    "env": {
      "trialDays": {
        "key": "BILLING_TRIAL_DAYS",
        "type": "number",
        "group": "billing",
        "default": 14,
        "description": "Free trial length"
      }
    }
  }
}

Route-level permissions: every route declares its RAI, or the app does not start

In Tulipes a route is declared with rai() — a Resource Access Identifier. The id has the shape module:scope:resource[:extra], such as billing:web:list or users:bo:detail:delete, and it does three jobs at once: it names the endpoint, it is the ACL permission that gates it, and it binds req.t to the module's translations. Add Zod schemas and the same declaration validates the request and documents it.

import { Router } from "express";import { z } from "zod/v4";import type { BackendCtx } from "@tulipes/core/boot"; export default function billingRoutes(ctx: BackendCtx): Router {  const router = Router();  router.get(    "/billing/invoices",    ctx.rai({      id: "billing:web:invoices",      name: "List invoices",      returns: z.object({ invoices: z.array(z.object({ id: z.string(), total: z.number() })) }),    }),    (req, res) => {      // req.auth.user is who is calling; rai() has already checked their role.      res.respond({ data: { invoices: [{ id: "inv_1", total: 4200 }] } });    },  );  return router;}

Forget the declaration and the boot fails after every route is mounted and scanned, rather than leaving an open endpoint in production:

TulipesBootError: Boot aborted during "routes" — 1 issue(s):  ✖ POST /api/v1/billing/refund has no rai() declaration

Grants live in each module's module.acl.ts. Roles are defined once; a grant is an id, *, or a prefix ending in :*. A grant to a role nobody defined, or the same grant twice, is a boot failure:

TulipesBootError: Boot aborted during "acl" — 2 issue(s):  ✖ [billing] allow() on unknown role "user" — roles must be defined first (defineRole)  ✖ [billing] "guest" already granted "billing:web:list" by module "billing" — duplicate grant

Access is denied by default. In the scaffolded app, GET /api/v1/billing was declared but granted to no role; tulipes routes listed it as reachable by — nobody, and a guest request got 401 with the code UNAUTHENTICATED. Core reads only req.auth, so swapping JWT for sessions or mTLS changes the auth module and nothing else.

// ▶ Press Run: each line says whether a role may call an endpoint.
//
// Try this:
//   1. Change "billing:web:*" to "billing:web:invoices" → the user keeps exactly one permission
//   2. Uncomment the "owner" line below → boot refused: that role was never defined
//   3. Grant "admin" the wildcard "*" → every admin check says allow

import { createAcl, grantsCovering } from "./acl.mjs";

const acl = createAcl();

// modules/core/module.acl.ts — roles are defined once.
acl.defineRole("guest");
acl.defineRole("user");
acl.defineRole("admin");

// Each feature module attaches grants on its own ids.
acl.allow("guest", "hello:web:read");
acl.allow("user", "billing:web:*");
acl.allow("admin", "billing:bo:detail:*", "users:*");
// acl.allow("owner", "billing:*");        // uncomment: unknown role, boot refused

if (acl.issues.length) {
  console.error(`Boot aborted during "acl" — ${acl.issues.length} issue(s):`);
  for (const issue of acl.issues) console.error(`  ✖ ${issue}`);
} else {
  const checks = [
    ["guest", "billing:web:invoices"],
    ["user", "billing:web:invoices"],
    ["user", "billing:bo:detail"],
    ["admin", "billing:bo:detail"],
    ["admin", "billing:bo:detail:refund"],
    ["admin", "billing:bo:list"],
    ["intern", "hello:web:read"],
  ];
  for (const [role, id] of checks) {
    console.log(`${acl.can(role, id) ? "allow" : "deny "}  ${role.padEnd(6)} ${id}`);
  }
  console.log("\nA request for billing:bo:detail:refund is checked against:");
  console.log("  " + grantsCovering("billing:bo:detail:refund").join("  ›  "));
}

One codebase for the API server, the queue worker and scripts

The same app boots as a backend (HTTP), a worker (queue consumers) or a script. All three run phases 1 to 10 identically, so a maintenance script sees exactly the configuration, models and ACL the server has, not an approximation of it.

import { boot } from "@tulipes/core/boot"; await boot({ rootDir: import.meta.dirname, mode: "backend" });

import { boot } from "@tulipes/core/boot"; // Refused when no module registers queue work:// "worker mode started with zero processors — no module registered queue work"await boot({ rootDir: import.meta.dirname, mode: "worker" });

import { boot } from "@tulipes/core/boot"; const app = await boot({ rootDir: import.meta.dirname, mode: "script" });try {  // same ctx.config, ctx.models and ctx.acl as a request handler} finally {  await app.shutdown();}

A worker with nothing to consume is treated as a misconfigured deployment rather than a process that idles quietly — the minimal app above has no queues provider, and starting it as a worker failed immediately with the message in the comment.

Generate OpenAPI 3.1 and Postman from Express routes, without a database

tulipes routes, tulipes roles and tulipes spec run an inspection boot: the normal pipeline with nothing acquired. Environment values are optional, providers are stubs that throw if used, bootstrap and listen() are skipped. No .env, secret or running service is needed, so CI can document an API it cannot start.

$ pnpm tulipes routes4 endpoint(s)POST  agent:web:invoke  /api/v1/agent/tools/:name  agent  guestGET   agent:web:tools   /api/v1/agent/tools        agent  guestGET   hello:web:health  /health                    hello  guestGET   hello:web:read    /api/v1/hello              hello  guest$ pnpm spec  wrote docs/openapi.json  wrote docs/collection.json4 endpoint(s) across 2 folder(s): agent, hello

The OpenAPI 3.1 document carries the permission and the roles that reach each operation (x-tulipes-permission, x-tulipes-roles), alongside the Postman collection. Because inspection runs the same routers through the same scan as a serving process, the generated test that compares both documents passes by construction — and fails the moment a routes file starts reading a database while building its router.

Expose AI agent tools over MCP (Model Context Protocol)

Tulipes does not turn routes into agent tools. A module lists what it offers to agents in agent/*.agent.ts: each action has an id that is also an ACL permission, a description written for a model, a Zod input schema and a handler. Calls go through the same gate as a route — ACL on the id, then the schema, then the handler.

import { action, defineAgent } from "@tulipes/core/agent";import { z } from "zod/v4"; export default defineAgent({  summary: "Says hello.",  actions: [    action({      id: "hello:web:greet",      description: "A greeting, optionally addressed to someone",      readOnly: true,      input: z.object({ name: z.string().optional().describe("Who to greet") }),      handler: (ctx, { name }) => ({ message: name ? `Hello, ${name}` : "Hello" }),    }),  ],});

$ curl -s localhost:3000/api/v1/agent/tools{"success":true,"data":{"app":{"name":"my-api"},"authorization":"acl", "tools":[{"name":"hello_web_greet","module":"hello","permission":"hello:web:greet",   "description":"A greeting, optionally addressed to someone",   "input_schema":{"type":"object","properties":{"name":{"description":"Who to greet","type":"string"}},   "additionalProperties":false},"read_only":true}]},"errors":[],"meta":{}}$ curl -s -X POST -H 'content-type: application/json' -d '{"name":"world"}' localhost:3000/api/v1/agent/tools/hello_web_greet{"success":true,"data":{"message":"Hello, world"},"errors":[],"meta":{}}

Generated apps include mcp.ts and @tulipes/mcp, which serves the same manifest to Claude Code or any client of the Model Context Protocol. It is the mechanism behind the k13 tools mentioned at the top: an agent sees exactly the actions its role may call, and nothing derived from the HTTP surface by accident. Every generated app also ships an AGENTS.md, a CLAUDE.md and task-scoped skills under .claude/skills/, so a coding agent learns the conventions — declare variables instead of reading process.env, never call mongoose.model() — before it writes a line.

Graceful shutdown in Node.js, in the right order

Express's own graceful shutdown guide asks an app to stop accepting requests on SIGTERM, finish the ones in flight, release its resources and exit. Tulipes does that for every module. Work stops first and resources close last, all under one shared deadline — 10 seconds unless boot() is given shutdownTimeoutMs (src/boot/boot.ts):

1. ctx.signal aborts, so long-running work such as an SSE stream or a poller ends while everything it needs is still alive.
2. The HTTP server closes while queue providers drain at the same time; models stay connected.
3. Bootstrap cleanups run in reverse load order. A failed or stuck cleanup is reported without blocking the ones after it.
4. Providers are disposed in the reverse order they were acquired, the time zone is restored, and the process exits 0.

import type { RuntimeCtx } from "@tulipes/core/boot"; export default async function heartbeat(ctx: RuntimeCtx) {  const timer = setInterval(() => console.log("billing is alive"), 30_000);  ctx.signal.addEventListener("abort", () => clearInterval(timer)); // shutdown began  return () => console.log("billing cleanup ran");                  // after traffic drains}

Tulipes vs NestJS vs plain Express

All three can build the same API. They differ in where structure comes from and when mistakes surface. NestJS organises code with decorators and a dependency-injection container and runs on Express by default; plain Express leaves every structural choice to you. Tulipes keeps plain Express handlers and gets its structure from file conventions and JSON contracts that are checked at boot.

Choose Tulipes if you want Express's handler model with a framework that refuses broken configurations, and you are comfortable on a young 0.x line. Choose NestJS if you want a large ecosystem and DI today. Choose plain Express for a small service where a framework is more weight than help.

What Tulipes does not promise yet

The project is unusually frank about this, and you should be too before adopting it. From its own support policy and this test run:

• Node.js 24 only. The CLI refuses other lines through engines; CI covers Node 24 on Ubuntu, and macOS for the minimal starter. Windows is not claimed. Node 24 is an LTS line supported until the end of April 2028 (Node.js releases).
• No published production evidence. The support policy states there is no load, backup-restore or multi-replica evidence yet, and no independent security review.
• Three providers. Models mean Mongoose and MongoDB, queues mean BullMQ and Redis, sockets mean Socket.IO. The provider seam is designed for others, but none exist yet.
• Private source repository. The packages are MIT-licensed and each npm tarball ships the compiled JavaScript with type declarations, but the Git repository, issues and CI need access.
• Pre-1.0 versioning. A 0.x minor may change public contracts, with a migration guide and a tulipes migrate command — 0.11 and 0.12 both shipped one.

For scale: installing @tulipes/core 0.13.0 alone with npm 10 on Node 24 added 71 packages and 12 MB to node_modules in this run. The full minimal app, with TypeScript, Vitest and the CLI as dev dependencies, came to 131 MB.

Where to start

Run tulipes init, then break something on purpose — unset a variable, forget a rai(), grant a role that does not exist — and read what the boot tells you. That report is the framework's whole argument: problems are cheapest before the first request, and cheapest of all when you see every one of them at once.

Sources and further reading

• @tulipes/core on npm, with @tulipes/cli, @tulipes/spec and @tulipes/mcp
• Express: Introducing Express v5, Upgrade to Express v5, Health checks and graceful shutdown
• Configuration: The Twelve-Factor App — Config, NestJS configuration
• Zod documentation and the OpenAPI Specification 3.1.0
• Agents: What is the Model Context Protocol? and AGENTS.md
• Node.js release schedule