Server Generator

Generates a deployment shell that composes one or more apps and includes platform-specific infrastructure configuration (Docker, Vercel, Lambda, or Cloudflare).

Usage

nx g @frontmcp/nx:server production --apps crm,analytics

Options

Option	Type	Default	Description
`name`	`string`	—	Required. The name of the server
`apps`	`string`	—	Required. Comma-separated app names to compose
`directory`	`string`	`servers/<name>`	The directory of the server
`deploymentTarget`	`node` \| `vercel` \| `lambda` \| `cloudflare`	`node`	The deployment target platform
`redis`	`docker` \| `existing` \| `none`	`none`	Redis setup option (node target only)
`skills`	`recommended` \| `minimal` \| `full` \| `none`	`recommended`	Skills bundle to scaffold under `skills/`
`tags`	`string`	—	Comma-separated tags

Generated Files

Node.js (Docker)
Vercel
Lambda
Cloudflare

servers/production/
├── src/main.ts              # Entry point composing apps
├── skills/                  # Skills bundle (unless --skills none)
├── Dockerfile               # Multi-stage Docker build (context: workspace root)
├── Dockerfile.dockerignore  # Ignore file Docker reads for this Dockerfile
├── docker-compose.yml       # Docker Compose (+ Redis if selected)
├── project.json
├── package.json             # Minimal manifest so `frontmcp build` runs in the project root
├── tsconfig.json
└── tsconfig.lib.json

servers/production/
├── src/main.ts
├── skills/                  # Skills bundle (unless --skills none)
├── vercel.json              # Install and build commands (Build Output API)
├── project.json
├── package.json             # Minimal manifest so `frontmcp build` runs in the project root
├── tsconfig.json
└── tsconfig.lib.json

servers/production/
├── src/main.ts
├── skills/                  # Skills bundle (unless --skills none)
├── template.yaml            # AWS SAM template (handler: dist/lambda/handler.cjs)
├── project.json
├── package.json             # Minimal manifest so `frontmcp build` runs in the project root
├── tsconfig.json
└── tsconfig.lib.json

servers/production/
├── src/main.ts
├── skills/                  # Skills bundle (unless --skills none)
├── wrangler.toml            # Cloudflare Workers config
├── project.json
├── package.json             # Minimal manifest so `frontmcp build` runs in the project root
├── tsconfig.json
└── tsconfig.lib.json

Generated Code

The entry point imports and composes all specified apps from their project folders:

src/main.ts

import 'reflect-metadata';
import { FrontMcp } from '@frontmcp/sdk';
import { CrmApp } from '../../../apps/crm/src/crm.app';
import { AnalyticsApp } from '../../../apps/analytics/src/analytics.app';

@FrontMcp({
  info: { name: 'Production Server', version: '0.1.0' },
  apps: [CrmApp, AnalyticsApp],
})
export default class Server {}

Nx Targets

The project is named server-<name>.

Target	Executor	Description
`build`	`@frontmcp/nx:build`	Compile with deployment adapter (`--target <platform>`)
`dev`	`@frontmcp/nx:dev`	Run the composed apps with `frontmcp dev`
`typecheck`	`nx:run-commands`	`tsc --noEmit -p tsconfig.lib.json`
`deploy`	`@frontmcp/nx:deploy`	Deploy to target platform

Build Output

nx build server-<name> runs frontmcp build --target <platform> with --out-dir servers/<name>/dist, and the generated deployment files point at what it writes:

Target	Build writes	Referenced by
`node`	`dist/node/server-<name>.bundle.js`	`Dockerfile`: `CMD ["node", "dist/node/server-<name>.bundle.js"]`
`vercel`	`dist/vercel/handler.cjs` and `.vercel/output/` (Build Output API)	`vercel.json`: `buildCommand` runs `nx build server-<name>` from the workspace root
`lambda`	`dist/lambda/handler.cjs`, exporting `handler`	`template.yaml`: `CodeUri: dist/lambda/`, `Handler: handler.handler`
`cloudflare`	`dist/cloudflare/index.js`	`wrangler.toml`: `main = "dist/cloudflare/index.js"` (the build keeps it in sync)

