Release and upgrade policy
NoticeOS release evidence identifies the source commit, toolchain, schema and the checks actually executed. A package version or successful build alone does not establish a qualified release. Package metadata alone does not state a support or upgrade guarantee.
What can be installed today
The source installation starts a new, empty standalone installation with Postgres and a Dolt task database. Existing installations require their own configuration and maintenance procedures. Standalone access relies on a trusted network or access layer; it is not a public login-protected hosted product.
The application container starts an already prepared installation; pnpm os:setup, or its launcher's setup, prepares a new one. The container itself does not initialize or migrate either database. Its declared platform and fixture checks are evidence for those exact inputs; they do not show that every host or architecture has been tested.
Every main commit that passes CI is published as the app image ghcr.io/notice-cx/noticeos:<commit>, for linux/amd64 and linux/arm64, with a build provenance attestation (release-image.yml). It is built from the container source allowlist alone. A published image is a build, not a qualified release. pnpm os:setup and pnpm os:update use it only when its labels match the commit, the schema and the hash of the public build inputs the checkout prepares for that commit; otherwise they stop without changing anything. When nothing is published for the commit, or the registry is unreachable, they build the image locally from the same inputs. A fork's commits are not published there, so a fork builds locally.
An installation also needs no checkout: docker run --rm ghcr.io/notice-cx/noticeos:main launcher | sh -s -- setup sets one up from main's newest published image, which its app then runs (Install with Docker). With no checkout there is no source to check that image against: the launcher runs the image the main tag points to, and noticeos update moves to whatever image it points to later, and rejects an image without commit and schema labels. The release workflow annotates each published index with its commit (org.opencontainers.image.revision), so the newest published version is read from one manifest. Others can fetch the image only while its package on GitHub's registry is public, a setting its owner makes once.
Hosted identity, scoped browser/task APIs and journaled scheduling have local disposable qualification. The operator runtime instructions list the implemented explicit compositions and their limits.
The portable demo profile packages the compiled app, Postgres and Dolt for a Linux server or VM behind an HTTPS reverse proxy. It creates one synthetic workspace in new, empty stores. Anonymous visitors have read-only access; a separately admitted simulator updates that workspace. It does not activate customer signup, mail delivery or provider integrations. The gateway fixes the demo profile and public origin in private server configuration; the checked-in general Worker profiles remain standalone.
This is a preview hosting profile, with pinned workerd/Miniflare runtime dependencies. Qualify the exact image and platform, fresh setup, browser requests, restart and restore before routing public traffic. The demo guide provides a stopped-stack backup procedure; recurring hosted backups are not built. Local qualification does not establish a deployed domain or production availability. Customer account hosting remains outside this release.
Qualify a release candidate
Record an immutable source commit and verification receipts. Use the locked dependency graph and the declared tool versions. All six CI jobs must pass; the evidence must name skipped tests and separately qualified deployment paths. Changes to database, task, backup or hosted behavior need the relevant disposable integration and recovery proofs as well.
Describe compatibility against the installation's actual schema and runtime. An additive migration still needs explicit verification of app versions eligible for rollback. New hosted authorization behavior cannot be assumed to exist in an older standalone release. A candidate handling non-USD ledger rows must also qualify the exact rollback app against that state; a prior app that handles only USD is not a compatible rollback merely because the schema is unchanged.
Upgrade an existing installation
Before an upgrade, identify the running commit, pending frozen migrations and the target release's instructions. Preserve a backup with a tested restore path for the operational store, task database and configured archives. Use the backup and restore procedure for the installation's declared transport.
Applying schema changes to an existing installation is a separate operator step, taken before the app update. A restart, source merge or app update never applies migrations. Migrations are additive within a release unless its release notes say otherwise, so the running app keeps working while they are applied. Follow Postgres maintenance for the exact target and approval. Do not edit applied migrations or adopt an existing database through fresh-install setup.
The app update checks main's published image against the checkout, or builds it locally, replaces only the stack's app container and stops on a release whose migrations the database has not applied. Without a checkout, noticeos update moves the image and the stack definition copied out of it together, recreates each service whose declaration changed, and stops on the same releases. App rollback keeps the updated database; it does not reverse a migration, and it is blocked across a schema change. Restore and database engine upgrades have separate procedures and must not be inferred from an app rollback command. The local stack commands are not a general hosted upgrade API.
Hosted activation additionally records the exact server profiles and origin, identity/mail/edge bindings, scoped service grants and executable registries, physical task allocations, private persistence and archive destinations. Qualify remote PostgreSQL connectivity/TLS, task transport and backup/restore for that same target before claiming support. The portable demo keeps PostgreSQL inside its private Compose network and shares a network namespace for app-to-Dolt loopback transport. It does not qualify remote database services. Customer hosting and other transports need their own qualification; the local stack commands are not a remote release mechanism.
Retain occurrence journals across app changes and rollback. An uncertain outside effect remains halted after restart; an app rollback is not, by itself, approval to reset a checkpoint, generate a new occurrence ID or replay delivery. A separately reviewed recovery plan must reconcile the exact destination and journal evidence. See the recovery states.
Publication and reporting
The license is AGPL-3.0-only, copyright 2026 Reindex Ventures LLC. Apart from the app image published for each main commit (above), preparing these materials does not publish a repository or activate a service. The intended public repository is a new export without this private repository's history or installation records. Its current files, defaults, documentation, screenshots and dependency licenses still require review before publication.
The container source allowlist excludes private build inputs; it is not a complete public-repository export or a secret audit. Private recovery archives and actual installation evidence stay private.
To prepare the reviewed public file set, use the committed-source exporter. It takes an immutable full commit hash and creates a new directory outside the checkout, with a file manifest and no Git history. It does not publish, sanitize content or qualify a release. Review that exact exported tree and its nested public archive, scan for private data, and execute the release gates before creating or publishing a history-free public repository.
No response-time or long-term maintenance commitment is established here. Report vulnerabilities privately using the contact and instructions in the security policy.