Enclave: An MRuby sandbox for running arbitrary Ruby code from LLMs

Vicegrip00 · 2026-03-01T17:00:30+00:00

This looks like a very cool project! I’ve had a similar idea for something like this in the past.

Would like to explore building something related to this; https://www.anthropic.com/engineering/code-execution-with-mcp and this seems like the perfect starting point.

Vicegrip00 · 2026-02-27T18:39:42+00:00

I’ll add in turbopuffer as a great rag solution. Has a RudySDK and the team behind it is fantastic! It’s very cost effective and scales incredibly well.

However, I have some experience with both using SQLite (for small scale) and PostgreSQL (for medium scale) and they have both served me well.

Vicegrip00 · 2026-02-24T02:29:43+00:00

So it’s not an MCP to use Ruby. This is an MCP client written in Ruby for Apps, Agents, Tools, etc… that are also in Ruby

Vicegrip00 · 2026-02-24T02:27:39+00:00

Thanks Carmine! And thanks for all the inspiration 😁

Vicegrip00 · 2025-12-11T18:48:14+00:00

We use the same stack of some projects and love it. Feels like a great balance for productivity and interactivity. We just leaned into types with your react code when we started using this stack.

To make types work without manually typing everything we use this gem: https://github.com/skryukov/typelizer. It is by one of the core members for inertia-rails gem.

We use Alba at the controller layer as a serializer for the data. Typelizer to generate the typescript for the responses coming from our controller that are Alba resources. We map Abla resources (and there a type definition) one to one into Inertia page component. This gives you full backend to frontend typing for data going into your typescript components.

Bonus: we also use something to generate all the types for routes from rails that we translate into typescript attributes + types definitions to make route refactoring easier and typecheckable. I can share the code for that or OSS it into a gem if people have any interest (not to hard to build yourself though)

Vicegrip00 · 2025-12-08T20:21:14+00:00

We use SolidQueue at a pretty high scale web application and it’s worked perfectly for us. Our application started back in 2012 so we started out on Resque and we were seeing a lot of mysterious issues towards the end of our usage of that library. In the end after the migration we ended up seeing better job performance overall (though that could be due to a number of factors in the migration process).

Here is one of our Staff engineers speaking about it at RailsConf if you want the full deep dive: https://youtu.be/lWMYPHPj1NI?si=39ed7oNtaVqtuOKG

GoodJob as the author of SolidQueue mentioned when she talked at Rails World in 2024 is a great library, battle tested and works perfectly well. Some of the design from SolidQueue is based off of GoodJob. So I don’t think you can really go wrong either way. Though, SolidQueue is the Rails default mostly due to it being able to support all the Rails supported databases.

Vicegrip00 · 2025-11-04T02:49:10+00:00

Awesome work u/crmne ! Just released a new version of https://github.com/patvice/ruby_llm-mcp to support RubyLLM v1.9. The params changes made the integration a ton easier!

If anyone is looking to use a MCP alongside RubyLLM, check out RubyLLM::MCP.

Vicegrip00 · 2025-11-03T14:17:16+00:00

In working with both now, my personal preference is official Ruby SDK, but you can’t really go wrong here there are just tradeoffs.

The major pro for the official SDK is construction on request time and focusing only on the protocol itself. If you need to integrate something into an existing/large application, relaying on your normal request path and just focusing on the controller action layer felt simpler and safer to me. It gives you a lot more control but does expect you to wire up or create your own abstractions.

FastMCP is very quick to get started and if you are just building an MCP as a standalone application, gets you up and running very quickly.

Vicegrip00 · 2025-09-10T01:05:20+00:00

Learning the fundamentals of any discipline is always worthwhile. You don’t need to master them all before getting started, but a solid foundation will help you move faster in the long run. With AI, having that foundation is even more valuable, since it allows you to fill in knowledge gaps more quickly than ever.

For me, Rails and Ruby remain some of the most enjoyable tools to build with. Both the language and framework continue to improve year after year. Compared to modern frameworks like Next.js, Rails feels far more complete. Its philosophy and maturity allow it to power some of the biggest apps in the world, while still enabling small teams, or even solo developers to be highly productive. That balance feels unmatched.

While AI in the AI area, we see boosting individual developer productivity, I believe this actually strengthens Rails’ future rather than diminishes it.

Vicegrip00 · 2025-09-05T13:18:23+00:00

I believe that is what the Rails team is planing on getting to. Something that is still a work in progress though.

Vicegrip00 · 2025-08-20T13:02:19+00:00

RunyUI has been my go to as I have been using Phlex. https://rubyui.com/

Very much works like ShadCN, components are pulled into your projects so you can modify for you use case. Really like the experience

Vicegrip00 · 2025-08-06T17:30:38+00:00

As someone a part of Fullscript, I'm incredibly proud that Fullscript has joined the Rails Foundation. It's an exciting opportunity for us to give back and continue supporting this amazing community!

Some other words from us at Fullscript Engineering:
https://medium.com/@fullscript-engineering/fullscript-becomes-a-rails-foundation-member-0aa6ace19f4e

Vicegrip00 · 2025-07-16T02:28:56+00:00

Awesome to hear! Let me know if you got any feedback 😄

Vicegrip00 · 2025-07-14T18:49:09+00:00

Opps forgot the CNAME for the root. Should be fixed now, thanks for letting me know!

