> Is there working stack you can deploy to your own VM and deploy Wildebeest to?
I don't think anyone has tried it yet. There are probably some missing pieces that need to be filled in. In principle, it should be possible to fill in those pieces without changing any of the Wildebeest code itself.
As a simple example, Workers KV provides a simple key/value storage API, basically just the methods get(key) and put(key, value). In workerd, you can use this API, but you have to configure it to point at your own back-end that does the actual storage. It translates into a basic HTTP API (mostly just GET/PUT). You could pretty easily write a Worker (running as another nanoservice on top of the same workerd instance) that uses local disk storage to back this API, or sends the data to some other back-end of your choice.
Eventually we should have ready-made shims like this to handle a lot of situations, but it's still somewhat early days of workerd and at present some of this is still missing.
I don't think anyone has tried it yet. There are probably some missing pieces that need to be filled in. In principle, it should be possible to fill in those pieces without changing any of the Wildebeest code itself.
As a simple example, Workers KV provides a simple key/value storage API, basically just the methods get(key) and put(key, value). In workerd, you can use this API, but you have to configure it to point at your own back-end that does the actual storage. It translates into a basic HTTP API (mostly just GET/PUT). You could pretty easily write a Worker (running as another nanoservice on top of the same workerd instance) that uses local disk storage to back this API, or sends the data to some other back-end of your choice.
Eventually we should have ready-made shims like this to handle a lot of situations, but it's still somewhat early days of workerd and at present some of this is still missing.