Add documentation in regards to self-hosting JSR

[halvardssm]

Hi! Very excited about JSR! One of the big selling points is that it is open source, but what I am lacking is better documentation in regards to self-hosting. This would be especially interesting for companies with restrictions regarding their internal codebase.

The use case would be:
A company has multiple internal tools and apps written in JS/TS. They would want to create one or many shared libraries that they can use in their multiple repositories and apps. They have restrictions as to where they can publish and host said library. Another requirement is that it is restricted to the company domain and developers, and that it is fairly easy to integrate with the current ecosystem.

Current options:

• Publish to code hosting tools like github or gitlab.
• Publish to NPM or JSR (but not possible with private packages).
• Git submodules or similar.

Proposed solution:
Documentation is added that describes the steps to self-host JSR. This should ideally be a one command solution that uses docker or similar.

Bonus:

• As self hosting requirements would be less demanding than a centralised global registry, a database such as SQLite would be sufficient in most cases.
• Private registries with SSH key or other similar security options (see NPM).

[ericlery]

I agree, especially about SQLite, or could also be Deno KV. The easier it is to self-host, the better it will be. Ideally just two files, the JSR binary and a file-based database.

I've notice there is no GitHub Releases yet, and that the documentation for self-hosting is Terraform config files for Google Cloud. That's good, for people that know Terraform, and those who trust Google to not shut down Google Cloud in the future.

I would greatly appreciate a straightforward binary and can be upgraded via jsr upgrade, similar to the Deno self-contained binary.