No Crd

@nogoo9/no-crd

[nogoo9 logo]

[no-crd Dashboard]

Agent-Driven, On-Demand Pod Orchestration in Kubernetes — Without Custom Resource Definitions.

[npm version] [npm downloads] [Documentation] [License] [Coverage Status] [OpenSSF Scorecard] [Semgrep]

[Model Context Protocol] [Built with Antigravity] [Powered by Gemini]

[Bun] [Deno] [Node.js]

@nogoo9/no-crd is a lightweight, cross-runtime Model Context Protocol (MCP) server that empowers AI agents and APIs to dynamically spawn, route to, and manage ephemeral containerized sandboxes on standard Kubernetes (k8s/k3s) clusters — without requiring Custom Resource Definitions (CRDs), cluster-level operators, or elevated RBAC permissions.

It provides JupyterHub-like dynamic pod lifecycle management but is completely agnostic to actual workloads and supports multi-runtime execution under Bun, Deno, and Node.js.

📚 For detailed guides, API reference, and configuration options, visit the public Documentation Website or access the built-in documentation served directly at /docs/ (e.g. http://localhost:3000/docs/) when running the server.

🗺️ Choose Your Path

To get started with @nogoo9/no-crd, select the track that matches your goals:

• Track A: AI Agent & MCP Users $\rightarrow$ MCP Client Setup Guide
  • Best for: Connecting no-crd to Cursor, Claude Desktop, Cline, or Roo Code to let your agent manage pods.
• Track B: Platform & Service Deployers $\rightarrow$ SSO & Routing Deployment Guide
  • Best for: Deploying a multi-tenant sandbox service in your Kubernetes cluster with Keycloak OIDC, stateless cookies, and reverse proxy routing.
• Track C: SDK & Code Contributors $\rightarrow$ SDK & Contributor Guide
  • Best for: Programmatically controlling pods via the TypeScript SDK or contributing to the core runtime codebase.

🚀 Key Features

• No CRDs Required: Runs directly against core Kubernetes resources (Pods, ConfigMaps, ServiceAccounts). Highly portable, secure, and compatible with restricted/managed environments (EKS, GKE, K3s).
• Agent Sandbox Spawner: Specialized spawner tools that automate workspace provisioning with context validation, init containers, IAM roles, pre-stop hooks, and lifecycle sync.
• ConfigMap-Based Templates: Store, version, and load reusable pod templates stored as standard Kubernetes ConfigMaps.
• Local Filesystem Templates: Bake YAML/JSON pod templates into Docker images or mount them from host paths — with built-in defaults shipped in the package.
• Isomorphic Multi-Runtime SDK: Imports seamlessly as a composable programmatic SDK or MCP server running under Node.js, Bun, or Deno.
• Workspace Routing Proxy (Experimental): Built-in reverse proxy routing that dynamically pipes traffic to running container IPs with secure user token ownership verification, path-scoped session cookies (nocr_token and nocr_sess), and automatic HMAC-signed session management for short-lived token resilience.
• Experimental JWT Authentication: Built-in OAuth token validation engine supporting HS256, RS256, ES256, JWKS endpoints, and OAuth 2.0 Token Introspection (RFC 7662).
• Embedded Web UI App: Exposes an interactive web-based Pod Manager interface featuring a light/dark theme toggle, client-side PKCE OIDC login with proactive silent token refresh, and workspace file preview rendering (supporting HTML sandboxed iframes and custom Markdown rendering).

⚡ Quick Start

Run Standalone via NPX (No Installation)

# Option 1: Start HTTP/SSE server on port 3000npx @nogoo9/no-crd --transport http --port 3000
# Option 2: Run over standard input/output (stdio) for local IDE agentsnpx @nogoo9/no-crd --transport stdio --mode cluster

Install Globally

npm install -g @nogoo9/no-crdnocrd9 --transport stdio --mode cluster

Run via Docker

docker run -d -p 3000:3000 \  -v "$HOME/.kube/config:/app/.kube/config:ro" \  -e KUBECONFIG=/app/.kube/config \  ghcr.io/nogoo9/no-crd:latest

⚙️ Configuration & Environment Variables

The server and command-line utility are configurable using CLI options or environment variables. Below is the quick reference table of all settings:

🔌 Server Configuration

🔒 TLS Configuration

🌐 CORS Configuration

☸️ Kubernetes Configuration

🔑 Authentication Configuration

🖥️ UI & Themes Configuration

☸️ Kubernetes Setup & RBAC Permissions

For the @nogoo9/no-crd MCP server to interact with Kubernetes, it must run with appropriate RBAC permissions. Depending on your configuration, you can deploy it with Cluster-Wide (ClusterRole) access or Namespace-Scoped (Role) access.

Tool-to-Permission Mapping

Below is the mapping showing which Kubernetes API resources and verbs each MCP tool requires. The server dynamically checks these permissions at startup (via SelfSubjectAccessReview) and only registers tools that the active identity is authorized to use.

Resource: configmaps

Resource: events

Resource: namespaces

Resource: pods

Resource: pods/log

1. Cluster-Wide Mode (MODE=cluster)

Use this mode if you want the MCP server to manage sandboxes across any namespace in the cluster.

Create a ClusterRole and ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: nogoo-mcprules:  - apiGroups: [""]    resources: ["pods"]    verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]  - apiGroups: [""]    resources: ["pods/log"]    verbs: ["get"]  - apiGroups: [""]    resources: ["namespaces"]    verbs: ["get", "list"]  - apiGroups: [""]    resources: ["configmaps"]    verbs: ["get", "list", "create", "update", "patch", "delete"]  - apiGroups: [""]    resources: ["serviceaccounts"]    verbs: ["get", "list", "create", "update", "patch", "delete"]---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: nogoo-mcproleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: nogoo-mcpsubjects:  - kind: ServiceAccount    name: nogoo-mcp    namespace: nogoo9 # Change to the namespace where your MCP server runs

