Three simple consumption models to support your journey to serverless Ruby & Crystal

Free Tier

1 FREE Runner per Month

Fully hosted & managed
Community support


per runner per month

Fully hosted & managed
Uncapped usage
Priority email support

Self Hosted

Deploy to any infrastructure
Priority email & chat support



How does the FREE Tier work?

Currently, only the Free Tier version of the platform is live with SaaS and Self Hosted versions available soon. When you deploy functions from the FaaStRuby CLI, those functions will be deployed by a cloud-based, multi-tenant control plane to runners hosted on infrastructure that is fully managed by us. The free tier is limited to a single free runner per month.

How does hourly pricing work?

Runners are billed hourly up to a monthly cap of 720 hours. At least 1 runner must always be assigned to an account in order for your functions to be called.

If you use additional runners for fewer than 720 hours during the month, you will be billed for each hour that you used it. If you use a runner for more than 720 hours that month, you will be billed at the monthly cost.

We calculate Runner pricing this way so that consistent month-to-month usage results in a consistent invoice.

How many Runners will I need for my functions?

Runners execute functions as soon as they are triggered. You should try to keep your functions slim - the faster they are, the more requests per second you can serve with a single Runner. To calculate how many Runners you will need, first deploy your functions to a cloud workspace and watch their execution time by making requests with the header Benchmark: true. Then estimate how many requests a Runner could serve per second based on the execution time of each function. Divided the number of requests per second you would like to be able to serve by the number you calculated previously and that will give you the number of Runners you need.

For example, say you have a function that executes in 100ms. That means you can serve that function at a rate up to 10 req/s with one Runner. If you want to serve that function at a rate up to 20 req/s, it will need at least 2 Runners.

What happens when all my Runners are busy and other requests arrive?

Runners will do the best they can to serve all your requests. When all your Runners are busy, every subsequent request gets stored in a temporary queue and discarded if they are waiting for more than 10 seconds for a free Runner. When this 10-second timeout is reached, the request will fail with a 429 - Too Many Requests.