Publishing

Every .s9pk needs a registry to live in before it can be installed on a StartOS device. StartOS is deliberately flexible about which registry that is — you can run your own forever, submit to the Start9 Community Registry, or do both in parallel. Nothing about the packaging workflow requires you to distribute through Start9.

Self-Hosted Registry

The fastest and most autonomous path is to run your own registry — install the startos-registry service on a StartOS device, point start-cli at it, and publish. See Hosting a Registry for the full walkthrough (install, first-run setup, administration).

You can run a self-hosted registry in parallel with a Start9 Community submission: developers often keep an alpha/testing registry of their own while a more stable build is promoted through the community pipeline.

Start9 Community Registry

If you want your package on Start9’s official community registry, the current flow is email-driven. A developer portal with self-service submission and promotion is on the roadmap; until it ships, this is the interface.

The community registries, in promotion order:

• community-beta — https://community-beta-registry.start9.com — receives every PR-merge build automatically
• community (production) — https://community-registry.start9.com — promoted from beta on your go-ahead

Initial Submission

1. Email submissions@start9.com with a link to your public GitHub repository.
2. Start9 forks your repo into the Start9-Community GitHub organization and replies with any feedback.
3. Address feedback by opening PRs against the Start9-Community fork, not your original repo. The fork becomes the upstream for the community pipeline from that point on.

The Pipeline

Once your fork exists inside Start9-Community:

1. Open a PR against the fork with your changes.
2. Merge — when Start9 merges the PR, a workflow automatically builds, tags, and deploys the package to community-beta. You don’t run any publish commands yourself; the automation handles it.
3. Test the beta build. This is where a release soaks: install it from community-beta, exercise it, and give other users a chance to.
4. Promote to production — when you’re ready to ship broadly, email submissions@start9.com or open an issue on the fork. Start9 promotes the current beta build to community. The go-ahead is yours to give, not Start9’s.

Every subsequent change or version bump is another PR through the same cycle — merge publishes to beta, email/issue promotes onward.

Note

The email / issue loop is clunky — we know. A developer portal with self-service submission management and one-click promotion is actively being built. Until it ships, email and issues are how the pipeline is operated.

Pre-Publish Checklist

Before publishing to your own registry — or before opening / updating a PR on the Start9-Community fork — walk through this. For community submissions, these checks must pass before you open the PR: the merge triggers the build, and anything wrong will ship directly to community-beta.

1. Tag convention followed. Your version tag matches Git Tag Conventions.
2. All checks pass. tsc --noEmit, tests, and the pack step must be green.
3. README is current. Every action, volume, port, dependency, and limitation matches the code. No version numbers anywhere — see Writing READMEs.
4. Tested end-to-end on StartOS. Installed cleanly, service started, UI loaded (if applicable), health checks went green. Uninstall and reinstall to confirm teardown works.