2. Namespace-Scoped Mode (MODE=namespaced)

Use this mode if the MCP server should be restricted to a single namespace (e.g. nogoo9). In this mode, no cluster-level or administrative permissions are needed.

Create a Role and RoleBinding in the target namespace:

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: nogoo-mcp  namespace: nogoo9rules:  - apiGroups: [""]    resources: ["pods"]    verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]  - apiGroups: [""]    resources: ["pods/log"]    verbs: ["get"]  - apiGroups: [""]    resources: ["configmaps"]    verbs: ["get", "list", "create", "update", "patch", "delete"]  - apiGroups: [""]    resources: ["serviceaccounts"]    verbs: ["get", "list", "create", "update", "patch", "delete"]---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: nogoo-mcp  namespace: nogoo9roleRef:  apiGroup: rbac.authorization.k8s.io  kind: Role  name: nogoo-mcpsubjects:  - kind: ServiceAccount    name: nogoo-mcp    namespace: nogoo9

(Note: In namespace-scoped mode, the list_namespaces tool will only return the target namespace, and namespace parameter inputs to all tools will default to the target namespace.)

📑 Workspace Templates & Spawner Annotations

Templates in @nogoo9/no-crd can be loaded from three sources (highest to lowest priority):

1. Kubernetes ConfigMaps — labeled with nogoo9/pod-template: "true" (original mechanism)
2. Custom local directory — set via TEMPLATES_DIR env var (YAML or JSON files)
3. Built-in templates — shipped with the npm package (disable with BUILTIN_TEMPLATES=false)

See ADR-001 for format details.

1. How to Define a Template

To register a template with the spawner, create a ConfigMap meeting the following requirements:

1. Discovery Label: Must be labeled with nogoo9/pod-template: "true".
2. Spec Key: The data block must contain a key named spec whose value is a JSON string conforming to the PodSpecSchema (e.g. containers, volumes, restartPolicy).
3. Behavior Customization: Set annotations on the ConfigMap metadata to configure advanced spawner integrations (like IAM role binding, init containers, and pre-stop lifecycle hooks).

Example Template Definition:

apiVersion: v1kind: ConfigMapmetadata:  name: node-workspace-template  namespace: nogoo9  labels:    nogoo9/pod-template: "true"  annotations:    nogoo9/description: "A standard Node.js development sandbox with S3 storage sync"    nogoo9/tag: "node-20"    nogoo9/required-context: "PROJECT_NAME,REPO_URL"    nogoo9/iam-role-arn: "arn:aws:iam::123456789012:role/workspace-s3-access"    nogoo9/init-image: "alpine/git"    nogoo9/init-command: "git clone $REPO_URL /workspace/$PROJECT_NAME"    nogoo9/pre-stop-command: "aws s3 sync /workspace s3://my-workspace-backups/$PROJECT_NAME"    nogoo9/default-grace-period: "120"data:  spec: |    {      "containers": [        {          "name": "workspace",          "image": "node:20-alpine",          "command": ["sleep", "infinity"],          "volumeMounts": [            {              "name": "workspace-storage",              "mountPath": "/workspace"            }          ]        }      ],      "volumes": [        {          "name": "workspace-storage",          "emptyDir": {}        }      ]    }

2. Supported Spawner Annotations

The spawner inspects ConfigMap metadata annotations (and custom inline annotations passed during spawn_workspace) to customize the workspace lifecycle:

📦 Programmatic SDK & API Proxy Services

