Swift Runtime for Vercel Serverless Functions

Hey everyone,

I've been working on a Swift runtime + SPM plugin for Vercel that makes it trivial to deploy applications to their platform. I have it in a place where its fully functional so wanted to share:

Under the hood Vercel deploys to AWS Lambda so I was able to take advantage of their Build Output API and the AWSLambdaRuntime from swift-server. Feedback, suggestions and PRs are all welcome.


This is fantastic! I haven't used Vercel functions yet but this will get me to try them out.

1 Like

This is amazing. I was also working on this in my spare time, you beat me to it :smile:

Is there anything that I could help out with? And is there any interest in turning this into an official community-supported runtime?

Great work, love to see this!

1 Like

@gonzalonunez thanks so much! I would love additional help on this. Biggest area right now is probably local development. I don't like that you need node installed. Ideally I wanted to build the local server with Vapor but I had a hard time linking dependencies to the plugin.

As for making this an official runtime - Vercel has a bizarre definition of "runtime". Right now their official "runtimes" are designed to play with Next.js, in that they allow you to put files (ex. go, rust, etc.) inside Next.js /api/ routes. After speaking with the team, they agreed with me that this is not the direction we want for this project, where we really want the entire application to be swift (not a javascript application with a bit of swift) and they confirmed that targeting the build output API is the correct approach.

Of course getting some recognition on that community-runtime page would certainly be nice. I've sent this around to a few people at Vercel but haven't really gotten much feedback from them to be honest.


I see! Fascinating, I had briefly tried the other approach that I think is used by most of the other community runtimes, I was getting close but still a ways away from getting it all working. Agreed that it's weird :smile:

Getting this to be a Vapor server would be awesome. If it's of any help, I recently built a tiny little file-based routing library for Vapor apps that gives them a little more of that Next.js-like feel of having separate functions in separate files. So I'd obviously love to be able to deploy Vapor apps with Vercel!

That said, I'd also love to be able to deploy serverless functions written in Swift but use Next.js for the frontend. But I'm still relatively new to all of the server-side Swift world, I haven't explored what frontend is like in the Vapor apps.

I'll take a look around the repo and try to wrap my head around everything, maybe I can get Vapor working. I'll see what I can do!

I'm new to server development but this seems very exciting. Related, what would it take for swift to run on Deno Deploy? Would it work since Deno Deploy supports WASM? And more specifically to run on Supabase? (which uses Deno Deploy for their edge functions) I use Supabase for the backend for my iOS apps and thought swift as edge functions would be really useful, but I'm still learning so let me know if this makes any sense.

Hey Douglas,

Currently there's no way to run Swift on Cloudflare Workers or Deno Deploy, but you can run on Fastly Compute@Edge and I've developed a very similar runtime to do so:

This is possible on Fastly because Fastly publishes a set of WASI host calls that allow Swift to interop with their platform. Things like network requests, caching etc. are all available via publicly documented specs. Cloudflare and Deno are built on V8 isolates and do not document any WASI host calls which would mean we would have to bridge to JavaScript to accomplish anything meaningful with WASM.

Take a look at the Compute SDK and if you want a hosted platform for trivially deploying to Fastly then take a look at https://swift.cloud which takes away all the headaches. I also have a blog post here which describes how to deploy to Fastly on your own: Deploy server side Swift to Fastly | Swift Cloud

OK I see, very cool! And I've seen Swift Cloud before, I think iOS dev weekly newsletter. I am intrigued, (and thats really cool you built that!) what then are the difference between Vercel and Fastly functions?

Yeah good question, some really important differences:

  1. Fastly is a WebAssembly runtime. Vercel functions are AWS Lambda
  2. Fastly requires us to compile Swift to WASM and thus use the SwiftWasm toolchain which is not officially supported by Apple.
  3. Vercel allows us to use the production Swift toolchain, and the AWS Lambda runtime which is officially supported (and built) by Apple

If you're reading that and thinking, why would I bother using Fastly, then I wouldn't overthink it and definitely just deploy on Vercel. There are serious benefits to using Fastly though for specific workloads.

Fastly will globally distribute your Swift code, virtually no cold start, can handle 1M+ requests per second, supports full end-to-end streaming. AWS Lambda is much more limited in some of those networky specific metrics.

Here's a deck I built for server side swift conf that explains some of the benefits of Fastly specifically: Globally Distributed Server Side Swift - Google Slides


Ok I see! Thank you for the rundown, very helpful.

Yeah for my needs I probably would just go the Vercel route. Or just write edge functions in javascript on Supabase even though I'm sad it's not swift haha. I don't yet know enough or have something at scale that needs what you're describing, but I like learning.

Thats interesting though, you're saying Fastly ultimately is faster and can scale better than AWS lambda / Vercel? and so thats why you went through the effort of the WASM implementation right?

Is AWS lambda the only server-less service where swift runs natively then? Why is that? What would it take for Fastly to have it run without needing WASM? Isn't it all on linux?

EDIT: I see your deck, very cool, and I guess that answers my question, they have proprietary runtimes either V8 (deno deploy etc) or WASM (fastly etc), what about Lambda then, where does that fit?