Try out https://fly.io again. I'm really interested in Fly but every time I use it I run into weird production bugs. But if it's more stable now, it'd be interested to either get it working nicely with XTDB or maybe write a howto for using sqlite + litestream instead since Fly is big into those.
For XTDB, that could mean setting up checkpointing + a howto and/or helper code for setting up a new deployment with Postgres + MinIO. Or maybe--and I think this would be pretty interesting to experiment with--after using Fly to provision the server, we could treat it more like a long-running VM than a short-lived container. e.g. instead of Postgres + MinIO, you could just set up a storage volume and use that, same as setting up a DigitalOcean droplet with the XTDB standalone topology. clj -M:dev deploy and clj -M:dev soft-deploy could likewise rsync the code onto the storage volume--no need to go through a whole fly deploy for application code changes. You'd only need to do fly deploy when you change the Dockerfile.
Eventually, Fly could theoretically replace DigitalOcean as the default recommended deployment provider, however it'd need to be rock solid. In the mean time, howto documentation + maybe some helper code in a standalone library would be great.
Try out https://fly.io again. I'm really interested in Fly but every time I use it I run into weird production bugs. But if it's more stable now, it'd be interested to either get it working nicely with XTDB or maybe write a howto for using sqlite + litestream instead since Fly is big into those.
For XTDB, that could mean setting up checkpointing + a howto and/or helper code for setting up a new deployment with Postgres + MinIO. Or maybe--and I think this would be pretty interesting to experiment with--after using Fly to provision the server, we could treat it more like a long-running VM than a short-lived container. e.g. instead of Postgres + MinIO, you could just set up a storage volume and use that, same as setting up a DigitalOcean droplet with the XTDB standalone topology.
clj -M:dev deployandclj -M:dev soft-deploycould likewise rsync the code onto the storage volume--no need to go through a wholefly deployfor application code changes. You'd only need to dofly deploywhen you change the Dockerfile.Eventually, Fly could theoretically replace DigitalOcean as the default recommended deployment provider, however it'd need to be rock solid. In the mean time, howto documentation + maybe some helper code in a standalone library would be great.