Skip to content

Home

Project Ramen

release ci docs PyPI bridge license MCP

Ramen on Glama: score, tools and listing

Ramen is a multizone, highly available MCP server for GCP, AWS and Azure Kubernetes. Your team keeps a git repo of tools, resources and prompts in plain Python. Ramen turns it into a fleet of MCP workers behind a cloud load balancer, with canary deploys, secrets, a role per group, OAuth sign-in for people, and a log line that says who called what. Underneath it is gRPC, JSON-RPC 2.0 and a Rust node. You code in Python.

ramen

The server: console, Rust node, Python runtime, Helm charts and Terraform for GCP, AWS and Azure. Releases are tagged and built by CI.

ramen-mcp-bridge

pip install ramen-mcp-bridge. A stdio MCP server for clients that cannot speak HTTP. Carries a group key or signs you in through the console. On PyPI.

ramen-demo-mcp

The demo group repo every guide deploys: three tools, a resource, a prompt, an env.yaml, golden cases and NeMo rails. Point a group at it and press Deploy.

Get started How it works

Why Ramen

  • One deployment per team, not one server per tool. A worker loads every tool of the group. Thirty tools run on one Deployment per zone with a canary, behind one load balancer.
  • Built on how organizations work. A group is a team. It owns a repo, a bucket, its secrets and its members. People hold a role per group: Group Admin, Viewer, MCP User, or a role you define. Entra ID or Google Workspace groups can decide the roles at sign-in, and what an admin sets by hand stays.
  • Guardrails where the tool runs. Opt a tool into NeMo Guardrails rails, or a policy file of your own, checked in the worker before the call and after the result. A blocked call is a readable tool error; the access log names the rail.
  • Build once, deploy on three clouds. Terraform and Helm for GKE, EKS and AKS, with a publicly trusted certificate on GKE and AKS. The same console, routes and guards on all three.
  • It scales itself. Ramen adds workers under load and removes them when it is quiet, between 1 and a max that group admins set per zone. No cloud autoscaler config, every step in the audit log.
  • Canary by default. Every deploy rolls one canary pod, smoke-tests it, then rolls the stable pods. A failure leaves the old version serving.
  • Clients connect as themselves. A person signs in through the console (a Ramen password, Entra ID or Google) and the client gets a token for one group and zone. Agents and CI use a group key. The group page prints the exact commands; Connect with OAuth has every client.
  • Secrets never show. Values live in Secret Manager, Secrets Manager, Key Vault or the Fernet-encrypted store and reach tool code only as environment variables on deploy.
  • The edge is locked. The cloud edges listen on 443 only, IP rules apply per zone at the node and at the cloud edge, Redis throttles by address and by token, and every console action leaves an audit line.
  • Multizone from day one. Group, environment, zone, worker. The load balancer routes on two headers, so one client config reaches any zone.
  • Rust where it counts. The Rust node owns auth, limits and the transport. Your Python runs in a separate process it can restart at any time.

What is verified. 0.8.0 passed the release suite and the load tests live on GKE, EKS and AKS; what each run covered, and what is tested only: Transport → What is verified. Everything else is in the wiki.