Ruby in Netlify Functions

I’d love to see Ruby as an option for Netlify Functions instead of just JavaScript and Go. Ruby support has added on AWS Lambda in late 2018 and should make this feasible. I’d love to see it paired with Middleman and Jekyll.


Hey Ben,

Appreciate the feedback and I’m interested to see if it picks up momentum. Our functions repo is public; feel free to x-link an issue between there and here!

Unfortunately I’m not holding my breath at this point for additional language support. There have been many requests for Python as well as Ruby in other threads (What Function-ality would you like to see? - #6 by rob) (Python lambda functions?) for months now. I understand this stuff takes time, but “it’s on our feature request list” isn’t really an answer. Is Ruby support actually planned? Q3? Q4? To add fuel to the fire, I’ll soon be releasing a new Ruby microframework for serverless functions that will work on Vercel, OpenFaaS, or any Rack-compatible configuration—perfect for running alongside Bridgetown, Jekyll, Middleman, etc.—and I’d love to support Netlify Functions as well. But if it’s not under active development… :man_shrugging:

I think you’re wise not to hold your breath, and to find a different way to make this happen such as deploying to your own AWS account directly.

You’re one of less than 10 people to ask for this, so the demand isn’t there for us to even begin investigating implementing it yet. To clarify, “having an open feature request” does not mean “Netlify plans to implement it”, so the amount of time ago it was requested, or how long it might take you to implement does not really impact anything on our side.

Rather, it means:

  • that our Product Management team has been made aware of the request
  • that our Support team will make sure to respond in this thread (and individually to any helpdesk cases that have been opened on the topic) in case we either implement it, or decide never to implement it. Neither of these things has happened or is likely to happen soon, just to set expectations. TL;DR it’s not a bad idea, but we’ve got a few hundred different ideas, most of which will enable thousands of workflows, rather than dozens :slight_smile:

Your framework is a very interesting data point to consider in those plans, so thank you much for raising it! I will make sure our product team is aware of this specific post, rather than the request in general, but I know what is on our roadmap for the next couple of quarters it is pretty full, so even if it becomes popular amongst our highest-paying customers, that might not move the needle much considering the work we already have planned. Or it might - fortunately I am not the one choosing what we do :slight_smile:

We don’t give timelines for releases that may not happen, so what you can be sure of based on our lack of saying anything is that we have no solid plans to release this feature (yet).

Hopefully that clears things up, but let me know if not.

Thanks for such an in-depth response! That’s a real bummer. I know of plenty of other Ruby hosting options but it does make it more challenging to stick with Netlify for the static part. Anyway, once again I appreciate the info.

Yeah, this is a tough one. My full time role right now is actually that of a RoR back end with a massive PWA front end, so I totally understand both sides of the equation. Honestly though, I haven’t written more than 2 Lambdas in Ruby even though it’s been out for a while now - it’s sort of just a late addition to an already-set status quo of “Lambda === JS” :confused:

@jaredwhite while I too would love to see Netlify grant Ruby Function support (although I’m not sold that I would actually use it tbh), I think the best thing you could do is convince the community to want it :slight_smile: Netlify’s product team’s goal is always to provide the biggest number of folks the enhancements they want as fast as reasonable… if you can get more folks on board with the desire, the Product team will definitely hear that!


1 Like

Yeah, I see it is a bit of a chicken and egg thing… People aren’t always going to demand something that doesn’t exist yet… I think the serverless computing mindset hasn’t really taken hold in many sectors of the Ruby community, but the flipside is the tooling often hasn’t been there in the first place. Plus Ruby isn’t as popular in DevOps as something dedicated to massive performance gains such as Go or Rust for example.

All that being said…for general web server framework coding I think Ruby still shines brightly and that’s why I’m hoping to get the microframework/functions story to take off as well. :slight_smile:

1 Like

OK folks — this is a pre-pre-release, but I think I’ve gotten it off to a pretty decent start now. I’ve been working on a micro-framework called Phaedra that’s well-suited for use in serverless function contexts (and also Docker). In a nutshell, you can add /api/* to your Bridgetown (or Jekyll, or Middleman) sites. :smiley:

There’s a section in the Readme about how to use Netlify’s proxy rewrites to set up the /api endpoint. One easy way to get Phaedra up and running to use use Using Docker you can deploy the API app to a global network of container hosts in minutes.

I could envision this being super helpful for providing services like authentication, paywalled content, payment processing (Stripe, etc.), and other bits of functionality on the “A” side of JAMstack.

Another thing I’ve been experimenting with is connecting to a MongoDB database using something like ScaleGrid or Atlas. Makes it super-easy to store and retrieve JSON “in the cloud” right from your Ruby API.

Anyway, I welcome your feedback and suggestions!

1 Like

We use a Ruby backend as well, and the repo is massive. We run it on hosts, not in functions, because functions aren’t suitable for so much of what it does:

  • long billing runs
  • asynchronous “can be done eventually” work
  • some calls longer than 26 seconds, though generally not for functions that would be called synchronously from a webpage
  • can make dozens of database calls

We use javascript and go from functions (as our feature allows), but we don’t try to run ruby in them - but ruby powers our API which is all that you are using from

I know that some people really do have small, synchronous tasks that run from Ruby and could reliably work as a function. But I think that others (like us) have ruby that really needs a long-running server process rather than trying to cram everything into a lambda.

Note that we have NO intention of becoming a general purpose ruby/php/node host and running server-side code like that.

1 Like

Hey, that’s super awesome—I didn’t realize Netlify used a bunch of Ruby in its own backend.

Good points about functions vs. larger server-side applications. What’s exciting to me is there are so many opportunities now to pick exactly the right hosting environment for the job. Run the gamut from Static Builds -> Functions -> Docker containers -> Cloud VMs -> Own your own metal… (that last one is probably not too applicable anymore, but I suspect it’s still best for a tiny % of apps)

Bump. Vercel supports Ruby serverless functions. Render supports static sites + Ruby containers and even Rails APIs natively. Ruby support on Lambda and GCF? Check and check.

Not sure how much longer I can recommend Netlify for Ruby developers. :confused:

Hey Jared :wave:t2:

Just asking out of curiosity here in a genuine way. I’ve got a lot of background in both Rails and JAMstack and truly enjoy both, and I think they’re used for different things. Do you find yourself recommending serverless/JAMstack-style setups to Ruby devs to begin with? It’s not something that strikes me as a norm, I guess. I know there’s always been a big movement to grow Ruby beyond Rails, which I don’t have any issue with… but beyond Rails, Ruby alone isn’t a performance monster, has a super opinionated syntax that doesn’t lend well to other languages, and isn’t known for its concurrency systems. I’m not trying to dump on Ruby — I love Ruby and eat/breath Rails all day long, but (outside of Hotwire) doing ‘web’ without learning any Javascript is pretty impossible and serverless running on javascript just makes a lot of sense. What leads you / drives you to want to get more Rubyists into serverless?

Hope that doesn’t come off poorly, I just genuinely don’t see the benefits per se and want to hear them. Certainly open to having my opinion changed :stuck_out_tongue:


“has a super opinionated syntax”

Haha, well I could say the same thing about TypeScript. Or Go for that matter, another language that is supported by Netlify.

Here’s but a brief example. Zach Leatherman got Eleventy to rerender a page dynamically “in the cloud” by using a serverless function. Cool, right? This is the next evolution of the Jamstack!

Well, I’m heading up the Bridgetown project which is a competitor to Jekyll, also Ruby-based. I’m working on an easy way to dynamically rerender content with that too. If Netlify supported serverless Ruby, I could whip up a quick function and it’d work in exactly the same way as the Eleventy example. But, alas, not possible.

The other problem here is optics. Netlify’s jam (wink) is to convince the world that you can use Jamstack techniques to build web apps, and serverless functions are promoted as a key player in that new world. If I, as a Ruby developer, am completely left out of one half of that equation—static builds? yep! functions? nope!—that’s a real concern. Of course that’s not just an issue with Ruby, but with Python, Java, C#, whatever. AWS Lambda says it “natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby code, and provides a Runtime API which allows you to use any additional programming languages to author your functions.” Yipee! But Netlify supports only 2 of the 7 options listed there. I don’t think Netlify should be in the business of picking winners and losers when it comes to who can build atop serverless infrastructure. They’re communicating—intentionally or no—to large developer communities that they aren’t welcome in the Jamstack world. If that’s indeed the case, it’s a real shame.

Anyway, that’s my take on it. :slight_smile: Thanks for asking!

1 Like

That was incredibly well-written, Jared, and I have surfaced it to our Product team who are working on the future of functions. Thanks for taking the time to share so articulately and with such great context.

Of course some context is that additional functions runtime support is a lot of work - for our team to build once, but then also to maintain that - it isn’t a “set and forget” thing on our side as AWS and our service grow in capability - but also for our Support team to try to work with when we are not all polyglots, is another. Not that it is impossible, or a bad idea, or we shouldn’t do it - just try to be aware that it is a challenging problem to solve well, so we haven’t pounced on it faster since the implementation is just “the tip of the iceberg” for work needed to enable a good experience using it.


Hi Jared, very well articulated. Do you happen to know whether there has been any movement bringing Ruby into the lambdas?

Hey @nkrasnogor,

There’s no movement in this area at the moment. We recently announced Rust support in Functions, but nothing so far for Ruby.

Both a bump for this topic but also a big congratulations to @jaredwhite on a v1.0 release of Bridgetown. As a fellow rubyist I’m excited to see this grow and will look to use it myself soon — baking in erb sounds wonderful :grin:



Thanks @jonsully — much appreciated! :blush: