Self-host Noodle Core

Noodle Core is the Apache-2.0 engine, TypeScript authoring SDK, CLI, runtime, and self-host service behind Noodle Seed. You can develop and operate it without a Noodle Seed account or license key.

There are two useful local paths:

1. Author loop: noodle dev runs one app in memory with zero service configuration.
2. Self-host stack: Docker Compose runs the deploy service, PostgreSQL, and durable filesystem assets.

Local author loop

With Node.js 24 or newer:

npx @noodleseed/one@latest init my-app
cd my-app
noodle dev

noodle dev boots the normal runtime on loopback, reloads server.ts on save, and requires no account, database, master key, or OAuth provider. Use it while authoring. Use the Compose stack when you need the real deploy API, persistence, restart recovery, or an endpoint shared by multiple local apps.

Start the self-host stack

You need Docker Compose v2 and Node.js 24 or newer:

git clone https://github.com/NoodleSeed-com/noodle-core.git
cd noodle-core
npx @noodleseed/one@latest service init --profile open-core --compose
docker compose up --build --wait postgres noodle && docker compose run --rm bootstrap

The initializer verifies that the published CLI understands this checkout before it writes anything. It then creates an ignored .self-host/ directory with protected random credentials, a secret-free generated Compose fragment, and the open-core service profile. It never prints secret values.

The Compose line builds both application images from the exact checkout, starts and health-checks PostgreSQL and Noodle, then runs an idempotent CLI bootstrap that creates the local organization. Re-running the same commands preserves secrets and data. Noodle binds only to http://127.0.0.1:8787; PostgreSQL has no host port.

The repository's self-hosting guide owns the deploy walkthrough, generated-file contract, persistence and reset procedures, OAuth configuration, and production-hardening checklist.

What you can do locally

• Author and compile normal TypeScript server.ts applications.
• Deploy to the local organization through the typed API and CLI.
• Serve tools, resources, prompts, Apps artifacts, and both supported MCP protocol eras.
• Persist deployment/configuration state in PostgreSQL and packaged assets in a named filesystem volume.
• Restart the stack without losing active deployments or asset URLs.
• Inspect status and history, change access, and roll back through the normal headless API/CLI paths.
• Use the fixed local administrator for control-plane operations.
• Optionally configure an external OAuth issuer or the portable Google-federated authorization server and bind a distinct owner subject for owner-only MCP access.

The default profile has no end-user identity provider. Use --access public for the first local deployment. The generated administrator token controls deploy and operator APIs; it is deliberately rejected as an MCP end-user bearer token.

What is not included

The self-host stack is not Noodle Seed Cloud and is not a production hosting distribution. It excludes the managed Console, billing, commercial policy modules, WorkOS platform identity, managed KMS/key custody, hosted GitHub builds, cloud/edge asset delivery, managed distribution, and company operations.

It also does not configure TLS, DNS, backups, upgrades, monitoring, high availability, or a support SLA. The filesystem asset adapter is single-host. Before public internet exposure, you own the reverse proxy, TLS, network policy, real PUBLIC_BASE_URL, OAuth boundary, backup/restore drills, upgrade process, and monitoring.

State and secret safety

The named postgres-data and asset-data volumes survive docker compose down. Back them up together with .self-host/.env; the generated encryption key is required to recover persisted secret values.

--force updates only non-secret generated templates. --replace-secrets rotates every generated secret and can make existing encrypted configuration unusable, so reserve it for a clean reset or a planned migration. docker compose down --volumes destroys the local database and packaged assets.

Portability guarantee

Your server.ts remains the developer-owned source of truth. The internal manifest/runtime artifact is data, not the authoring interface. The same source runs through noodle dev, Noodle Seed Cloud, or the self-hosted open-core service without a commercial module dependency.

If you stop using Noodle Seed Cloud, keep server.ts in version control, run Noodle Core yourself, and point your MCP clients at your endpoint. Apache-2.0 covers the projected core; Noodle Seed trademarks remain separate.