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.

1. Install a registry service from any existing registry onto a StartOS device.

2. Configure its interface to reach your audience: LAN for private testing, .onion for Tor-reachable distribution, or a clearnet domain for public access.

3. Publish your .s9pk to it with start-cli:

   start-cli s9pk publish \
     --url=https://my-registry.example.com \
     myservice_x86_64.s9pk
   

Testers install by adding your registry’s URL to their StartOS and selecting your package from the list. If you want distribution to stay entirely under your control — not just during early testing, but indefinitely — this is all you need. Plenty of packages are distributed this way permanently.

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-alpha — https://community-alpha-registry-x.start9.com — receives every PR-merge build automatically
• community-beta — https://community-beta-registry.start9.com — promoted from alpha on your request
• community (production) — https://community-registry.start9.com — promoted from beta on your request

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-alpha. You don’t run any publish commands yourself; the automation handles it.
3. Promote to beta — when you’re ready for wider testing, email submissions@start9.com or open an issue on the fork. Start9 promotes the current alpha build to community-beta.
4. Promote to production — when the beta has soaked and you’re ready to ship broadly, same signal (email or issue). Start9 promotes to community.

Every subsequent change or version bump is another PR through the same cycle — merge publishes to alpha, 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-alpha.

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.