@nogoo9/no-crd provides a complete programmatic SDK and dynamic cluster routing proxy to allow developers to build custom pod orchestrators and route workspace traffic natively.

1. Composable Programmatic SDK

You can import @nogoo9/no-crd in your Bun, Deno, or Node.js codebase to control pod sandboxes and templates programmatically, bypassing the MCP HTTP server.

import { KubeConfig } from "@kubernetes/client-node";import {   initK8sContext,   spawnWorkspace,   stopWorkspace,   listWorkspaces } from "@nogoo9/no-crd";
// 1. Initialize Kubernetes API Context (optionally pass custom configuration)const kc = new KubeConfig();kc.loadFromDefault();const ctx = initK8sContext(kc);
// 2. Spawn a workspace sandbox from a templateconst spawnResult = await spawnWorkspace(ctx, {  id: "agent-session-42",  templateRef: "nogoo9/default-agent-workspace",  context: {    "S3_BUCKET": "my-bucket",    "S3_FOLDER": "session-42"  }});console.log(`Spawned pod: ${spawnResult.podName}`);
// 3. List active workspaces running in the namespaceconst list = await listWorkspaces(ctx, {  namespace: "nogoo9"});console.log(`Active workspaces count: ${list.workspaces.length}`);
// 4. Terminate the workspace sandboxawait stopWorkspace(ctx, {  id: "agent-session-42"});

2. Workspace Routing Proxy (Experimental)

[!WARNING] The workspace routing proxy and JWT authentication engine are experimental and likely to change in the next version.

The server includes a built-in reverse proxy routing service. HTTP requests targeting: http://<mcp-server-host>/route/<workspace-id>/<subpath> are dynamically proxied directly to the running workspace pod's IP address inside the cluster.

If AUTH_ENABLED is true:

• Token Bootstrapping & Path-Scoped Cookies: Since standard browser navigations (links, iframes) cannot transmit custom HTTP headers, the client passes the active JWT via a ?token= query parameter on initial redirect. The proxy validates it and issues a secure, path-scoped cookie (nocr_token), allowing subsequent resource requests (JS, CSS, images, WebSockets) to authenticate seamlessly without URL parameters.
• Direct Access Redirect (SSO): Accessing a workspace URL directly without active credentials redirects you to the main dashboard's login screen. Once logged in, the dashboard automatically routes you back to the target workspace URL with a fresh bootstrap token.
• Resource Ownership Verification: The workspace pod's nogoo9/user-sub label must match the JWT's subject claim, preventing unauthorized access to other users' workspaces.
• Proxy target port: Inside the workspace pod defaults to 3000 or can be overridden via pod annotation nogoo9/workspace-port or the DEFAULT_WORKSPACE_PORT environment variable.
• Multi-Port / Custom API Routing: You can expose and route additional APIs inside the pod (e.g., a web terminal or secondary service) by defining custom annotations in the template (e.g., nogoo9/api.terminal.port: "7681", nogoo9/api.terminal.path: "/terminal"). The proxy will dynamically handle subpath routing and method checks.
• A stateless signed session cookie (nocr_sess) is minted on first successful JWT validation, enabling workspace traffic to survive short-lived token expiry. (Available from v0.4.0) See ADR-002 and ADR-003 for design details.

For a detailed breakdown of the redirection lifecycle, Keycloak configuration, and JWT claims, see the SSO & OIDC Integration Guide.

3. OAuth Resource Discovery (RFC 9728)

Exposes the standardized metadata endpoint GET /.well-known/oauth-protected-resource returning:

• Supported authorization servers.
• Token format specifications.
• Required scopes.

This allows client interfaces (and MCP clients) to automatically discover security requirements and handle dynamic OAuth authentication flows.

4. Embedded Web UI & Dashboard Themes

