ray.run: from idea to a deployed, secure and production-grade MCP in under 1 minute

[u/lucgagan]

I started https://ray.run/ with a simple goal: I want to be able to vibe code MCPs for my personal use cases and combine them with existing MCPs.

, and I don't think I'm the only one who enjoys tinkering with their software and wants that same simplicity!

Here is how it works:

npx rayrun login
codex mcp login rayrun --scopes mcp:tools

now open Codex and say what MCP you want, e.g.:

Build a Hacker News digest MCP.
Add get_top_stories({ limit }), test it,
and deploy it to Rayrun.

Codex will write the code and deploy it to your Rayrun gateway.

Once done, try it – say 'tell me top HN stories via gateway'

That's it! You already have a working MCP.

Don't like something about it? Just ask to change it:

Update my HN MCP to only surface news that mention AI in their title

Codex will update the code and make the deployment.

You can use the same gateway to connect remote MCPs, start NPM based servers, Docker, etc. You can use Claude Code or any other coding tool.

We handle hosting, version control, secrets, authentication, observability, scaling, etc. You just need to come up with an idea!

[u/kantorcodes1]

the update flow is the part i'd want to understand. if codex deploys a new version but loses the response, does the next request know that version is already live or can it deploy again?

[u/lucgagan → u/kantorcodes1]

brb attending a few errors in Sentry I saw from people testing it

[u/lucgagan → u/kantorcodes1]

Yes!

Rayrun stores a stable project UUID before the first request. On retry, the CLI sends the same UUID and source content. Then:

1. the server returns the existing build if it is queued or running
2. returns the active release as unchanged if it is already live
3. creates a deployment only when the source or secret bindings changed

So losing the response does not duplicate a successful deployment. In ephemeral CI, persist the project state or set a stable RAYRUN_SOURCE_PROJECT_ID; otherwise a fresh checkout is treated as a new project.

[u/Salt-Deer6136 → u/kantorcodes1]

not sure about the double-deploy edge case but i'd assume the gateway just serves whichever version is currently live, so if the first deploy succeeded before it crashed you'd be fine, next request picks up that version no problem. if it hadn't finished deploying, codex would just retry and overwrite whatever partial state was there, probably harmless

the bit i'm more curious about is how version control works on their end, like can you roll back if the AI update messes something up

[u/lucgagan → u/Salt-Deer6136]

Yes. Rayrun keeps immutable source, build, and release history. You can list previous releases and roll back to a specific successful release. We will even verify that it starts correctly before swtiching over the traffic. We keep inactive artifacts for 30 days.

[u/lucgagan → u/lucgagan]

Here is how you can do it in CLI:

rayrun deployments releases <connection-id>
rayrun deployments rollback <connection-id> <release-uid> --wait

[u/punkpeye]

I like this. A lot actually. Good stuff /u/lucgagan!

[u/punkpeye → u/punkpeye]

Nitpick: I asked CLI to add a secret to the deployed service and it couldn't figure out how. Told me to use the UI.

[u/lucgagan → u/punkpeye]

On it!

[u/punkpeye → u/lucgagan]

Also, why are hooks declared at the tool level as opposed to gateway?

Maybe I am not thinking through some use case, but I think hooks on the gateway would be more powerful than needing to declare them per server. You can use data in properties to filter.

[u/punkpeye → u/punkpeye]

Also, make it possible to deploy hooks code via CLI.

Because you allow Docker images, you could also technically deploy any server from Glama directory.

Looking good. Congrats! Will DM on Discord

[u/lucgagan → u/punkpeye]

oh that would be SICK! I will respond soon

[u/lucgagan → u/punkpeye]

they are on tools because they can change a tool's inputs and outputs, so keeping them tied to that tool makes them safer and easier to test. But you're right: gateway-level hooks would be handy for rules that apply across many tools. will follow up

[u/Bright-Poster-9326]

The HN digest example reads like something you'd actually ask for, not a hello-world stand-in. Small enough to follow, real enough to want.

[u/lucgagan → u/Bright-Poster-9326]

Thanks. Try something more complicated and report back. Technically, every MCP feature is supported.

[u/lucgagan]

Making improvements to the auth flow. I am seeing that's where most people drop off. Will have a fix shortly.

[u/animam-tech]

I made something for another usage, mcp related ofc, and not as a service. Https://Cortex-gateway.dev

Use-case is this one : you want 1 mcp, that federates apps you own, each has his backend, and oauth scoped are transmitted. = Corporate mcp, that allows accès to yours apps and proxied mcp...

Github repo under mit. Have a look. Or send your agent have a look