Standalone domain(s) for apps

[elepedus]

Livebook apps are an excellent way of rapidly prototyping ideas & iterating on them. I had largely given up on building side-projects because the initial project setup would take multiple coding sessions, by which time life had moved on and I no longer had the time to work on it.

Now I have an idea, sit down, and within minutes I can be iterating on it. UI, API, AI, it doesn't matter, I can just start, and get meaningful results fast, and I can even deploy my app for the world to see 🚀

However, to go from a prototype to an MVP, I still have to break out of Livebook, set up a project, a server, a domain etc. etc. etc., and in doing so I lose the super-tight feedback loop that I enjoy in Livebook.

I'd love to be able to configure an apps domain in Livebook, and launch apps to arbitrary paths on that domain.

So I can point the domain's DNS entry to my Livebook server, let Livebook know it can use it, and then deploy apps at different paths, like they were pages or microservices.

If the team is open to it, I'm happy to work on this, but I will need some guidance, as I think it's a bit of a step up from my past PRs.

[josevalim]

Hi @elepedus! We already built something similar on Livebook Teams: https://livebook.dev/teams/

The only part that is not configurable is where those apps live. They are always at /apps/foo-bar. We could make this somewhat configurable, but it would help to understand how do you want to deploy those.

For example, if you want one machine to host different apps for the same client, what we have available should suffice (let us know if it does not). However, if you want different domains to host different apps from the same machine, we would need more affordances.

Basically, the whole deployment aspect is solved, we just need to allow them to be served from different places.

[josevalim]

Perfect, thanks. We could also support something like LIVEBOOK_APPS_SUBDOMAINS=.speedrun.dev, so if you access "foo.speedrun.dev", we automatically rewrite it internally to "/apps/foo". We will need to double check how several links are generated, but they already have some complexity because they need to deal with apps and sessions anyway.

But there are other things that may get in the way of "launching brands". For example, there is a Livebook icon and submenu on every app. There may be others too. Using /apps as a starting point may help to find other blockers before going ahead.

[elepedus]

Honestly, I'm ok with the Livebook icon to start off with. It would be nice to be able to tweak that in the future, but just having "a place to call home" is the most important starting point

[josevalim]

If you would like to submit a PR for LIVEBOOK_APPS_SUBDOMAINS, we would gladly review it. I can't confirm though it would be approved, that would require the feedback of others, but maybe it brings more insights into the problem too. :)

[elepedus]

Sure, I would love to do that, and I'm happy to explore different approaches to find something that is acceptable to the team.

Only snag is I have no idea where to start with this one! 😅

I saw an old post from Chris McCord about using a plug to pluck the host from the conn and prepend it to the path, but early experiments with doing that in Livebook didn't get me very far.

How should I proceed?

[josevalim]

My only idea would be fiddling with conn.host in the endpoint (before the router) when path_info: [] and changing the path_info accordingly to the path.