Show HN: ExecAPI – Zero-Infra Background Jobs as a Service | Hacker News Reader

Show HN: ExecAPI – Zero-Infra Background Jobs as a Service

execapi.com

2 pointsammmir4 comments

Hey everyone!

I'm excited to show off ExecAPI, a zero-infrastructure background job runner as a service. It's a bit like a hosted Sidekiq (if you're from the Ruby world), except that you can write your job workers in any language that has a Docker image available.

Background jobs (aka workflows) are triggered by either a Cron schedule or an on-demand HTTP request, which then executes one or more actions. Each action is user-submitted code that runs a Docker image of your choosing, and is run in a secure sandbox (currently gVisor, perhaps Firecracker VM in the future).

It's a bit rough around the edges right now, but I'd love to get some feedback on the direction I'm going with this. The plan is to build a low/no-code experience consisting of triggers and actions that can be be used to build automation workflows, a bit like Zapier, IFTT, et al. and to provide an on-prem/private VPC solution.

Open articleView on HN

Congrats on launching - Its so hard to get this far!

A few points of feedback:

- Some real world use cases would be helpful to people frame your product. I saw your guide but that isn't a really something useful and could do in my app itself.

- You should add how this service compares to other function as a service SaaS's on the market. I'm not sure why I would pay $10 a month when AWS lambda can offer the same features.

- Whats a project? The pricing page mentions it but I don't see it anywhere else

- Is their a free tier? I see it mentioned on the change log but no where on the site.

Thanks for the feedback! You're right, there are many assumptions in my head about what the product is intending to be, and looks like I need to be more explicit in the marketing materials :)

Right, it'll be tricky to compete with other SaaS that offer code execution, since they have free tiers and a lot of mindshare already. Other feedback is also hinting that I should focus more on workflows/process automation for non-developer users, rather than code actions. This is the direction I want to go anyway, but I decided to launch with what I have already.

The project term is a bit premature, since I haven't fully finished. Essentially, a separate collection of workflows/jobs, meant for team accounts that can have multiple users.

There's no free tier, but there's free credit on signup so you can try it out without any payment or credit card. Maybe I should have a free tier? My overthinking brain is worried about abuse, but maybe I shouldn't care at this point if nobody is using it yet... :)

This is neat. How does it compare to Cloudflare Workers?

I’ve been thinking about building a tool like this for fun. Does the code run inside a Docker container? I’ve been looking at Firecracker VMs for sandboxing which seems pretty cool

The main difference is that ExecAPI is intended for running periodic or triggered background tasks, and you're not limited to JavaScript or Wasm code running on just V8. You can run any Docker container as a background job; mix and match Bash, Python, and Node.js if you like. I would say ExecAPI is closer to a combo of Cloudflare Workers Durable Objects and Queues products, than meant to handle/filter HTTP requests traveling to your origin server.

Code ("actions") run in a Docker container using the gVisor runtime. I'm also toying with using firecracker-containerd, which uses Firecracker microVMs underneath.

It's funny you mention that. A previous "iteration" of this project was an edge function runtime, which would take Docker images and convert them to Firecracker VMs, prebooting them, and taking a snapshot at the right moment using some VSOCK magic. It was similar to Fly.io, Lambda@Edge, etc. and ultimately I decided to go another direction because most people don't care about low-latency compute on the edge.

Reply on news.ycombinator.com