Node.js (Docker)

The Docker build context is the workspace root, so build the image from there; Docker reads the ignore rules from Dockerfile.dockerignore next to the Dockerfile. The Dockerfile uses your workspace’s package manager: it installs from the lockfile (npm ci, yarn install --immutable or --frozen-lockfile for Yarn 1, pnpm install --frozen-lockfile, bun install --frozen-lockfile, after corepack enable or installing bun), runs nx build, prunes dev dependencies and copies the pruned node_modules into the runtime image. For Yarn Berry it sets YARN_NODE_LINKER=node-modules in the build stage, so a Plug’n’Play workspace still installs a node_modules folder for the image. The image gets Yarn from corepack, which installs Yarn 1 unless the workspace pins a version, so for a Yarn Berry workspace that pins none (no packageManager in the root package.json, no yarnPath in .yarnrc.yml) the generator adds "packageManager": "yarn@<version>" with the Yarn it runs under, or warns you to run yarn set version when it can’t tell which. The image sets FRONTMCP_BIND_ADDRESS=all, because the server binds 127.0.0.1 by default and a published port could not reach it, and has a HEALTHCHECK that asks /health, which the server answers whatever health.healthzPath says. It runs with NODE_ENV=production, so pass MCP_SESSION_SECRET when you start it. Generate the secret once and reuse it on every start and deploy: a new value ends every open session; docker-compose.yml refuses to start without it and publishes Redis (when selected) on loopback only. The image installs from the lock file, which must list the shell’s own package.json: the generator runs your install after it writes the shell. Up to 1.9.2 it did not, so the image stopped at npm ci with Missing: server-<name>@0.0.1 from lock file until you installed; the image had no HEALTHCHECK and the compose file passed no MCP_SESSION_SECRET.

docker build -f servers/production/Dockerfile -t production .
echo "MCP_SESSION_SECRET=$(openssl rand -hex 32)" >> servers/production/.env   # once
docker run -p 3000:3000 --env-file servers/production/.env production
# or
docker compose -f servers/production/docker-compose.yml up --build

Vercel

nx deploy server-<name> builds, then runs vercel deploy --prebuilt --prod in the server folder, so Vercel deploys the .vercel/output tree the build wrote instead of building again. Link the folder to a Vercel project once with vercel link (or vercel pull). For Git-triggered builds on Vercel, set the project’s Root Directory to servers/<name>: vercel.json installs and builds from the workspace root with your package manager (cd ../../ && npm install, cd ../../ && npx nx build server-<name>). Those commands read files outside the Root Directory, so turn on Include source files outside of the Root Directory in the Build Step in the project’s settings (newer Vercel projects enable it by default). The build target lists .vercel/output in its outputs, so an Nx cache hit restores it too.

AWS Lambda

The generator adds @codegenie/serverless-express to the workspace: the generated handler wraps the server with it and frontmcp build --target lambda refuses to run without it. The build bundles it into handler.cjs, so the function needs no layer. template.yaml sets NODE_ENV: production and MCP_SESSION_SECRET from its McpSessionSecret parameter: generate it once (openssl rand -hex 32) and pass the same value on every deploy (sam deploy --parameter-overrides McpSessionSecret=<secret>, or parameter_overrides in samconfig.toml). Up to 1.9.2 it set neither and asked for a layer.

Example

# Node.js server with Docker Redis
nx g @frontmcp/nx:server production --apps crm,analytics --deploymentTarget node --redis docker

# Vercel deployment
nx g @frontmcp/nx:server edge --apps crm --deploymentTarget vercel

# Run, build and deploy
nx dev server-production
nx build server-production
nx deploy server-production

Get Started

Generators

Executors

Usage

Options

Generated Files

Generated Code

Nx Targets

Build Output

Example

​Usage

​Options

​Generated Files

​Generated Code

​Nx Targets

​Build Output

​Example

Usage

Options

Generated Files

Generated Code

Nx Targets

Build Output

Example