Marketplace: Install into an Existing Project
How to discover, analyze, and apply Feature Packs and Recipe updates to an already-running Alchemist project, including conflict detection, AI-assisted reconciliation, versioning, and compatibility.
If your project already exists and you want to add a Feature Pack or pull in a Recipe update, you use the post-creation install surface rather than recreating the project from scratch. This guide covers how to discover compatible add-ons, run the install analysis, apply changes, and understand how versioning and conflict reconciliation work.
Finding Add-Ons for Your Project
From the project Marketplace tab
Every Alchemist project has a Marketplace tab in the sidebar. Opening it shows:
- Catalog — the published listings, each with its one-time price, annual Maintenance price, and version. Click Purchase to buy a listing into this project through Stripe Checkout, or enter a Coupon / grant code and click Redeem. A listing this project already holds shows “This project already has an active license for this listing.”
- Licenses on this project — each license with its Maintenance state and the packs it includes. This is where you install and update packs.
From the standalone Marketplace
You can also browse the full catalog under Recipes & Marketplace in the sidebar. The listing detail page shows each listing’s declared compatibility. To purchase, open the listing from the project’s Marketplace tab so the license binds to that project.
Compatibility checking is based on the pack dependency declarations in the catalog. The preview step (below) provides a more precise report against your actual project files before anything is written.
Previewing an Install
Expand a license under Licenses on this project and click Preview install (or Preview update for a pack that is already installed) on a pack. Before any files are written, the preview:
- Checks dependencies and conflicts — compares the pack’s declared dependencies and conflicts against the packs already installed in your project.
- Compares files — checks each file the pack writes against what already exists in your project.
- Produces a change plan — the number of file changes, and whether the change is a clean apply or needs AI reconciliation.
- Lists what else is needed — the changelog for the incoming version and any secrets the pack requires.
The preview is read-only and non-destructive. You can run it as many times as you like.
Updating to a newer version needs active Maintenance on the license. If Maintenance has lapsed or was never bought, Apply fails with a Maintenance message and nothing is written.
Understanding the Change Plan
The analysis classifies each file the pack writes:
| Category | What it means |
|---|---|
| Add | File does not exist in your project yet — safe to write directly |
| Identical | File already matches what the pack would write — no change |
| Update | File still matches what the installed pack version wrote — the pack’s own version-to-version change applies directly |
| Overlap | File differs from both the incoming version and what the pack wrote before — you (or an agent) changed it, so it is never overwritten silently |
If any file overlaps, the plan is not a clean apply and the platform routes the change to AI reconciliation.
Applying the Changes
After reviewing the preview:
- Apply (clean apply) commits the pack’s files directly to your project’s repo and records the installation as provenance on the project.
- Apply (via AI reconciliation) (your files have drifted) dispatches an Alchemist ticket instead of overwriting anything. The agent merges your changes with the incoming pack version. Your current version stays live until that ticket lands.
Any database migrations included in the pack ship with the commit and run on the next deploy.
Versioning and Compatibility
How versions work
Each Marketplace Listing publishes a version number following semantic
versioning conventions (e.g. 1.2.0). Packs declare the range of versions of
their dependencies they are tested against. When you install a pack, the version
you receive is recorded as provenance on your project.
Compatibility declarations
A listing’s detail page shows:
- Current version and publish date
- Changelog — a human-readable description of what changed
- Compatibility — the constraints the listing declares, or “No compatibility constraints declared.”
Forks and divergence
When an AI reconciliation ticket lands, the resulting file is a fork: your project’s copy now diverges from the canonical pack source. This is expected and intentional — you own the source, and customization is a first-class use case.
If a future pack update modifies the same file again, the preview flags it as an overlap and the update routes to AI reconciliation again, which incorporates both your prior divergence and the new upstream changes.
Staying up to date
With active Maintenance, you can preview and apply newer compatible versions from Licenses on this project, and changelogs show on the listing detail page and in the preview.
Without active Maintenance, you keep the installed source and the perpetual right to use the version you purchased, but you stop receiving new compatible updates, AI-assisted reconciliation, and security/compatibility notices for that listing until Maintenance is renewed. See Maintenance Subscriptions for details on what Maintenance covers and how cancellation works.
Security, Review, and Support Expectations
Security posture of published packs
A seller publishes a pack, Recipe, or bundle version directly from Sell Recipes. There is no automated security scan or Chipp review step before a pack, Recipe, or bundle version is listed, and a published version is frozen: it cannot be changed after publishing.
A listing in the Marketplace is not a guarantee that a pack is free of vulnerabilities. Treat installed pack source with the same care as any third-party code: read the files, run your own tests, and report issues to the seller and to Chipp’s security contact.
Seller support
Each listing’s detail page links to the seller’s profile. Support for a listing is provided by the seller while Maintenance is active. For issues with a specific pack, contact the seller directly. For platform-level concerns (billing, entitlement, account), use Chipp’s support.
Sellers are not obligated to provide support beyond what is stated in their listing. Active Maintenance subscribers are entitled to the level of support the seller declares in the Maintenance terms on the listing.
Verified publisher badge
Listings from sellers Chipp has marked as verified display a verified badge. It does not constitute a warranty or guarantee.
Reporting security issues
If you discover a security vulnerability in a published pack:
- Contact the seller through the channel on their profile page.
- Also report to Chipp via the security contact in the platform footer.
- Do not publish the vulnerability publicly before the seller has had a reasonable opportunity to issue a patch (coordinated disclosure).
Chipp may delist or quarantine a listing while a reported vulnerability is being addressed.