I'm working on Daestro[0] - a job orchestrator that can directly integrate with cloud providers like AWS, Vultr, DigitalOcean and Linode to create instances for jobs to run on and destroy when done.

Currently I'm working on following features: - Multi user support (Team) on project level - Then I'll look into whether to add support for OIDC/SSO now or not - Alert on slack - Webhook support

0: https://daestro.com/

I am working on Daestro[0] which is a cloud-agnostic, self-managed job orchestrator that bridges your compute — anywhere.

Apart from bringing your own compute, Daestro also integrates with AWS, DigitalOcean and Linode.

0: https://daestro.com

I am working on Daestro[0], which is a cloud agnostic job orchestrator with built-in support for AWS, Vultr, DigitalOcean and Linode to run jobs on. Daestro can spawn and terminate compute instances based on requirement. It is suitable for running batch jobs or data engineering related jobs.

Self-hosted compute can also be linked to Daestro to run jobs on.

[0]: https://daestro.com

In general I love the PaaS experience and I can see the value Flightcontrol can potentially provide to the companies that work mostly with AWS. The free starter plan for individual is tempting to try out Flightcontrol, BTW what is the service limit for free plan? I could not find it.

I am also working on similar tool[1] but it's bit more niche to batch jobs type functionality but not just limited to AWS rather it's cloud agnostic.

[1]: Daestro - https://daestro.com

There is no service limit on the free plan. It’s limited to a single user instead.

I've been building something with HTMX since the last week, I have not done whole lot of complex things with it but I don't think it will pose any problem when time comes.

I get the premise of HTMX and when and why to use it, it's not solution to everything however it is a blessing for backend developers' who wants to work on frontend.

-> A bit of backstory

For my project Daestro[0], which is bit complex (and big) I chose Rust as backend and Svelte (with Sveltekit) as frontend SPA app. This was my first time working on both. After years of working on Django, I wanted to try statically typed language, after some research and trial, I chose Rust. Sveltekit was obvious because it made sense to me compared to other frameworks and it was super easy to pick up.

After working on Sveltekit for a year, I realised I've been spending a lot of time doing these same thing: 1. You create the api on the backend 2. then you create Zod schema on the frontend for form validation 3. the create +page.ts to initialize the form 4. in +page.svelte you create the actual form and validate it there itself with zod before sending it to the server

Hopping over two code bases just for a simple form, and Daestro has a lot of forms. I was just exhausted with this. Then HTMX started to get a lot of traction, I was watching it from a distant but having worked with Django and it's template, I was dismissive of it and thought having separate frontend is best approach.

-> Why I'm leaning towards HTMX now?

- Askama (rust crate) is a template engine which is compile time checked - Askama supports block fragments[1], which is you can render certain part (block) of template, plus for HTMX usage - Askama's macro almost don't make me miss Svelte's components - Rust has amazing type system, now you can just use it, no need to replicate those on Typescript - same codebase, no more hopping - only one binary to deploy (currently for Daestro I've 3 separate deployments)

-> My rules for using HTMX

You must self-impose a set of rules on how you want to use HTMX, otherwise things can get out of you hand and instead of solving a problem you'll create bigger ones. These are my rules:

- Keep your site Multi-page Application and sprinkle some HTMX to make it SPA like on per page basis - make use of hx-target header to only send the block fragments that is required by HTMX (very easy with Askama) - do not create routes with partial page rendering instead a route must render complete page, and then use block framents to render only what is being asked in hx-target - Do not compromise on security[2]

[0]: https://daestro.com [1]: https://askama.readthedocs.io/en/stable/template_syntax.html... [2]: https://htmx.org/docs/#security

I'm adding feature to run jobs with custom CPU and Memory quota, so that multiple jobs can be run on a single system to better utilize it's capacity.

This is for Daestro[1] which is a cloud agnostic job orchestrator.

[1] https://daestro.com

Wow this is fast.

However I tried rustls with redis for my axum application, for some reason it was not working, even though my self signed ca certificate was updated in my system's local CA store.

After a lot of try I gave up then thought about trying native tls, and it worked in first go.

Did you file an issue or ask in the rustls Discord channel? We're happy to help.

The irony is that due to CA stores (and how verification is handled) it's usually a tad more ficklish to replace TLS clients than TLS servers.

Was there no way to provide a custom CA store (that only included your self signed one)?

Did you try rustls-tls-native-roots? rustls-tls defaulting to only use the webpki bundle caught me off guard on a system with a bespoke CA

Working on adding Job schedule and cron features in Daestro[1].

About Daestro: Daestro is workload orchestrator that can run compute jobs across cloud providers and on your own compute as well. More like cloud agnostic batch jobs or step functions.

[1]: https://daestro.com

That's a nice way to write blog using Obsidian. I am using zola for my blog[1] and I might use obsidian for better UI.

For my work[2] I am using SvelteKit and written my own blog using mdsvex and enabled pre-render. That works well too.

[1]: https://vivekshuk.la [2]: https://daestro.com/blog

A cloud agnostic platform to run your compute workloads across cloud providers. Currently supports Vultr and DigitalOcean. More cloud providers coming soon. Will also release support for on-prem.

Daestro - https://daestro.com