mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-22 16:51:28 +02:00
## Thinking Path > - Paperclip is the open source control plane people use to manage AI-agent companies > - Operators need a predictable installation path that survives beyond an ephemeral `npx` process > - A durable installation needs an owned per-user payload store, stable command shim, safe shell integration, and supported service lifecycle > - Updates must preserve recoverability by backing up data, installing side-by-side, verifying the new payload, and retaining rollback state > - Bootstrap scripts and privileged service operations must fail closed across download, filesystem, ownership, and consent boundaries > - This pull request integrates managed install, update, rollback, service, uninstall, doctor, bootstrap-installer, and runtime-serving support into one workflow > - The benefit is a recoverable, inspectable, and documented installation lifecycle with explicit safety boundaries across Linux, macOS, containers, WSL, npm, npx, and source checkouts ## Linked Issues or Issue Description ### Problem Paperclip lacks a first-class durable installation and lifecycle workflow. Operators currently have to assemble npm/npx installation, PATH setup, background-service management, updates, rollback, diagnostics, and uninstall behavior themselves. That makes upgrades harder to recover, creates inconsistent behavior across platforms, and leaves shell/download/service trust boundaries without one documented implementation. ### Proposed Solution Add a managed per-user install store and stable shim, a verified shell bootstrap installer, service lifecycle commands, install-mode-aware update/rollback behavior, doctor checks, and documentation. Managed updates back up the database, install and smoke-test a side-by-side payload, atomically switch `current`, and retain prior payloads. The shell installer pins registry/download trust boundaries and requires explicit consent for non-interactive privileged actions. ### Alternatives Considered - Keep recommending `npx`: simple for evaluation, but ephemeral and unsuitable for stable services, atomic updates, or rollback. - Require global npm installation only: familiar, but cannot provide the owned side-by-side payload store and retained rollback semantics. - Split the capability across multiple PRs: rejected because install, update, service, uninstall, bootstrap, and serving behavior share contracts and security boundaries that need review together. ### Related Pull Requests - Supersedes #10042 and #10044 with one integrated final diff. - Incorporates and replaces the closed preparatory work in #10032 and #10034. ## What Changed - Added `paperclipai install`, `update`/`upgrade`, rollback, uninstall, service lifecycle, onboarding integration, and managed-install doctor checks. - Added a private managed payload store, verified manifest/marker ownership, exclusive mutation locks, atomic manifest/current/shim writes, retained previous payloads, and provenance validation. - Added npm and GitHub-ref install sources with exact target resolution, registry isolation, database backup, side-by-side verification, atomic activation, service restart coordination, and failure rollback. - Made managed-update backups report actionable service-start and `--no-backup` recovery guidance for unreachable databases, while clean never-onboarded instances skip an empty backup. - Added systemd user and launchd service definitions, status/health/log commands, single-instance coordination, stale-port recovery, and explicit sudo/lingering consent handling. - Added the `scripts/install.sh` bootstrap path with checked two-stage downloads, pinned public npm registry usage, platform checks, dry-run/non-interactive controls, and Docker fixtures. - Added embedded Postgres/native bootstrap integration, hot-restart/systemd-notify serving support, passive update notices, configuration contracts, README/CLI/install documentation, and focused regression tests. - Security re-review should explicitly re-verify: (1) `addManagedPathBlock`/`removeManagedPathBlock` reject symlinked or non-regular rc files, assert current-user ownership, preserve restrictive modes, and replace atomically; (2) managed shim replacement rejects unsafe parents, foreign-owned or multiply linked files, and uses checked atomic replacement; (3) the shell installer and sudo path preserve explicit consent and checked downloads; and (4) installed service/runtime serving remains bound to the validated managed shim and instance configuration. ## Verification - `bash -n scripts/install.sh scripts/clean-install-git.sh scripts/clean-install-npm.sh scripts/test-install-sh-docker.sh` - `pnpm exec vitest run cli/src/__tests__/install-store.test.ts cli/src/__tests__/install-command.test.ts cli/src/__tests__/managed-install-check.test.ts cli/src/__tests__/onboard-service.test.ts cli/src/__tests__/service-health-check.test.ts cli/src/__tests__/service-manager.test.ts cli/src/__tests__/update-command.test.ts cli/src/__tests__/update-notice.test.ts packages/db/src/embedded-postgres-native.test.ts` — 9 files, 66 tests passed - `pnpm --dir cli typecheck` - `pnpm --dir cli build` - Follow-up verification: `pnpm exec vitest run cli/src/__tests__/update-command.test.ts` (14/14), `pnpm --dir cli typecheck`, `pnpm --dir cli build`, and `pnpm --filter @paperclipai/server typecheck`. - `pnpm -r typecheck` - `pnpm build` - Full `pnpm test:run` exercised all suites; an injected static AWS credential changed one unrelated doctor expectation, which passed when those credentials were removed. A second run cleared that case and exposed stale pre-existing adapter-utils `dist` output; rebuilding `@paperclipai/adapter-utils` made the isolated test pass. The updated PR CI is the authoritative clean-workspace full-suite run. ## Risks - Installer/update code writes executable shims, symlinks, shell rc blocks, service definitions, and managed payloads; ownership, regular-file, symlink, hard-link, marker, and path-containment checks fail closed before destructive changes. - The bootstrap installer executes downloaded tooling; downloads are staged and checked before execution, npm traffic is pinned to the public registry, and non-interactive privileged behavior requires explicit consent. - Linux lingering may invoke `sudo`; the command is surfaced and confirmed before execution, and unsupported service managers fall back to foreground-run guidance. - Database migrations remain forward-only; payload rollback does not reverse migrations, so managed updates create a backup before activation unless explicitly disabled. - Service restart and runtime serving touch process/port ownership; lifecycle locks, health/version checks, and stable-shim service definitions reduce split-brain and stale-process risk. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex coding agents using GPT-5.5 and GPT-5.6-sol, with reasoning, repository/API access, shell execution, and test tooling. The runtime did not expose a reliable context-window size. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
257 lines
8.2 KiB
Markdown
257 lines
8.2 KiB
Markdown
# Installing Paperclip
|
|
|
|
Paperclip supports a managed installation, an ephemeral `npx` tryout, a
|
|
traditional global npm installation, and development from a source checkout.
|
|
The managed installation is recommended because it provides atomic updates,
|
|
rollback, git-ref installs, and a stable entrypoint for the background service.
|
|
|
|
## Recommended Install
|
|
|
|
On macOS, Linux, or WSL2:
|
|
|
|
```sh
|
|
curl -fsSLO https://paperclip.ing/install.sh
|
|
curl -fsSLO https://paperclip.ing/install.sh.sha256
|
|
if command -v sha256sum >/dev/null 2>&1; then
|
|
sha256sum -c install.sh.sha256
|
|
else
|
|
shasum -a 256 -c install.sh.sha256
|
|
fi
|
|
bash install.sh
|
|
```
|
|
|
|
The bootstrap script:
|
|
|
|
1. verifies that the platform is supported;
|
|
2. ensures Node.js 20 or newer is available;
|
|
3. delegates installation to `paperclipai install`;
|
|
4. starts interactive onboarding when stdin and stdout are terminals.
|
|
|
|
The script prints and confirms any command that requires elevated privileges.
|
|
Third-party Node.js bootstrap scripts are pinned and SHA-256 verified before
|
|
execution; the installer stops if a published script changes unexpectedly.
|
|
The `paperclip.ing` checksum detects transfer or publishing mistakes, but it is
|
|
served from the same origin as the script and is not an independent
|
|
authenticity proof. For an independently hosted source, download a release-tag
|
|
or commit-pinned copy from GitHub, review it, and run that local file.
|
|
|
|
Use `--no-prompt` for automation and `--no-onboard` to stop after installing.
|
|
The piped form only proceeds when supported Node.js, npm, and npx are already
|
|
installed; if Node.js bootstrap is required, download the script first so the
|
|
privileged commands are inspectable before execution:
|
|
|
|
```sh
|
|
curl -fsSL https://paperclip.ing/install.sh | bash -s -- --no-prompt --no-onboard
|
|
paperclipai onboard --yes
|
|
```
|
|
|
|
If the vanity installer endpoint is unavailable, fetch the same
|
|
release-controlled source from GitHub raw content:
|
|
|
|
```sh
|
|
raw_base=https://raw.githubusercontent.com/paperclipai/paperclip
|
|
curl -fsSL "$raw_base/master/scripts/install.sh" | bash
|
|
```
|
|
|
|
For audits or incident response, pin the raw URL to a release tag or commit SHA
|
|
instead of `master` and download it first. That immutable GitHub URL provides a
|
|
separate delivery path from `paperclip.ing`; do not treat a checksum served by
|
|
the same origin as the artifact as an independent trust anchor.
|
|
|
|
Each installer flag also has a `PAPERCLIP_INSTALL_*` environment-variable
|
|
equivalent. This helps where passing arguments through a pipe is awkward.
|
|
|
|
## Managed Install Layout
|
|
|
|
Managed code is separate from instance data:
|
|
|
|
```text
|
|
~/.paperclip/cli/
|
|
├── install.json
|
|
├── current -> installs/npm/2026.720.0
|
|
└── installs/
|
|
├── npm/<version>/
|
|
└── git/<sha12>/
|
|
|
|
~/.local/bin/paperclipai
|
|
```
|
|
|
|
The `paperclipai` shim remains stable while `current` switches atomically
|
|
between complete payloads. Paperclip keeps the two previous managed payloads
|
|
for rollback. Configuration, databases, uploads, logs, secrets, and workspaces
|
|
remain under `~/.paperclip/instances/` and are not stored inside CLI payloads.
|
|
|
|
If `~/.local/bin` is not on `PATH`, the installer offers to update the relevant
|
|
shell startup file when running interactively. Non-interactive installs print
|
|
the exact `export PATH` command instead of editing shell files silently.
|
|
|
|
## Install Sources
|
|
|
|
Install the current stable release:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install
|
|
```
|
|
|
|
Install canary or pin an exact published version:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install --canary
|
|
npx --registry https://registry.npmjs.org paperclipai install --version 2026.720.0
|
|
```
|
|
|
|
Install a branch, tag, or commit from GitHub:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install --ref master
|
|
npx --registry https://registry.npmjs.org paperclipai install --ref v2026.720.0
|
|
npx --registry https://registry.npmjs.org paperclipai install --ref <commit-sha>
|
|
```
|
|
|
|
Use a fork by adding `--repo owner/repository`:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install \
|
|
--repo your-org/paperclip \
|
|
--ref your-branch
|
|
```
|
|
|
|
Git-ref installs resolve the requested ref to an exact commit before building.
|
|
Review and trust the repository and ref: installing a git ref executes that
|
|
revision's package installation and release build scripts on your machine.
|
|
|
|
## Onboarding And The Service
|
|
|
|
Run onboarding after a non-interactive installation:
|
|
|
|
```sh
|
|
paperclipai onboard
|
|
```
|
|
|
|
Interactive onboarding asks whether Paperclip should run as a background
|
|
service when the platform supports one. Automated onboarding deliberately does
|
|
not install a service unless explicitly requested:
|
|
|
|
```sh
|
|
paperclipai onboard --yes # configure only; no service install
|
|
paperclipai onboard --yes --install-service # explicit automation opt-in
|
|
paperclipai onboard --yes --no-install-service
|
|
```
|
|
|
|
Service commands are namespaced:
|
|
|
|
```sh
|
|
paperclipai service install
|
|
paperclipai service status
|
|
paperclipai service start
|
|
paperclipai service stop
|
|
paperclipai service restart
|
|
paperclipai service logs -f
|
|
paperclipai service uninstall
|
|
```
|
|
|
|
Paperclip uses a systemd user service on Linux and WSL2 systems with user
|
|
systemd, and a LaunchAgent on macOS. Containers, WSL1, and systems without a
|
|
supported user service manager receive foreground `paperclipai run` guidance
|
|
instead of a hard failure.
|
|
|
|
The service uses the stable managed-install shim, restarts after crashes, and
|
|
can start on login. On Linux, service installation may offer to enable user
|
|
lingering so it can continue without an active login session. The command
|
|
explains and confirms that system-level action before running it.
|
|
|
|
Use one server process per instance. `paperclipai run` refuses to start when
|
|
the same instance is already supervised; stop the service first or use
|
|
`--force` only when you intentionally accept the single-writer risk.
|
|
|
|
## Update And Rollback
|
|
|
|
Update according to the source and channel recorded in the install manifest:
|
|
|
|
```sh
|
|
paperclipai update
|
|
```
|
|
|
|
Select a different release source explicitly:
|
|
|
|
```sh
|
|
paperclipai update --latest
|
|
paperclipai update --canary
|
|
paperclipai update --version 2026.720.0
|
|
```
|
|
|
|
Managed updates create a database backup before switching payloads, verify the
|
|
new CLI, atomically flip `current`, and restart an installed service. A failed
|
|
install or verification leaves the previous payload active.
|
|
|
|
If the service is stopped, start it with `paperclipai service start` before
|
|
updating so Paperclip can take the safety backup. Use
|
|
`paperclipai update --no-backup` only when you intentionally accept updating
|
|
without that rollback safeguard. A never-onboarded instance with no config or
|
|
instance data skips the backup automatically because there is nothing to save.
|
|
|
|
Roll back to the previous retained payload:
|
|
|
|
```sh
|
|
paperclipai update --rollback
|
|
```
|
|
|
|
The `upgrade` command is an alias for `update`. Exact versions and commit SHAs
|
|
are pinned; provide a new target when you want them to move.
|
|
|
|
## Other Installation Methods
|
|
|
|
Ephemeral tryout with no managed install:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai onboard --yes
|
|
```
|
|
|
|
Traditional global npm install:
|
|
|
|
```sh
|
|
npm install --global --registry https://registry.npmjs.org paperclipai
|
|
paperclipai onboard
|
|
```
|
|
|
|
Source checkout for development:
|
|
|
|
```sh
|
|
git clone https://github.com/paperclipai/paperclip.git
|
|
cd paperclip
|
|
pnpm install
|
|
pnpm dev
|
|
```
|
|
|
|
The managed `paperclipai update` command can update managed and global npm
|
|
installs. For source checkouts it reports the appropriate git workflow instead
|
|
of modifying the checkout automatically.
|
|
|
|
## Diagnose An Installation
|
|
|
|
Run:
|
|
|
|
```sh
|
|
paperclipai doctor
|
|
paperclipai service status
|
|
```
|
|
|
|
`doctor` checks the managed install store, manifest, `current` link, shim,
|
|
`PATH`, Node.js version, and service state. Service diagnostics cover unit-file
|
|
presence and drift, running state, configured port ownership, and the running
|
|
server version.
|
|
|
|
## Uninstall
|
|
|
|
Remove the background service and managed CLI payloads:
|
|
|
|
```sh
|
|
paperclipai service uninstall
|
|
paperclipai uninstall
|
|
```
|
|
|
|
`paperclipai uninstall` removes the managed shim, manifest, and CLI payloads.
|
|
It deliberately preserves `~/.paperclip/instances/`, including configuration,
|
|
databases, uploads, logs, secrets, backups, and workspaces. Back up and remove
|
|
that data separately only when you intend to delete the Paperclip instance.
|