Your code has a home.
So do future updates.

A practical look at installing Stack Toast, adding your own features and reviewing an upstream release before merging it.

Start with your own repository

The public installer checks your machine and creates a project from an edition your GitHub account can access.

composer global require stacktoast/installer
stacktoast check
stacktoast new my-app

Your repository keeps two remotes: origin for your own project and stacktoast for the purchased edition’s releases. Shared git history gives future releases a merge base.

Build in normal Laravel locations

app/                    Your models and product services
app/StackToast/          The shipped foundation
resources/views/        Your pages and supported view overrides
routes/web.php          Your product routes

Use the documented extension points to change shipped behavior. Your edition includes rules for Claude Code, Cursor and Codex, plus architecture notes explaining which files belong to your app.

See the work before you update

php artisan stacktoast:upgrade

The preflight reports without changing your working files:

Your version gap and changelog entries needing attention.
Modified boilerplate files and the supported alternatives for your changes.
Conflicts found by a real trial merge in git’s object store.
Stale view overrides and missing environment keys.

Bring the release onto an upgrade branch

php artisan stacktoast:upgrade --merge

When the preflight allows it, this creates a dedicated upgrade branch and merges the release tag. It refuses with reasons when conflicts or required decisions prevent the merge.

Review the changes, run your tests and verify your application before merging the upgrade branch into your own main branch.

Already edited a shipped view?

php artisan stacktoast:upgrade --extract-overrides

The override extraction workflow helps move edits into supported view overrides. Keep reviewing upstream changes: an override can otherwise miss a later fix in its original view.

Start through git for the shared-history upgrade workflow. A ZIP’s release manifest can identify changed files, but the archive alone does not provide a shared git history for merging releases.