When the server runs in HTTP/SSE transport mode, the visual React Pod Manager UI Dashboard is served directly at root / (e.g. http://localhost:3000/).

• Dashboard Themes: The UI includes a system/light/dark toggle and supports custom visual themes.
• Three-Source Theme Merge Engine: CSS stylesheets are dynamically scanned and merged from:
  1. Kubernetes ConfigMap (THEMES_CONFIGMAP environment variable).
  2. Custom Local Directory (THEMES_DIR environment variable, defaults to themes/).
  3. Built-In Catalog (pre-baked styles: Dracula, Nord, Stripe, Slack, Vercel, Apple, Superhuman, Notion, and Antigravity).

Duplicate theme IDs are resolved according to priority: ConfigMap > Local Directory > Built-In Catalog. For detailed customization guidelines and CSS templates, see the Dashboard Themes & Branding Guide.

🔌 API Reference (MCP Tools & Resources)

Pod Tools

• list_pods: Retrieve a summary of pods in the namespace. Filters by labelSelector, fieldSelector, and limit.
• get_pod: Fetch full Kubernetes API JSON payload for a target pod name.
• create_pod: Create a custom pod with direct container/volume specifications.
• patch_pod: Apply a Strategic Merge Patch to modify labels, annotations, or container resource limits dynamically.
• delete_pod: Terminate a pod with optional gracePeriodSeconds.
• get_pod_logs: Fetch logs for a container with options like tailLines, sinceSeconds, timestamps, limitBytes, and previous.
• list_namespaces: List all namespaces accessible with current credentials.
• list_registry_images: List catalog images from the configured REGISTRY_URL.

Pod Template Tools

Manage preconfigured pod specifications stored as standard Kubernetes ConfigMaps (labeled nogoo9/pod-template=true).

• list_templates: Show available templates.
• get_template: Get the raw pod template spec.
• create_template: Store a new pod template spec.
• update_template: Update labels, annotations, or specs on an existing template.
• delete_template: Delete a template.
• create_pod_from_template: Spawn a pod using a template, applying container overrides (environment variables, commands, resources) and top-level overrides.

Agent Workspace (Spawner) Tools

Specially designed for AI agents to safely spawn and clean up their own workspace sandboxes.

• list_workspaces: List active agent workspaces (with JWT/owner mapping support).
• spawn_workspace: Spawn a workspace sandbox pod. Features:
  • Context Validation (nogoo9/required-context): Requires the caller to supply critical env variables (e.g. API keys) before spawning.
  • Init Containers (nogoo9/init-image / nogoo9/init-command): Initialize workspace directories/files before main containers start.
  • Pre-Stop Hooks (nogoo9/pre-stop-command): Run custom cleanup commands (e.g., commit/sync code to git or S3) upon termination.
  • IAM Role Mapping (nogoo9/iam-role-arn): Dynamically provisions AWS EKS IAM Role service accounts.
• stop_workspace: Clean up and terminate the workspace pod.

Utilities

• current_namespace: Returns active namespace and access mode.

MCP Resources

• pod-template://{namespace}/{name}: Exposes stored pod templates directly as read-only MCP resources.
• ui://nogoo9/app: Exposes the embedded React/web UI app (if UI_ENABLED=true and built). When the server runs in HTTP/SSE transport mode, the UI is also served directly at / or /ui (e.g. http://localhost:3000/) and automatically falls back to standard HTTP JSON-RPC calls when loaded outside a postMessage-compatible MCP host (such as in a standard browser tab or the MCP Inspector).

🏗️ Architecture

  ┌───────────────────────┐  │   AI Agent / Client   │  └───────────┬───────────┘              │ (Stdio or SSE Transport)              ▼  ┌───────────────────────┐  │      MCP Server       │ <── (Queries ConfigMaps for specs)  └───────────┬───────────┘              │ (Kubernetes API - CoreV1)              ▼  ┌──────────────────────────────────────────┐  │            Kubernetes Cluster            │  │  ┌────────────────────────────────────┐  │  │  │         Target Namespace           │  │  │  │  ┌──────────┐ ┌──────────┐ ┌────┐  │  │  │  │  │ Agent    │ │ Custom   │ │    │  │  │  │  │  │ Sandbox  │ │ Workload │ │... │  │  │  │  │  │ Pod      │ │ Pod      │ │    │  │  │  │  │  └──────────┘ └──────────┘ └────┘  │  │  │  └────────────────────────────────────┘  │  └──────────────────────────────────────────┘

The server interacts directly with the Kubernetes API using @kubernetes/client-node. By using standard Pod and ConfigMap resources, the setup is highly scalable, requires no cluster operator installs, and easily adheres to strict enterprise namespace-level security policies.

🛠️ Development

We use Moon for toolchain management and task running, and Biome for formatting and linting.

Prerequisites

• Bun 1.3.11+
• Node.js 22.14.0+
• Moon 2.1.3+
• k3d (for local Kubernetes cluster)

Setup Environment

# Install dependenciesbun install
# Auto-fix code formatting and linting via Biomebun run format
# Run TypeScript compilation checksbun run typecheck

Running Tests

# Run unit testsmoon run mcp:test
# Run full spawner workspace lifecycle tests (requires local k3d)bun run test:lifecycle

Local Cluster Testing (k3d)

Bootstrap a local k3d Kubernetes cluster complete with a local registry, built-in mock S3, and Traefik:

# Spin up development clustermoon run k3d:bootstrap
# Rebuild, push, and deploy MCP server to the clustermoon run mcp:deploy
# Tear down the clustermoon run k3d:teardown

📄 License

This project is licensed under the Apache License 2.0. See LICENSE for details.