My main concern is that the default structure becomes messy when you have more than just a biff project under , in my case it became problematic when vendoring deps. I also don’t like files in being “owned” by a tool, feels unpredictable. Would it be an idea to have a setting, say prod-dir , which is appended to /home/app everywhere? We would have to prompt for the dir in new-project.clj so that it would be set correctly in server-setup.sh etc.

instead of adding an option, I'd probably prefer to just have everyone use a sub directory for the workdir, sinc' I think that should work for everyone. if anyone really wants to use ~ for the workdir they can always edit server-setup.sh. however, to change bb deploy without a breaking change, might have to add a prod-dir option anyway... I'll see what would be required for the change (eventually 🙂)

I would still prefer an option, as I can easily see myself wanting to run more than one biff app on a given box. I have one box where I put all my projects that are not yet worthy of their own box. I would love to just provide a subdir for a new project and have it all work ootb. Maybe one option for prod-user and one for prod-dir would be ideal 😅

ah what kind of box is this? how much ram/how many apps? is the purpose of using one box to share resources or just to avoid setting up a new box/vm each time? in my tests a single app has to have 1gb ram, so I'm not sure there'd be much cost savings in most cases--instead of a 2gb vm you can just do two 1gb vms. though there is still setup time of course. I think the use case of deploying multiple apps to a single vm is/will be rare enough that it's probably not worth adding options to support it--probably better to just have people modify the server-setup.sh script and write a custom bb deploy task. (could be a good subject for another how-to guide!)

I have one box olavfosse-private w 4gb ram and one olavfosse-public w 8gb ram. Anything which is exposed to the internet goes in olavfosse-public and olavfosse-private only exposes SSH. my biff app is idling at 699M. The purpose is that i don’t have a good reason to have more servers 😅. More servers -> more work, more attack surface, more expenses, more keys, more databases, more firewalls, more web servers, more system updates etc etc. I do isolation via systemd, and if appropriate i pull the app out into its own server. > I think the use case of deploying multiple apps to a single vm is/will be rare enough that it’s probably not worth adding options to support it Maybe, maybe not. It doesn’t seem like a rare use case to me. Especially considering biff is marketed as “for solo hackers”. Hard to say without data. > could be a good subject for another how-to guide! 👍

sounds good! I still definitely lean toward "just set up multiple droplets" as the default/recommended approach, but regardless when I get around to it I'll see what it might look like to support both use cases without requiring custom server-setup.sh / bb deploy, and then we can evaluate from there

(as as aside--another thing I have also thought about is doing a how-to guide for making multiple biff apps that use the same jvm process. i.e. if you write your apps as libraries which provide plugins, then you can have a single parent biff app that includes all the plugins. each app would lose the ability to customize the framework at all, but you'd get to share a jvm process, so could cheaply run as many biff apps as you want on a single 1gb instance. good for weekend projects perhaps)

"Bunch of small services on a single box" is a good use case for piku IME, if you don't mind the extra (lightweight) tooling. Clojure is officially supported, but I have yet to see an example repo, so some tinkering might be necessary.

I've been wanting to try out Alpine.js for a while. I think it ticks all your boxes. I'm not familiar with dumdom

My .02: I'm currently playing with my first Biff/htmx project and I need an "island" of non-trivial UI interaction... so I've made a small "component" with Alpine.js: it can take you quite far, but I soon needed something more, with custom JS code. I think "custom elements" (web components) might actually make sense on this context. Kinda doing "bottom-up" design: enriching the html "language" to bring it closer to your app needs. I'll probably try with SolidJS or Preact first... (maybe via #C03U8L2NXNC ?). Anybody has experience in this area? any better suggestion?

I've thought about Svelte for that purpose--haven't tried it but seems really interesting