Unikraft Launches KraftCloud: Never Pay for Idle Again

Because KraftCloud leverages Unikraft, a unikernel library OS project, we are single-process. Postgres is multi-process since it uses the fork() syscall. If you require Postgres, we can set it up for you as a managed service. That said also, we are currently working on supporting fork() and this should become available in the next few weeks/end of April.

Re: bring your own DB: yes. We are setting up metros in many popular hyperscalers and IaaS vendors and DC zones. This means there should be no egress fees and you'll have data locality.

For serious deployments, be close to your data. If you get in contact (alex@unikraft.io), we can discuss further how we are approaching this.

And yes, we are working on cron, this will translate to setting up an instance to start at a regular interval and not auto-restart it (so it scales-to-zero). :-)

I could be mistakened.

There's an initial free tier that, but once limits are reached, we will switch to pay-as-you-go plan. Our next offering ("developer") is still work-in-progress, and we're setting it initially for our early customers with much larger workloads who need autoscale more than they need scale-to-zero.

1. Scale-to-Zero: don’t ever pay for idle again;

So I believe this is true? Where are you seeing a pricing page anyway?

1. Yes. We're essentially a baremetal solution. Either we run it on your behalf (this is kraft.cloud), or we deliver an ISO or AMI and this can be installed on-prem/cloud-prem. This latter solution is our enterprise offering.

2. eBPF used in this way, I feel, has become a symptom of the problem that we're trying to solve at Unikraft: the bloated Linux- (and cloud native-) stack. In the end, you're adding more tools or doing more tricks to try and do computationally less since performance and running faster is about performing less operations in the critical-path. Unikraft approaches the problem space differently: bottom up (app first, then dependencies, then select OS libraries/primitives based on required syscalls) as opposed to top-down (taking away from Linux, its distros, removing functionality, making short-cuts, etc.).

Including acceleration libraries & device drivers could severely impact the size and complexity of the resulting binary image. API remoting though could be something.

disclaimer: We're building a solution based on API remoting, and we have an example integration with Unikraft, the unikernel tech that kraftcloud is based on.

We have a whole section in our documentation's guides section on example usecases with database:

https://docs.kraft.cloud/guides/#databases

They work exactly as you suggest, they scale-to-zero when no requests are made and data can be safely stored/transactioned in persistent volumes on the platform too.