[Other]: Self-hosting Shuttle on own server or own cloud

[jonaro00]

"Self-hosting" Shuttle is a common question we get, and it has many interpretations. Here are 4 interpretations, and our stance towards them:

• Running a single project locally with cargo shuttle run --release --external with Docker integration for databases: This is currently possible and might be enough for some light use cases.
• Running the Shuttle Docker stack on a single server: ~~Might be possible, but requires lots of manual modification and good understanding of Shuttle. We are not currently focused on this use case.~~ This will soon be impossible due to Shuttle's infra going cloud-native.
• Full deployment of Shuttle's infra into your own AWS account or other clouds (aka "Bring your own cloud" (BYOC)): ~~This is a huge project and is currently far away.~~ Will likely not be possible.
• Running a "Shuttle orchestrator" in your own cloud that allows you to manage Shuttle apps that are hosted in your own cloud, via the central Shuttle API: This is an idea that we might explore in the future.

Related: https://github.com/shuttle-hq/shuttle/discussions/976#discussioncomment-7854392

---

_{This issue is a part of the Product Feature Poll (all issues). React with :+1: if you want this feature. Comment if you have suggestions related to this feature.}

[Flash1232]

Heroku/ Dokku-style deployment of Rust Web apps would definitely be a game-changer, as currently, it involves a lot of manual work, even cross-linking of the binary to use in a docker container in some cases. Having a PaaS-Tool like Shuttle to self-host (cases 2 and 3 mentioned above) and quickly deploy and update Rust apps would thus be very nice.

I understand this would potentially be orthogonal to your business interests at the moment though.

[erlend-sh]

I understand this would potentially be orthogonal to your business interests at the moment though.

True. This is why I’m a proponent of the source-available Polyform NonCommercial license for this kind of work, since it resolves the disincentive that otherwise prevents the work from being shared at all. It helps proprietary layers go from closed to minimally open.

For some similar prior art, see https://element.io/blog/element-starter-open-source-meets-on-premise-collaboration/

[jonaro00]

Updated the issue with one new item, and updated descriptions.