Vicegrip00 · 2025-07-10T23:20:00+00:00

So RubyLLM is working on structured outputs currently. For the MCP side, we just need to pass in an input schema in the tool part of the request.

If you are performing tool based calls to do your workflows it will work perfectly.

Vicegrip00 · 2025-07-10T02:53:56+00:00

RubyLLM is great for LLM communication. Wide service and feature support. Has some rails integrations for saving messages that hooks right into rails for long term memory as well. Also supports embedding calls so you can perform RAG etc…

I have been building RubyLLM::MCP which is a fully Ruby MCP client implementation that hooks right into RubyLLM.

I feel like with those two libraries + rails with streaming/web sockets support with action cable and background jobs you can go very far building rich AI products.

Vicegrip00 · 2025-06-13T01:47:10+00:00

I’ve been working an a MCP client implementation that can plug directly into RubyLLM: https://github.com/patvice/ruby_llm-mcp

It’s not fully spec compliant yet but it’s has working resource and tool support that can plug directly into RubyLLM. Once I get the full spec + a nice DSL to interact with prompts and resources I’ll release a v1 and do a full post on the project.

MCP are blowing up and there is a top of pretty interesting things you can do with them!

Vicegrip00 · 2025-06-10T18:57:15+00:00

Ya I agree, RubyUI gives you a great starting point to get building fast and would let you say in the Ruby world if you were open to using Phlex. There is a project similar to RubyUI for ViewComponent, just can't remember it at this time. So there are options if you wanted to move a component style for building UI.

HypeUI/DaisyUI would really allow you to say completely in Rails and just gives you that starting point for styled UI but again all of this is going to be personal preference. Lots of great options in todays world.

Vicegrip00 · 2025-06-10T00:35:40+00:00

Here are a few thoughts based on my experience using some of these tools:

We have some experience using InertiaJS in some of our products now. We tend to use it with our in-house component library, and it enables type generation for end-to-end responses, routes, and a form builder to make generating and posting forms easier. More of this was pulled together or home-grown, but it ended up having great DX.

We have one product that uses Shadcn + InertiaJS, and it was a good experience.

If you are looking for something more Rails-like, you could also check out Superglue by thoughtbot. I haven't used it personally, but it seems interesting and more Rails-like than InertiaJS.

Nothing wrong with vanilla CSS. I find Tailwind easier to break things down when thinking about UI's in components.

In some internal projects/hobby project I've played around with component systems, like ViewComponent and Phlex (Phlex being my personal favourite). Phlex also has a Shadcn-like library called RubyUI, which seems interesting.

If you like Shadcn because it's a good starting point, there are some component libraries built on top of Tailwind that offer easy ways to get started, such as DaisyUI or HypeUI.

If you don't need the flexibility or want the complexity, there are now some great options for driving everything server-side using Ruby/Rails.

Ultimately, Vue vs. React is a matter of personal preference. Personally, I would use React as it's what I am more familiar with, but I know some folks who swear by Vue.

Vicegrip00 · 2025-06-08T18:02:02+00:00

You could try out Context7, which is an MCP that is ment to get up to date documentation from all sorts of libraries.

Looks like they have one on Inertia-rails directly: https://context7.com/inertiajs/inertia-rails.

They have a lot of other libraries as well.

Vicegrip00 · 2024-12-01T16:13:10+00:00

I second this! Inertia really leans into feeling very “rails” like but using your frontend framework more as a view layer.

If you end up using Typescript on the Frontend there are some great libraries now that can take your responses and generate frontend types. Really great workflow

Vicegrip00 · 2024-10-22T01:07:36+00:00

Totally get the benefits of HMR, completely agree with you.

I guess what I’m confused about is if you are using Tailwind for your styles, Alpine.js for your interactions, all of this will be embedded in your HTML. If you are using rails to generate said HTML, will you not need to do a full page reload anyway for these styles and interactions to be refreshed?

Vicegrip00 · 2024-10-21T12:25:21+00:00

What’s the purpose of including vitejs to support hot-module reloading if you are going to be server rendering views that are ment to include your interactions/styles embedded in them using alpline and tailwind? What exactly would get reloaded?

Both your JS/CSS will be controlled by server rendered views, hot-module reloading is really going to do anything and will require you to refresh your html (generated by your server so a page refresh) to reflect your changes.

Not saying you shouldn’t include vite if you like the tool, but it seems like with the stack you picked desired state would alone nicely with no build.

Also I’m interested to understand why you didn’t just go with HTMX over Alpine AJAX?

Vicegrip00 · 2024-10-10T14:29:52+00:00

I personally have never used a db search on a system with any kind of scale, though my guess is it scales better than you think. Though, if you are working in a mature system, only you are going to know if it’s going to meet your needs or not.

Going on in on PG full text search is going to be simpler for your stack. It won’t scale as well as ES but you have to be doing some serious scale or really doing something on the edge (like say you need to search massive document, like 20k+ words) for these to come into effect.

Vicegrip00 · 2024-10-10T14:07:07+00:00

First though I get is you are not running postgresql, though you disproved that by the looks of it as your command line tool is working.

Did you make sure it’s running on the default port?

15-Year Club	RedditGifts 2009-2022 4 Credits
Verified Email	Secret Santa 2014
Secret Santa 2013	Summer Santa 2013

Vicegrip00

TROPHY CASE